System Design | Bí Mật Kiến Trúc GÁNH 10 Triệu User Của Shopee Và Binance
Cập nhật: 2026-07-09
Mục lục
- 1. Giới hạn vật lý của một máy chủ đơn
- 2. Horizontal Scaling và bài toán hỗn loạn giao thông
- 3. Load Balancer — trạm kiểm soát giao thông
- 4. Thuật toán Load Balancer: Round Robin và Least Connections
- 5. Khi kẻ xấu tấn công: DDoS, Rate Limiter và Token Bucket
- 6. Ba lớp kiến trúc phòng thủ, Auto Scaling và kết luận
1. Giới hạn vật lý của một máy chủ đơn
Hãy hình dung khoảnh khắc đồng hồ điểm đúng 0:00 trong ngày siêu sale của Shopee, hoặc giây phút Bitcoin vừa phá vỡ đỉnh lịch sử và hàng triệu trader trên Binance đồng loạt nhấn nút khớp lệnh. Cùng một vệt phần nghìn giây đó, hàng chục triệu luồng dữ liệu khổng lồ từ khắp nơi trên toàn cầu đổ ập về hệ thống.
Nếu mang khối lượng truy cập này dội vào một máy chủ vật lý thông thường, CPU sẽ bốc cháy, RAM tràn ngay lập tức và hệ thống sẽ chết đứng trước khi kịp chớp mắt. Thế nhưng thực tế thì ứng dụng vẫn chạy cực kỳ mượt mà, đơn hàng vẫn chốt, giao dịch vẫn khớp — hệ thống của họ dường như miễn nhiễm với cơn sóng thần traffic này.
Để hiểu tại sao 10 triệu kết nối có thể đánh sập một hệ thống, cần nhìn sâu vào bên trong một máy chủ vật lý. Thực chất máy chủ đứng trong data center cũng chỉ là một chiếc máy tính giống chiếc laptop đang dùng hằng ngày, chỉ là to hơn và mạnh hơn. Mỗi khi bấm F5 hoặc gửi một yêu cầu chốt đơn, yêu cầu đó đâm thẳng vào máy chủ này. Lúc này hai thành phần quan trọng nhất phải làm việc là CPU và RAM:
- CPU phải tốn sức lực để xử lý logic, tính toán.
- RAM phải cắt ra một khoảng bộ nhớ để lưu trữ tạm thời phiên đăng nhập.
Nếu chỉ có vài nghìn người, CPU và RAM dư sức phục vụ. Nhưng khi hàng triệu luồng dữ liệu ập vào cùng lúc, thanh RAM nhanh chóng bị lấp đầy không còn một khe hở, CPU phải gánh 100% công suất, nóng rực lên và quá tải.
💡 Hình dung: Giới hạn vật lý là thứ không thể phá vỡ. Khi máy chủ chạm ngưỡng giới hạn này, nó không thể xử lý thêm bất cứ ai nữa và bắt đầu cắt đứt mọi kết nối. Đó chính là lúc màn hình hiện lên con số 502 Bad Gateway.
Vậy nếu một cỗ máy vật lý có sức mạnh hữu hạn, các ông lớn công nghệ đã làm cách nào? Cách giải quyết hiển nhiên nhất là mua thêm máy chủ. Thay vì dồn toàn bộ tiền để nâng cấp một cỗ máy khổng lồ gánh mọi thứ, hệ thống được chia nhỏ ra thành bốn hoặc mười chiếc máy chủ chạy song song. Kỹ thuật này trong thực tế được gọi là horizontal scaling hay mở rộng theo chiều ngang.
2. Horizontal Scaling và bài toán hỗn loạn giao thông
Ngay khi có bốn máy chủ xếp thành hàng ngang, một vấn đề mới lập tức nảy sinh. Lượng truy cập từ người dùng vẫn tiếp tục đổ về như một cơn sóng, nhưng làm sao chúng biết phải đi vào máy nào — máy số một, số hai hay số ba?
Kết quả là các luồng kết nối chạy vòng vèo, ngơ ngác, thậm chí đứt gãy giữa chừng vì không có ai đứng ra phân luồng. Có nhiều cửa hơn để đón khách nhưng lại không có người chỉ đường. Việc mua thêm máy chủ lúc này chưa kịp giải quyết vấn đề chịu tải mà chỉ tạo ra một mớ hỗn độn mới trong luồng giao thông của dữ liệu.
Sự hỗn loạn này chính là lý do hệ thống cần một người phân luồng.
3. Load Balancer — trạm kiểm soát giao thông
Trong kiến trúc phần mềm, trạm kiểm soát này mang tên Load Balancer hay bộ cân bằng tải.
💡 Hình dung: Load Balancer giống như một anh cảnh sát giao thông hoặc một cô lễ tân đứng ngay cửa ngõ của toàn bộ trung tâm dữ liệu. Thay vì để người dùng tự do lao vào các máy chủ một cách mù quáng như trước, bây giờ tất cả mọi luồng dữ liệu đều phải đi qua chốt trạm này trước tiên.
Nhiệm vụ của Load Balancer rất rõ ràng: nhận yêu cầu từ người dùng, quan sát toàn bộ các máy chủ ở phía sau và quyết định xem luồng dữ liệu này nên được đẩy vào máy số một, số hai hay số ba là tối ưu nhất. Chỉ với sự xuất hiện của một trạm kiểm soát duy nhất này, toàn bộ sự hỗn loạn biến mất. Mọi luồng dữ liệu giờ đây chảy chân chu, chính xác và nhịp nhàng vào từng máy chủ.
Câu hỏi đặt ra là: anh cảnh sát này dùng quy tắc gì để chia việc cho các máy chủ?
4. Thuật toán Load Balancer: Round Robin và Least Connections
Round Robin
Cách đơn giản nhất và lâu đời nhất chính là thuật toán Round Robin hay phân phối luân chuyển vòng tròn.
💡 Hình dung: Nguyên lý của nó giống hệt như cách chia bài cho bốn người chơi. Load Balancer nhận request đầu tiên, ném thẳng vào máy chủ số một. Request thứ hai, ném vào máy số hai. Cứ thế tiếp tục cho máy số ba và số bốn. Sau khi đã chia xong một vòng cho tất cả các máy, nó lập tức quay ngược trở lại vạch xuất phát và giao request thứ năm cho máy số một.
Quá trình này lặp đi lặp lại một cách tuần tự, nhịp nhàng và không bao giờ sai lệch. Round Robin cực kỳ công bằng và dễ lập trình, không một máy chủ nào bị bỏ sót và số lượng công việc được chia đều tăm tắp cho tất cả mọi người — ít nhất là trên lý thuyết.
Điểm yếu chí mạng: thuật toán này công bằng một cách mù quáng. Trong thực tế các luồng dữ liệu đổ về không hề giống nhau — có request rất nhẹ như tải một dòng text giới thiệu sản phẩm, nhưng cũng có request cực kỳ nặng như xuất một file báo cáo dữ liệu dài hàng ngàn trang hay render một đoạn video.
Nếu một sự tình cờ xui xẻo ập đến, trạm cân bằng tải cứ nhắm mắt chia bài: máy số một liên tục phải nhận toàn những luồng dữ liệu nặng đô, trong khi máy số hai, ba, bốn chỉ nhận toàn việc nhẹ, xử lý xong trong chớp mắt rồi ngồi rảnh rỗi. Máy số một thì CPU kịch trần 100%, bộ nhớ tràn viền, gào thét báo động — nhưng Load Balancer không hề quan tâm xem máy nào đang mệt, máy nào đang rảnh. Tới lượt của máy số một, nó vẫn nhắm mắt ném thêm một luồng dữ liệu khổng lồ nữa vào đó, và kết cục tất yếu: máy số một sập hoàn toàn, kéo theo sự đứt gãy của hàng ngàn người dùng đang kẹt trong đó.
Least Connections
Bài học đắt giá là: cảnh sát giao thông không thể bịt mắt khi làm nhiệm vụ. Để hệ thống không bao giờ bị treo, Load Balancer buộc phải thông minh hơn, phải biết quan sát. Đó là lúc thuật toán Least Connections hay phân phối theo số lượng kết nối thấp nhất xuất hiện.
💡 Hình dung: Load Balancer được trang bị một hệ thống radar ngầm. Trước khi quyết định ném luồng dữ liệu khổng lồ đi đâu, nó sẽ tung các tia quét để hỏi thăm sức khỏe của từng máy chủ ở phía sau: "Số 1 đang gánh bao nhiêu kết nối rồi? Số 2, số 3, CPU còn rảnh không?"
Nếu máy số một đang chật vật với một file dữ liệu nặng nề, CPU đã lên tới 80%, ngay khi một yêu cầu cực nặng khác bay tới, Load Balancer quét qua và thấy máy số hai đang thảnh thơi. Chẳng có lý do gì để nhét thêm việc cho máy số một cả — đường dẫn đến máy số hai lập tức mở ra. Luồng dữ liệu được định tuyến chính xác vào nơi đang thông thoáng nhất.
Thay vì mù quáng lặp lại vòng tròn, hệ thống giờ đây liên tục đo lường, đánh giá và bù trừ cho nhau theo thời gian thực. CPU của cả bốn máy chủ luôn được duy trì ở mức cân bằng, không một ai bị bỏ lại và cũng không một ai phải làm việc đến mức gục ngã.
5. Khi kẻ xấu tấn công: DDoS, Rate Limiter và Token Bucket
Giới hạn của Load Balancer trước DDoS
Mọi thứ chỉ tuyệt vời nếu những người đang truy cập là khách hàng thật. Chuyện gì sẽ xảy ra nếu hệ thống lọt vào tầm ngắm của các cuộc tấn công từ chối dịch vụ (DDoS) — hàng triệu luồng truy cập giả ập đến cùng một giây?
Lúc này Load Balancer vẫn làm đúng nhiệm vụ của mình: liên tục quét radar, tìm máy chủ đang rảnh rỗi và chia đều công việc. Nhưng vấn đề là nó đang chia đều rác. Hàng triệu yêu cầu giả mạo được phân bổ một cách hoàn hảo và chính xác cho cả bốn máy chủ. Kết quả: cả bốn thanh CPU đồng loạt vọt lên 100%, bộ nhớ tràn viền, cả bốn máy chủ cùng lúc bốc cháy — hệ thống sập toàn tập.
Sự thật cay đắng là: chia đều cái xấu thì không thể làm nó tốt lên. Cảnh sát giao thông chỉ có nhiệm vụ phân luồng chứ không phải bắt cướp. Để chống lại cuộc tấn công này, cần một lớp phòng thủ hoàn toàn mới.
Rate Limiter
Trạm cân bằng tải sinh ra là để chỉ đường chứ không hề có chức năng chặn cửa. Để chống lại cơn bão traffic giả khổng lồ kia, cần thiết lập một chốt chặn đặc biệt ngay trước mắt trạm cân bằng tải. Bức tường này trong kiến trúc hệ thống được gọi là Rate Limiter hay bộ giới hạn tốc độ.
💡 Hình dung: Rate Limiter giống như một gã bảo vệ quán bar cực kỳ khó tính và lạnh lùng. Đám mây traffic giả hung hãn vừa lao tới liền đập thẳng vào bức tường phòng ngự và vỡ vụn. Gã bảo vệ này không quan tâm bạn là ai, hắn chỉ có một nguyên tắc duy nhất: chỉ cho phép một số lượng khách nhất định lọt qua cửa trong mỗi giây. Nếu vượt quá, xin lỗi, mời quay đầu.
Nhờ lớp khiên tuyệt đối này, những luồng truy cập hợp lệ, sạch sẽ vẫn chậm rãi lọt qua. Trạm cân bằng tải phía dưới lại thong thả làm việc của mình và các máy chủ bắt đầu hạ nhiệt.
Token Bucket
Bí mật đằng sau cách Rate Limiter biết chính xác lúc nào nên cho qua, lúc nào nên chặn lại nằm ở một thuật toán kinh điển trong system design có tên là Token Bucket.
💡 Hình dung: Đằng sau lớp khiên, đặt một chiếc xô trống. Phía trên chiếc xô là một hệ thống nhỏ liên tục nhỏ xuống các đồng xu với một tốc độ cố định, giả sử năm đồng xu cho mỗi giây. Mỗi khi một yêu cầu từ người dùng muốn đi qua cửa, nó bắt buộc phải lấy được một đồng xu trong chiếc xô này. Nếu xô đang có sẵn đồng xu, yêu cầu lấy một đồng làm thẻ thông hành và đi thẳng vào máy chủ.
Nếu một cuộc tấn công spam quét qua, hàng chục yêu cầu lao đến cùng lúc và tranh nhau lấy xu, chiếc xô lập tức cạn sạch. Lúc này bất kỳ yêu cầu nào đến sau mà thò tay vào một chiếc xô rỗng, hệ thống sẽ lập tức báo lỗi và từ chối phục vụ, phải đợi cho đến khi hệ thống nhỏ thêm đồng xu mới vào xô.
Cơ chế này cho phép một số lượng truy cập tăng vọt trong ngắn hạn nhờ số xu tích lũy sẵn, nhưng về dài hạn, tốc độ truy cập không bao giờ vượt quá tốc độ nhỏ giọt của đồng xu.
Tại sao phải dùng một chiếc xô tích trữ thay vì quy định cứng mỗi giây chỉ được truy cập đúng một lần? Câu trả lời nằm ở thói quen thực tế của người dùng — sẽ có những lúc sốt ruột và lỡ tay click đúp chuột, hoặc ứng dụng cần tải năm file hình ảnh cùng lúc chỉ trong vòng nửa giây. Đó gọi là spike traffic, lưu lượng tăng vọt đột ngột. Nếu dùng quy tắc cứng nhắc, các thao tác hợp lệ sẽ bị chặn ngay lập tức, gây ra trải nghiệm giật lag khó chịu. Nhưng với cơ chế xô đựng xu, nếu chiếc xô đang tích trữ sẵn năm đồng xu, nó sẵn sàng nhân nhượng cho phép cả năm yêu cầu đi qua cùng một lúc.
Chiếc xô này hoàn toàn không nhân nhượng với kẻ xấu: khi một con bot xả 50 yêu cầu liên tục vào hệ thống, chiếc xô có thể cho năm yêu cầu đầu tiên đi qua nhờ xu tích lũy, nhưng ngay lập tức cạn sạch — 45 yêu cầu còn lại sẽ bị chặn đứng tàn nhẫn, đập vào tường và bị hệ thống dán thẳng cho một nhãn cảnh báo đỏ rực: HTTP 429: Too Many Requests. Kèm theo mã lỗi này, trạm kiểm soát thường trả lại một thông điệp retry-after, yêu cầu con bot phải đợi đúng vài giây nữa mới được phép quay lại.
Nhờ vậy, hệ thống vừa thân thiện với con người vừa tàn nhẫn với hacker.
Token Bucket trong triển khai thực tế
Trong thực tế vận hành, module giới hạn tốc độ chuẩn của Nginx (ngx_http_limit_req_module) không dùng đúng Token Bucket mà dùng một thuật toán họ hàng gần là leaky bucket — request xếp hàng và được xử lý ra theo một tốc độ cố định (giống nước rò rỉ đáy xô ở tốc độ không đổi) thay vì được cấp token tích lũy. Cách vận hành khác nhau ở chỗ leaky bucket làm phẳng tốc độ ra, còn Token Bucket cho phép xả một cụm burst lớn khi token còn tồn đọng — nhưng cả hai đều phục vụ chung một mục tiêu: chặn spam mà vẫn khoan dung với spike traffic hợp lệ.
# Định nghĩa zone lưu trạng thái leaky bucket, giới hạn 5 request/giây cho mỗi IP
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;
server {
location /api/ {
# burst=10: cho phép hàng đợi tối đa 10 request vượt rate trước khi bị từ chối
# nodelay: xử lý ngay các request nằm trong hàng đợi burst thay vì delay tuần tự
limit_req zone=api_limit burst=10 nodelay;
}
}
6. Ba lớp kiến trúc phòng thủ, Auto Scaling và kết luận
Ba lớp kiến trúc
Để một hệ thống khổng lồ như Shopee hay Binance có thể đứng vững trước hàng triệu kết nối, bí quyết không nằm ở một cỗ máy vật lý siêu phàm nào cả. Nó nằm ở sự kết hợp của ba lớp kiến trúc:
- Rate Limiter đứng sừng sững ở ngoài cùng, lạnh lùng thanh lọc toàn bộ luồng truy cập độc hại, cắt đứt các đợt tấn công DDoS và chỉ cho phép những người dùng hợp lệ lọt vào bên trong.
- Load Balancer thông minh, hoạt động như một radar liên tục quét tình trạng của các máy chủ bên dưới. Nhờ thuật toán Least Connections, nó khéo léo định tuyến luồng dữ liệu sạch vừa lọt qua, đẩy chúng vào những vị trí đang rảnh rỗi nhất.
- Cụm máy chủ — nhờ được bảo vệ và phân luồng hoàn hảo, các máy chủ giờ đây không còn gào thét báo động. Chúng hoạt động nhịp nhàng, chia sẻ gánh nặng cho nhau, duy trì sự cân bằng tuyệt đối.
Một luồng dữ liệu khổng lồ đầy rác và sự hỗn loạn từ bên ngoài khi đi qua hệ thống này đã biến thành những dòng chảy chân chu, yên bình và trật tự.
Auto Scaling — khi traffic thật tăng vọt
Ba lớp phòng thủ trên giải quyết vấn đề spam rất tốt. Nhưng giả sử hôm nay là ngày sale lớn nhất năm, 11 tháng 11, và 10 triệu luồng truy cập khổng lồ hoàn toàn là người dùng thật đang cầm thẻ tín dụng để chốt đơn. Lúc này Rate Limiter không thể cứ nhắm mắt chặn cửa được, vì nếu chặn khách hàng thật, công ty sẽ mất hàng tỷ đồng. Nó buộc phải nới lỏng rào chắn, hàng triệu luồng dữ liệu hợp lệ ồ ạt đổ xuống trạm cân bằng tải. Dù chia đều đến đâu, bốn chiếc máy chủ phía dưới lại một lần nữa gồng gánh đến kiệt sức, đèn báo động CPU lại chuyển sang màu cam rực.
Đây là lúc sức mạnh thực sự của điện toán đám mây — auto scaling hay tự động giãn nở — phát huy tác dụng. Ngay khi nhận thấy cả bốn máy chủ đều đang chạm ngưỡng 80% công suất, hệ thống không hề hoảng loạn. Nó tự động tạo ra thêm bốn chiếc máy chủ mới tinh ngay lập tức. Trạm cân bằng tải nhanh như chớp, phóng thêm bốn đường truyền kết nối tới các máy mới này. Dòng thác dữ liệu khổng lồ lập tức được xé nhỏ ra làm tám, tải trọng trên mỗi máy giảm đột ngột từ mức nguy hiểm xuống trạng thái an toàn.
Không cần phải mua dư tám chiếc máy chủ từ đầu tháng để đóng bụi — hệ thống chỉ tự động thuê thêm máy đúng vào giây phút cao điểm đó và sẽ tự động tắt bớt đi khi ngày sale kết thúc. Tối ưu chi phí tuyệt đối và không một khách hàng nào bị rớt mạng.
Kết luận
Toàn bộ khối kiến trúc vĩ đại đó — từ Load Balancer, Rate Limiter đến cơ chế giới hạn tốc độ kiểu xô đựng xu — đều không phải là phép thuật. Chúng được tạo ra và điều khiển bởi những dòng cấu hình rất đơn giản và gọn gàng, ví dụ chỉ vài dòng cấu hình trong Nginx (limit_req_zone, limit_req) là đã có thể định nghĩa xong tốc độ giới hạn, kích thước hàng đợi cho phép vượt ngưỡng và thiết lập luật chia bài cho hệ thống cân bằng tải.
Hệ thống hàng tỷ đô của Shopee hay Binance về bản chất cốt lõi cũng bắt nguồn từ những nguyên lý thiết kế và những đoạn mã cơ bản này. Đó chính là vẻ đẹp của System Design: không chỉ viết ra một phần mềm, mà là làm kiến trúc sư xây dựng nên một thành phố dữ liệu, nơi mọi thứ vận hành trong một trật tự tuyệt đối.
Từ một chiếc máy chủ đơn độc, yếu ớt và dễ dàng gục ngã ở những phút đầu tiên, ba lớp kiến trúc — bức tường Rate Limiter vững trãi chặn đứng mọi kẻ phá hoại, trạm cân bằng tải Load Balancer thông minh điều phối từng nhịp đập, và sức mạnh Auto Scaling sẵn sàng bung nở nhân bản hệ thống lên gấp nhiều lần — đã cùng nhau tạo nên một pháo đài dữ liệu bất khả xâm phạm.
Không có phép thuật nào ở đây cả, chỉ có tư duy kiến trúc sắc bén và những dòng code tinh tế.
Nguồn tham khảo
Nguồn gốc: Bí mật kiến trúc GÁNH 10 Triệu User của Shopee và Binance | System Design — kênh Học Giải Thuật Cùng HPN
Ghi chú kỹ thuật (fact-check bổ sung):
- Bài viết gốc liên hệ trực tiếp cấu hình Nginx với thuật toán Token Bucket đã trình bày ở mục 5. Trên thực tế, module giới hạn tốc độ chuẩn của Nginx (
ngx_http_limit_req_module) dùng thuật toán leaky bucket — request được xử lý ra theo hàng đợi FIFO ở tốc độ cố định, khác với Token Bucket cho phép tích lũy token để xả burst. Nguồn: Nginx — ngx_http_limit_req_module, NGINX Blog — Rate Limiting with NGINX (truy cập 2026-07-09). - HTTP 429 Too Many Requests và header Retry-After (đề cập ở mục 5) đã được verify: 429 định nghĩa tại RFC 6585 (2012), Retry-After nay thuộc RFC 9110 §10.2.3 — nội dung transcript gốc chính xác.