Thiết kế Hệ thống Rút gọn URL: Cách các Công cụ Rút gọn Liên kết Hoạt động Bên trong

"Thiết kế một công cụ rút gọn URL" là một trong những câu hỏi phỏng vấn thiết kế hệ thống phổ biến nhất — và có lý do chính đáng. Nó liên quan đến hashing, cơ sở dữ liệu, bộ nhớ cache, cân bằng tải và hệ thống phân tán, tất cả trong một sản phẩm tưởng chừng đơn giản.

Trong hướng dẫn này, chúng ta sẽ tìm hiểu cách các công cụ rút gọn URL thực sự hoạt động, các quyết định thiết kế chính, và các sự cân bằng liên quan khi mở rộng quy mô.

Luồng Cơ bản

Một công cụ rút gọn URL làm hai việc:

1
Rút gọn: Lấy một URL dài và tạo mã ngắn
2
Chuyển hướng: Khi ai đó truy cập URL ngắn, chuyển hướng họ đến URL gốc

Dưới đây là luồng cấp cao:

Người dùng tạo liên kết ngắn:
  URL dài → Tạo mã ngắn → Lưu trữ ánh xạ → Trả về URL ngắn

Người dùng nhấp liên kết ngắn:
  URL ngắn → Tra cứu mã → Tìm URL dài → Chuyển hướng 301

Tạo Mã Ngắn

Thách thức cốt lõi là tạo mã duy nhất, ngắn. Có một số cách tiếp cận:

Cách tiếp cận 1: Mã hóa Base62

Chuyển đổi ID tự động tăng thành chuỗi Base62 sử dụng các ký tự [a-zA-Z0-9]:

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

Mã Base62 7 ký tự hỗ trợ 62^7 = 3,5 triệu tỷ URL duy nhất.

Ưu điểm: Đơn giản, độ dài dự đoán được, không có xung đột Nhược điểm: ID tuần tự có thể dự đoán được (người dùng có thể đoán các URL ngắn khác)

Cách tiếp cận 2: Hashing

Áp dụng hàm hash (MD5, SHA-256) cho URL dài và lấy N ký tự đầu tiên:

SHA256("https://example.com/very/long/url") → "a3f2b8c1..." Mã ngắn: "a3f2b8c"

Ưu điểm: Đầu vào giống nhau luôn tạo ra đầu ra giống nhau (khử trùng lặp) Nhược điểm: Xung đột hash yêu cầu xử lý; độ dài hash cố định có thể lãng phí không gian

Cách tiếp cận 3: Tạo Ngẫu nhiên

Tạo chuỗi ký tự chữ và số ngẫu nhiên và kiểm tra tính duy nhất:

Ưu điểm: Đơn giản, không thể dự đoán Nhược điểm: Yêu cầu kiểm tra xung đột trên mỗi lần tạo; chậm hơn khi cơ sở dữ liệu đầy

Cách tiếp cận nào để Sử dụng?

Hầu hết các hệ thống sản xuất sử dụng mã hóa Base62 với bộ tạo ID phân tán. Nó đơn giản, không có xung đột và hiệu suất cao. Tại Linkly, chúng tôi sử dụng cách tiếp cận tương tự — bạn có thể đọc thêm về cách hoạt động của các công cụ rút gọn URL để có cái nhìn tổng quan ít kỹ thuật hơn.

Thiết kế Cơ sở Dữ liệu

Bảng cốt lõi rất đơn giản:

urls ├── id (primary key, auto-increment) ├── short_code (unique index) ├── long_url (đích đến) ├── created_at (dấu thời gian) ├── user_id (ai đã tạo) └── click_count (bộ đếm được khử chuẩn hóa)

SQL vs. NoSQL

SQL (PostgreSQL, MySQL): Tuân thủ ACID, tính nhất quán mạnh, tốt cho quy mô vừa phải. Hầu hết các công cụ rút gọn URL bắt đầu ở đây.

NoSQL (DynamoDB, Cassandra): Mở rộng theo chiều ngang tốt hơn cho hàng tỷ URL. Tính nhất quán cuối cùng là chấp nhận được cho trường hợp sử dụng này.

Lai: SQL cho ánh xạ URL (cần tính nhất quán mạnh cho chuyển hướng), NoSQL hoặc cơ sở dữ liệu chuỗi thời gian cho phân tích nhấp (khối lượng ghi cao, tính nhất quán cuối cùng là tốt).

Xử lý Chuyển hướng

Khi người dùng nhấp liên kết ngắn, hệ thống phải:

1
Phân tích mã ngắn từ URL
2
Tra cứu URL dài tương ứng
3
Trả về phản hồi chuyển hướng HTTP

Chuyển hướng 301 vs. 302

301 (Vĩnh viễn): Trình duyệt lưu trữ chuyển hướng. Ít yêu cầu máy chủ hơn, nhưng bạn mất khả năng nhìn thấy nhấp lại.
302 (Tạm thời): Trình duyệt kiểm tra với máy chủ mỗi lần. Nhiều yêu cầu hơn, nhưng theo dõi nhấp tốt hơn.

Hầu hết các công cụ rút gọn URL sử dụng chuyển hướng 302 để chính xác theo dõi nhấp, sau đó cung cấp 301 làm tùy chọn cho các trường hợp sử dụng SEO. Xem hướng dẫn của chúng tôi về chuyển hướng 301 để tìm hiểu thêm về sự phân biệt này.

Bộ nhớ Cache

Chuyển hướng phải nhanh — mỗi miligiây độ trễ ảnh hưởng đến trải nghiệm người dùng. Bộ nhớ cache là quan trọng:

Bộ nhớ Cache trong Bộ nhớ (Redis/Memcached)

Lưu trữ ánh xạ mã_ngắn → URL_dài trong bộ nhớ:

GET /abc123 → Kiểm tra Redis cho "abc123" → Trúng cache? Trả về chuyển hướng ngay lập tức → Hết cache? Truy vấn cơ sở dữ liệu, lưu kết quả, trả về chuyển hướng

Một phiên bản Redis nhỏ có thể lưu trữ hàng triệu ánh xạ URL. Vì hầu hết lưu lượng truy cập đi đến một số nhỏ các liên kết phổ biến, tỷ lệ trúng cache trên 90% là phổ biến.

Bộ nhớ Cache CDN

Đối với chuyển hướng 301, các nút biên CDN có thể lưu trữ phản hồi chuyển hướng, phục vụ từ vị trí gần nhất với người dùng mà không cần phải truy cập máy chủ gốc của bạn.

Phân tích và Theo dõi Nhấp

Ghi lại dữ liệu nhấp là hoạt động ghi nặng không nên làm chậm chuyển hướng:

Xử lý Không đồng bộ

1
Người dùng nhấp liên kết ngắn
2
Hệ thống trả về chuyển hướng ngay lập tức
3
Sự kiện nhấp được đẩy vào hàng đợi thông báo (Kafka, RabbitMQ, SQS)
4
Một công nhân nền xử lý sự kiện: phân tích user agent, định vị địa lý IP, lưu trữ phân tích

Điều này tách đường dẫn chuyển hướng nhanh khỏi đường dẫn phân tích chậm hơn.

Dữ liệu để Thu Thập

Dấu thời gian
Địa chỉ IP (để định vị địa lý)
User agent (để phát hiện thiết bị/trình duyệt)
Tiêu đề Referrer
Quốc gia, thành phố (từ định vị địa lý IP)

Cân nhắc Mở rộng Quy mô

Khối lượng Công việc Nặng Đọc

Các công cụ rút gọn URL rất nặng trong việc đọc. Một tỷ lệ điển hình có thể là 100:1 đọc so với ghi. Điều này có nghĩa là:

Tối ưu hóa đường dẫn chuyển hướng trên tất cả
Sử dụng bộ nhớ cache tích cực
Sao chép lại cơ sở dữ liệu

Tạo ID Phân tán

Nếu bạn sử dụng ID tự động tăng trên nhiều máy chủ, bạn cần tránh xung đột. Tùy chọn:

Snowflake IDs: Cách tiếp cận của Twitter — nhúng dấu thời gian, ID máy và số thứ tự
UUID: Duy nhất trên toàn cầu nhưng dài hơn
Phạm vi ID: Gán mỗi máy chủ một phạm vi ID để cấp phát từ

Phân phối Địa lý

Triển khai máy chủ chuyển hướng ở nhiều vùng. Người dùng ở Tokyo không nên cần phải vòng tròn trở về máy chủ ở Virginia để chuyển hướng.

Cân nhắc Bảo mật

Các công cụ rút gọn URL có thể bị lạm dụng cho phishing và phân phối malware. Các hệ thống sản xuất cần:

Quét URL — kiểm tra đích địa chỉ chống lại cơ sở dữ liệu malware và phishing
Giới hạn tỷ lệ — ngăn chặn tạo hàng loạt các liên kết ngắn độc hại
Báo cáo lạm dụng — cho phép người dùng báo cáo các liên kết đáng ngờ
Trang xem trước — tùy chọn hiển thị cho người dùng nơi liên kết đi trước khi chuyển hướng

Tìm hiểu thêm về an toàn liên kết và bảo vệ chống lại gian lận nhấp.

Các Tính năng Bổ sung

Ngoài việc rút gọn và chuyển hướng cơ bản, các công cụ rút gọn URL sản xuất thêm:

Miền tùy chỉnh — liên kết ngắn có thương hiệu sử dụng miền của riêng bạn
Slug tùy chỉnh — chọn mã ngắn của riêng bạn thay vì các ký tự ngẫu nhiên
Hết hạn — liên kết giới hạn thời gian ngừng hoạt động sau một ngày
Bảo vệ bằng mật khẩu — yêu cầu mật khẩu để truy cập đích
Kiểm tra A/B — xoay giữa nhiều đích
Nhắm mục tiêu địa lý — chuyển hướng theo quốc gia
Nhắm mục tiêu thiết bị — các đích khác nhau cho di động vs. máy tính để bàn
Mã QR — tạo mã có thể quét cho bất kỳ liên kết ngắn nào

Kết luận

Thiết kế hệ thống rút gọn URL là một bài tập tuyệt vời vì nó bắt đầu đơn giản nhưng tiết lộ các lớp phức tạp: tạo mã, thiết kế cơ sở dữ liệu, bộ nhớ cache, đường ống phân tích và ngăn chặn lạm dụng. Hiểu những nguyên tắc cơ bản này sẽ giúp ích cho dù bạn đang chuẩn bị cho các cuộc phỏng vấn hay xây dựng các công cụ của riêng mình.

Muốn sử dụng công cụ rút gọn URL sản xuất mà không cần xây dựng công cụ? Bắt đầu với Linkly — tất cả kiến trúc được mô tả ở trên, sẵn sàng sử dụng với miền tùy chỉnh, phân tích và các tính năng nâng cao.