docs(newsletter): remove two Redis leaderboard entries from newsletter 130

2026-09-18 08:21:36 +00:00 · 2026-09-10 11:20:41 +07:00
parent 19c75e0f0b
commit 49cd340f3d
1 changed files with 0 additions and 30 deletions
@@ -111,33 +111,3 @@ Thiết kế còn có vài điểm đáng học. Toàn bộ thay đổi trạng
 - Script Lua đảm bảo mọi thay đổi trạng thái diễn ra nguyên tử trong một lần chạy.
 - Dùng số thứ tự thay cho dấu thời gian để tránh lệch đồng hồ giữa các máy.
 - Đánh đổi: độ trễ tăng 11–17% và bộ nhớ mỗi thành viên tăng gần ba lần.
-
-## [Redis Cluster Won't Shard Your Hot Leaderboard](https://dev.to/trungdlp/redis-cluster-wont-shard-your-hot-leaderboard-2c4p)
-
-Cùng tác giả của bài Podium ở trên, bài này bóc tách một hiểu lầm phổ biến trong câu nói "chúng tôi dùng Redis Cluster". Câu đó có thể mang hai nghĩa rất khác nhau: dữ liệu được phân tán trên nhiều nút, hoặc từng cấu trúc dữ liệu được chia nhỏ ra nhiều nút. Vế đầu có thể đúng trong khi vế sau hoàn toàn sai, và với bảng xếp hạng thì khác biệt này rất quan trọng.
-
-Mỗi bảng xếp hạng của Podium dùng năm khóa: hai sorted set cho chỉ mục giảm dần và tăng dần, một hash ánh xạ thành viên, một chuỗi giữ bộ đếm phân định điểm bằng nhau, và một sorted set quản lý hạn dùng. Redis Cluster chia không gian khóa thành 16.384 khe băm, và mặc định mỗi khóa băm độc lập nên có thể rơi vào các nút chính khác nhau — khi đó script Lua không còn chạy nguyên tử được nữa. Giải pháp là dùng hash tag với cú pháp `{...}`, ép mọi khóa của cùng một bảng xếp hạng rơi vào chung một khe, chẳng hạn `podium:{b<id>}:scores` và `podium:{b<id>}:members`.
-
-Điều cần chấp nhận là thêm nút vào cụm chỉ giúp trải các bảng xếp hạng khác nhau ra, chứ không chia nhỏ một bảng đang nóng. Với những bảng quá tải, tác giả khuyên phân vùng ở tầng ứng dụng theo khu vực, chế độ chơi, mùa giải hay bậc kỹ năng, đổi lại phải gộp kết quả khi đọc. Khi một lần cập nhật ảnh hưởng nhiều bảng, Podium chạy song song bằng goroutine giới hạn ở 32 luồng, vì các bảng đó cố ý nằm ở khe khác nhau.
-
-**Điểm chính:**
- Phân tán dữ liệu trên nhiều nút không đồng nghĩa với chia nhỏ một cấu trúc dữ liệu.
- Hash tag `{...}` ép các khóa liên quan vào cùng một khe băm để giữ tính nguyên tử.
- Một bảng xếp hạng luôn nằm trọn trên một nút chính, thêm nút không giúp gì cho nó.
- Bảng quá nóng phải được phân vùng ở tầng ứng dụng, đổi lại chi phí gộp khi đọc.
- Nên kiểm thử tích hợp trên cụm thật để phát hiện thao tác vi phạm ranh giới khe băm.
-
-## [Correctness Has a Price: We Benchmarked Fair Leaderboards](https://dev.to/trungdlp/correctness-has-a-price-we-benchmarked-fair-leaderboards-3ia8)
-
-Bài cuối trong loạt bài về Podium trả lời câu hỏi tự nhiên nhất: tính công bằng khi phân định điểm bằng nhau đáng giá bao nhiêu? Đội ngũ đã thêm script Lua, bộ đếm riêng cho mỗi bảng, lớp ánh xạ ID công khai và hai sorted set song song — tất cả đều có giá của nó, và họ chọn cách đo đạc thay vì phỏng đoán. Bốn chiến lược được đem ra so sánh: sorted set thuần túy làm mốc, thiết kế mã hóa thành viên như trong sản phẩm thật, bản chỉ dùng một chỉ mục để tách riêng chi phí mã hóa, và bản gộp điểm với số thứ tự vào một giá trị duy nhất.
-
-Kết quả đo trực tiếp trên Redis cho thấy chi phí độ trễ khá dễ chịu: thêm thành viên và trả về thứ hạng đắt hơn 11%, đổi điểm rồi trả về thứ hạng 17%, gửi lại điểm không đổi 5%, đọc một thứ hạng chỉ 1%, và đọc 50 người dẫn đầu 3%. Bộ nhớ mới là khoản đắt: khoảng 287 byte mỗi thành viên so với 99 byte của bản mốc. Đo đầu-cuối qua HTTP trên máy M4 Pro, trung vị của việc đặt điểm cho một thành viên là 305 µs, đọc một thứ hạng 282 µs, đọc một trang dẫn đầu 441 µs, còn cập nhật một người chơi trên 100 bảng mất 3,58 ms.
-
-Phần đáng giá nhất có lẽ là tám nguyên tắc đo đạc mà họ rút ra: xác định hợp đồng hành vi trước khi đo, luôn giữ một bản mốc đơn giản để so, đo từng thao tác riêng biệt, đo bộ nhớ phía máy chủ chứ không chỉ phía client, và giữ cho mọi hồi quy hiệu năng luôn nhìn thấy được. Như tác giả viết, mục tiêu không phải chứng minh thiết kế của mình nhanh, mà là biết mình đã mua gì, trả giá bao nhiêu, và hóa đơn nào cần xử lý tiếp theo.
-
-**Điểm chính:**
- Chi phí độ trễ cho tính công bằng chỉ 1–17% tùy thao tác, chủ yếu nằm ở thao tác ghi.
- Bộ nhớ mới là khoản đắt: 287 byte mỗi thành viên so với 99 byte của bản mốc.
- Luôn giữ một bản mốc đơn giản để có cơ sở so sánh khi thiết kế phức tạp hơn.
- Đo cả bộ nhớ phía máy chủ và độ trễ đầu-cuối qua giao thức thật, không chỉ đo trong bộ nhớ.
- Ghi rõ môi trường đo và giữ hồi quy hiệu năng luôn hiển thị trong quy trình.