Projekt systemu skracającego adresy URL: Jak działają skracarze linków pod maską

"Zaprojektuj skracacz adresów URL" to jedno z najpopularniejszych pytań z zakresu projektowania systemów — i słusznie. Dotyka haszowania, baz danych, buforowania, równoważenia obciążenia i systemów rozproszonych, wszystko w pozornie prostym produkcie.

W tym przewodniku omówimy, jak faktycznie działają skracarze adresów URL, kluczowe decyzje projektowe i powiązane z nimi kompromisy w dużej skali.

Skracacz adresów URL wykonuje dwie rzeczy:

1. 1Skrócenie: Wziąć długi adres URL i wygenerować krótki kod
2. 2Przekierowanie: Gdy ktoś odwiedzi krótki adres URL, przekierować go do oryginału

Oto przepływ wysokiego poziomu:

Użytkownik tworzy krótki link:
  Długi URL → Wygeneruj krótki kod → Przechowuj mapowanie → Zwróć krótki URL

Użytkownik klika na krótki link:
  Krótki URL → Wyszukaj kod → Znajdź długi URL → Przekierowanie 301

Głównym wyzwaniem jest generowanie unikalnych, krótkich kodów. Istnieje kilka podejść:

Konwertuj automatycznie inkrementowany ID na ciąg Base62 przy użyciu znaków [a-zA-Z0-9]:

• ID 1 → 1
• ID 62 → 10
• ID 238,328 → ZZZ

7-znakowy kod Base62 obsługuje 62^7 = 3,5 biliona unikalnych adresów URL.

Plusy: Proste, przewidywalna długość, brak kolizji Minusy: Sekwencyjne identyfikatory są przewidywalne (użytkownicy mogą odgadnąć inne krótkie adresy URL)

Zastosuj funkcję haszowania (MD5, SHA-256) do długiego adresu URL i weź pierwsze N znaków:

SHA256("https://example.com/very/long/url") → "a3f2b8c1..." Kod skracający: "a3f2b8c"

Plusy: Takie samo wejście zawsze daje takie samo wyjście (deduplikacja) Minusy: Kolizje haszowania wymagają obsługi; ustalona długość haszowania może marnować miejsce

Wygeneruj losowy ciąg alfanumeryczny i sprawdź wyjątkowość:

Plusy: Proste, nieprzewidywalne Minusy: Wymaga sprawdzenia kolizji przy każdym utworzeniu; szybciej się spowolnia w miarę zapełniania się bazy danych

Większość systemów produkcyjnych używa kodowania Base62 z rozproszoną generatorem identyfikatorów. Jest proste, wolne od kolizji i wydajne. W Linkly używamy podobnego podejścia — możesz przeczytać więcej o jak działają skracarze adresów URL, aby uzyskać mniej techniczny przegląd.

Tabela główna jest prosta:

urls ├── id (klucz podstawowy, inkrementacja) ├── short_code (indeks unikalny) ├── long_url (miejsce docelowe) ├── created_at (znacznik czasu) ├── user_id (kto to utworzył) └── click_count (denormalizowany licznik)

SQL (PostgreSQL, MySQL): Zgodność ACID, silna spójność, dobra dla umiarkowanej skali. Większość skracarzy adresów URL zaczyna się tutaj.

NoSQL (DynamoDB, Cassandra): Lepsza skalowalna poziomo dla miliardów adresów URL. Spójność ostateczna jest akceptowalna dla tego przypadku użycia.

Hybrydowe: SQL dla mapowań adresów URL (potrzebna silna spójność dla przekierowań), NoSQL lub baza danych szeregów czasowych dla analityki kliknięć (wysoka liczba zapisów, spójność ostateczna jest w porządku).

Gdy użytkownik kliknie na krótki link, system musi:

1. 1Przeanalizować kod skracający z adresu URL
2. 2Wyszukać odpowiadający długi adres URL
3. 3Zwrócić odpowiedź przekierowania HTTP

• 301 (Stałe): Przeglądarka buforuje przekierowanie. Mniej żądań serwerowych, ale tracisz widoczność powtarzających się kliknięć.
• 302 (Tymczasowe): Przeglądarka sprawdza serwer za każdym razem. Więcej żądań, ale lepsze śledzenie kliknięć.

Większość skracarzy adresów URL używa przekierowań 302 dla dokładności śledzenia kliknięć, a następnie oferuje 301 jako opcję dla przypadków użycia SEO. Zobacz nasz przewodnik na temat przekierowań 301, aby uzyskać więcej informacji na temat tego rozróżnienia.

Przekierowania muszą być szybkie — każda milisekunda opóźnienia wpływa na doświadczenie użytkownika. Buforowanie jest krytyczne:

Buforuj mapowanie short_code → long_url w pamięci:

GET /abc123 → Sprawdź Redis dla "abc123" → Trafienie w pamięć podręczną? Zwróć przekierowanie natychmiast → Brak w pamięci podręcznej? Zapytaj bazę danych, buforuj wynik, zwróć przekierowanie

Mała instancja Redis może buforować miliony mapowań adresów URL. Ponieważ większość ruchu trafia na stosunkowo niewielką liczbę popularnych linków, wskaźniki trafienia pamięci podręcznej powyżej 90% są powszechne.

W przypadku przekierowań 301 węzły brzegowe CDN mogą buforować odpowiedź przekierowania, serwując je z lokalizacji najbliższej użytkownikowi bez wcale trafiania na serwer źródłowy.

Rejestrowanie danych kliknięć to operacja z dużą ilością zapisów, która nie powinna spowolniać przekierowania:

1. 1Użytkownik klika na krótki link
2. 2System natychmiast zwraca przekierowanie
3. 3Zdarzenie kliknięcia jest wypychane do kolejki komunikatów (Kafka, RabbitMQ, SQS)
4. 4Pracownik w tle przetwarza zdarzenie: analizuje agenta użytkownika, geolokuje adres IP, przechowuje analitykę

To oddziela szybką ścieżkę przekierowania od wolniejszego potoku analityki.

• Znacznik czasu
• Adres IP (do geolokalizacji)
• Agent użytkownika (do wykrywania urządzenia/przeglądarki)
• Nagłówek referrera
• Kraj, miasto (z geolokalizacji IP)

Skracarze adresów URL są bardzo intensive do odczytu. Typowy stosunek może wynosić 100:1 odczytów do zapisów. To oznacza:

• Zoptymalizuj ścieżkę przekierowania ponad wszystko inne
• Użyj agresywnie buforowania
• Przeczytaj repliki dla bazy danych

Jeśli używasz automatycznie inkrementowanych identyfikatorów na wielu serwerach, musisz unikać kolizji. Opcje:

• Snowflake IDs: Podejście Twittera — osadź znacznik czasu, identyfikator maszyny i numer sekwencyjny
• UUID: Uniwersalnie unikalny, ale dłuższy
• Zakresy identyfikatorów: Przydziel każdemu serwerowi zakres identyfikatorów do przydzielenia

Wdrażaj serwery przekierowań w wielu regionach. Użytkownik w Tokio nie powinien potrzebować podróży w obie strony do serwera w Wirginii w celu przekierowania.

Skracarze adresów URL mogą być nadużywane do rozpowszechniania phishingu i złośliwego oprogramowania. Systemy produkcyjne potrzebują:

• Skanowania adresów URL — sprawdzenie miejsc docelowych względem baz danych złośliwego oprogramowania i phishingu
• Ograniczenia szybkości — zapobieganie masowemu tworzeniu złośliwych krótkich linków
• Zgłaszanie nadużyć — pozwól użytkownikom zgłaszać podejrzane linki
• Strony podglądu — opcjonalnie pokaż użytkownikom gdzie link idzie przed przekierowaniem

Dowiedz się więcej o bezpieczeństwie linków i ochronie przed oszustwami kliknięć.

Poza podstawowym skracaniem i przekierowaniem, produkcyjne skracarze adresów URL dodają:

• Domeny niestandardowe — markowe krótkie linki przy użyciu Twojej własnej domeny
• Niestandardowe slugi — wybierz swój własny kod skracający zamiast losowych znaków
• Wygaśnięcie — linki ograniczone czasowo, które przestają działać po dacie
• Ochrona hasłem — wymagaj hasła, aby uzyskać dostęp do miejsca docelowego
• Test A/B — obracaj się pomiędzy wieloma miejscami docelowymi
• Targeting geograficzny — przekierowuj po kraju
• Targeting urządzenia — różne miejsca docelowe dla urządzeń mobilnych vs. pulpitu
• Kody QR — generuj kody skanowalne dla każdego krótkiego linku

Projekt systemu skracającego adresy URL to świetne ćwiczenie, ponieważ zaczyna się prosto, ale ujawnia warstwy złożoności: generowanie kodu, projekt bazy danych, buforowanie, potoki analityki i zapobieganie nadużyciom. Zrozumienie tych podstaw pomaga niezależnie od tego, czy przygotowujesz się do rozmów kwalifikacyjnych, czy budujesz własne narzędzia.

Chcesz użyć produkcyjnego skracającego adresy URL bez budowania go? Zacznij z Linkly — cała architektura opisana powyżej, gotowa do użytku z niestandardowymi domenami, analityką i zaawansowanymi funkcjami.