High-Concurrency

Mục lục Series | Chương tiếp theo: Executive Summary → Answer-first: Khung nghiên cứu Alipay Double 11 hệ thống hóa toàn bộ kiến trúc xử lý thanh toán tài chính chịu tải 544.000 TPS: từ lịch sử mở rộng quy mô, trung tâm dữ liệu logic LDC, cơ sở dữ liệu phân tán OceanBase, middleware SOFAStack đến kiểm soát rủi ro AI CTU. Học Kiến Trúc Alipay Double 11 - Learning Index Nghiên cứu chi tiết về hệ thống xử lý 544,000 giao dịch/giây của Alipay ...

← Chương trước: Phần 1: HTTP/REST vs. gRPC Protobuf | Mục lục Series | Chương tiếp theo: Phần 3: Primary Key Showdown (UUIDv7 vs. Snowflake vs. BIGINT) → Answer-first: Đối với các điểm nóng giao dịch e-commerce chịu tải trên 5.000 RPS (Flash Sale, khóa tồn kho), Golang vượt trội nhờ tiêu tốn ít hơn 85% RAM và độ trễ P99 dưới 15ms, trong khi PHP/Laravel giữ vai trò trung tâm quản trị nghiệp vụ và cổng thông tin sản phẩm. ...

← Chương trước: Tóm Tắt Dành Cho Lãnh Đạo | Mục lục Series | Chương tiếp theo: Chương 2 — 3 Điểm Yếu Của Caching → Answer-first: Để vượt qua rào cản C10M (10 triệu kết nối đồng thời), hệ thống phân tán áp dụng kỹ thuật Kernel Bypass (DPDK/eBPF), thiết kế API Stateless đẩy toàn bộ trạng thái vào Redis, kết hợp Multi-level Caching và xử lý đơn hàng bất đồng bộ qua Kafka theo mô hình Shopee và Alipay. ...

← Chương trước: Bài 2: Kiến trúc Flash Sale — Bí ẩn phía sau Redis và Hot Keys | Mục lục Series | Chương tiếp theo: Bài 4: Tầng Dữ liệu — Từ MySQL Sharding đến TiDB NewSQL → Answer-first: Tấm khiên bảo vệ hệ thống trước cơn bão traffic Flash Sale kết hợp hàng đợi Apache Kafka để đệm đơn hàng và san phẳng đỉnh tải, cùng cơ chế suy giảm dịch vụ mềm (Graceful Degradation) tự động tắt các tính năng phụ để dồn tài nguyên cho luồng thanh toán. ...

← Chương trước: Lộ Trình Nghiên Cứu 5 Phase | Mục lục Series | Chương tiếp theo: Phase 2: Kiến Trúc LDC & OceanBase → Answer-first: Lịch sử 17 năm phát triển Double 11 của Alipay ghi nhận sự nhảy vọt từ 200 TPS (năm 2009) lên 544.000 TPS (năm 2019), vượt qua khủng hoảng giới hạn Oracle năm 2012 để kiến tạo kiến trúc LDC và cơ sở dữ liệu phân tán OceanBase tự chủ. ...

Answer-first: Hệ thống Event-Driven hiệu năng cao trên Go kết hợp NATS JetStream, CQRS và Transactional Outbox Pattern xử lý hơn 120.000 event/giây. Thiết kế phân tách Command-Query triệt để, đảm bảo ngữ nghĩa At-Least-Once Delivery và duy trì tính nhất quán cuối cùng giữa các bounded context. 🇬🇧 Read the English version of this article on tanhdev.com 1. Lý do Kiến trúc: Tại sao chọn Go + NATS JetStream cho Microservices Event-Driven Trong các kiến trúc cloud-native hiện đại, việc mở rộng quy mô hệ thống phân tán vượt ngưỡng hàng chục nghìn giao dịch mỗi giây (TPS) bộc lộ những nút thắt cổ chai nghiêm trọng trong mô hình request-response truyền thống. Traditional microservices built around synchronous HTTP/REST or gRPC backplanes frequently encounter database write contention, connection pool exhaustion, and cascading latency spikes whenever traffic bursts hit downstream storage layers. When a single database handles both complex mutation transactions (commands) and heavy analytical join queries (reads), row-level locks and index maintenance stall throughput, inflating p99 latencies from milliseconds to seconds. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Fiber và Gin là hai Go web framework hiệu năng cao với kiến trúc khác biệt: Fiber tận dụng fasthttp và sync.Pool để đạt 85,200 TPS zero-allocation, trong khi Gin dùng net/http tiêu chuẩn (42,500 TPS) cho độ ổn định, tương thích HTTP/2 và an toàn context Go mà không lo rủi ro tái sử dụng buffer đồng thời. The Testing Methodology (Beyond Hello World) Trong thế giới phát triển phần mềm, các bài kiểm tra hiệu năng kiểu “Hello World” thường rất phổ biến nhưng lại mang lại rất ít giá trị thực tế cho việc thiết kế hệ thống chịu tải cao. Một handler rỗng trả về chuỗi văn bản đơn giản chỉ đo được tốc độ phân tích cú pháp routing của framework và overhead tối thiểu của việc bắt tay TCP. Khi đưa ứng dụng vào môi trường sản xuất thực tế, hệ thống phải đối mặt với các bài toán phức tạp hơn nhiều bao gồm: kết nối cơ sở dữ liệu, quản lý tài nguyên đồng thời thông qua connection pooling, thực thi chuỗi middleware (ghi log, xác thực request, phân quyền) và xử lý vòng đời của Context. Do đó, bài viết này thiết lập một phương pháp kiểm tra hiệu năng thực tế hơn nhằm mô phỏng sát nhất các ứng dụng backend trong thực tế. ...

Answer-first: Kiến trúc Shopee Flash Sale chịu tải hàng triệu TPS nhờ phân tách luồng qua API Gateway, chặn tải 3 lớp (CDN Edge, Redis Token Bucket, Virtual Queue), tải trước kho (pre-heating) và trừ tồn kho nguyên tử bằng Redis Lua script sub-millisecond, sau đó ghi bất đồng bộ (Cache-Ahead) vào MySQL sharded & TiDB HTAP. 🇬🇧 Read the English version of this article on tanhdev.com Đúng 00:00:00 đêm 11.11, hàng triệu người dùng tại Đông Nam Á đồng loạt nhấn nút mua hàng trên một trang sản phẩm Flash Sale duy nhất (ví dụ: 1,000 suất sản phẩm giảm giá 99%). Trong 10 giây đầu tiên, một sản phẩm duy nhất có thể chịu hàng triệu lượt truy vấn đồng thời. Nếu không có kiến trúc vững chắc, hệ thống sẽ gặp các sự cố nghiêm trọng như bán quá số lượng kho (overselling), sập máy chủ, hoặc tắc nghẽn cơ sở dữ liệu (database deadlock). ...