Valkey tròn 1 năm: Nhánh fork cộng đồng đã vượt Redis như thế nào

• Redis Inc đã làm lung lay niềm tin của cộng đồng với quyết định đóng mã nguồn (chuyển sang SSPL), nhưng cộng đồng nhà phát triển đã tập hợp quanh nhánh fork Valkey, tiếp tục đóng góp và đổi mới rất sôi động
• Redis 8.0 đã quay lại với mô hình mã nguồn mở, và nhà sáng lập Antirez cũng trở lại để tham gia các tính năng mới và tối ưu hóa, cho thấy cả hai bên đều đang phát triển rất nhanh
• Theo kết quả benchmark mới nhất, Valkey 8.1.1 trong môi trường 8vCPU có hiệu năng SET cao hơn 37% so với Redis 8.0, đồng thời độ trễ p99 cũng ngắn hơn (hiệu năng GET cũng tốt hơn 16%)
• Với các kỹ thuật tinh chỉnh thực chiến như IO thread/core pinning, Valkey đạt mức tăng thông lượng hơn 3 lần trong môi trường đa luồng và giảm độ trễ xuống mức tối thiểu
• Bài viết cũng chia sẻ benchmark gần với môi trường sử dụng thực tế cùng các mẹo tuning, đồng thời hướng dẫn cách diễn giải kết quả benchmark và áp dụng trong vận hành thực tế

---

Redis đóng mã nguồn và sự xuất hiện của Valkey

• Một năm trước, Redis Inc (trước đây là Garantia Data) đã làm xấu đi mối quan hệ tin cậy với cộng đồng khi thay đổi giấy phép mã nguồn mở (áp dụng SSPL)
• Open fork Valkey ra đời như một giải pháp cho vấn đề này, và đã trở thành một tài sản công nghệ được dùng rộng rãi trong hệ thống phân tán, cache và xử lý dữ liệu thời gian thực
• Phía Redis sau đó cũng nỗ lực khôi phục niềm tin bằng việc Antirez (nhà sáng lập) trở lại, tăng cường hiệu năng/tính năng và đưa Redis 8.0 quay lại mã nguồn mở

Valkey 8.1 vs Redis 8.0: So sánh hiệu năng

• Benchmark SET trên cùng điều kiện: instance AWS c8g.2xl 8vCPU, item 1KB / keyspace 3M / 500 kết nối
  • Valkey 8.1.1: 999.8K RPS (p99 0.8ms)
  • Redis 8.0: 729.4K RPS (p99 0.99ms)
  • Valkey cao hơn 37% ở SET, 16% ở GET, và nhanh hơn 30% ở SET p99, 60% ở GET p99
• Khi áp dụng 6 IO thread, Valkey tăng từ 239K → 678K RPS (2.8 lần), p99 giảm từ 1.68ms → 0.93ms (44%)
• Redis cũng tăng từ 235K → 563K RPS với IO thread, p99 giảm từ 1.35ms → 0.84ms (40%)

Tác động của đa luồng và tuning lõi CPU

• IO thread bắt đầu cho hiệu quả rõ rệt từ 3 luồng trở lên, và Valkey tạo khoảng cách lớn hơn Redis từ sau mốc 4 luồng
• Khi giới hạn lõi IRQ (interrupt) còn 2 lõi và cố định Redis/Valkey vào 6 lõi còn lại (pinning), hiệu năng tiếp tục tăng thêm
  • Valkey: 832K → 999.8K RPS (pinning lõi/IRQ, sử dụng 80% CPU)
  • Việc tách lõi IRQ và lõi ứng dụng giúp cải thiện hiệu quả cache và giảm tail latency xuống mức tối thiểu
  • Có cung cấp ví dụ thực tế dùng Docker với cpuset-cpus, --io-threads v.v.

Tái hiện benchmark và mẹo thực chiến

• Sử dụng instance AWS Graviton4 (c8g.2xlarge) mới nhất cùng cluster placement group
• Đạt hiệu năng tối đa bằng core pinning / tách IRQ / điều chỉnh số kết nối (khoảng 400~500)
• Kích thước keyspace / item cũng cần tuning; giá trị nhỏ và keyspace nhỏ giúp tăng tỷ lệ hit của L3 cache
• Khuyến nghị tích cực sử dụng các công cụ benchmark đa luồng như valkey-benchmark hoặc rpc-perf (công cụ nền Rust gần với môi trường thực tế hơn)

  docker run --network="host" --rm --cpuset-cpus="2-7" \  
  valkey/valkey:8.0.1 valkey-benchmark \  
  -h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \  
  -r 3000000 --threads 6 -d 1024  
  

Giới hạn và lưu ý khi đo hiệu năng

• Kết quả benchmark có thể khác với môi trường vận hành thực tế

  • Workload thực tế có nhiều yếu tố kết hợp như tỷ lệ trộn SET:GET, biến động tải, mục tiêu TPS, độ trễ mạng v.v.
  • Khi số kết nối tăng đột biến, cũng quan sát thấy độ trễ hàng đợi tăng, throughput giảm và tail latency tăng
  • Kết quả có thể thay đổi rất lớn tùy theo công cụ/tùy chọn benchmark, topology mạng v.v.

Các cột mốc tăng trưởng chính và sự phát triển của cộng đồng

Dự án Valkey đã phát triển rất tích cực trong năm qua ở nhiều khía cạnh khác nhau

• Trên GitHub và các nền tảng khác, nhiều nhà phát triển và doanh nghiệp đã hợp tác để bổ sung tính năng, sửa lỗi và cải thiện bảo mật
• Cũng đầu tư vào tài liệu hóa và hỗ trợ người dùng, qua đó giảm rào cản cho người dùng mới
• Trong quá trình vận hành dự án, ra quyết định minh bạch và bỏ phiếu cộng đồng được nhấn mạnh

Giá trị công nghệ và trong ngành

Valkey có những điểm mạnh sau

• Không bị ràng buộc bởi giấy phép, nên là lựa chọn hấp dẫn cho nhà cung cấp dịch vụ đám mây và các công ty web quy mô lớn
• Có mức độ tương thích cao với Redis nên việc migration cũng dễ dàng
• Là dự án phát triển theo định hướng cộng đồng, nên có thể phản ánh nhiều nhu cầu khác nhau và cập nhật nhanh, liên tục

Kết luận và hàm ý

• Valkey chỉ sau 1 năm kể từ khi fork Redis đã cho thấy thành quả vượt Redis về công nghệ, hiệu năng và cộng đồng
• Các kỹ thuật tuning thực chiến như IO thread, tách lõi CPU/IRQ và điều chỉnh kết nối, cùng công cụ phù hợp, là yếu tố then chốt
• Hiệu năng không tự động xuất hiện; việc tối ưu liên tục theo hệ thống/workload/hạ tầng là điều bắt buộc
• Trong môi trường dịch vụ thực tế, cần tiếp cận theo hướng thực dụng: không chỉ dựa vào con số benchmark mà phải tự kiểm thử trong nhiều tình huống khác nhau

[ethanhur]

Redis đúng là đã đưa ra nhiều quyết định sai lầm, nhưng nhìn cảnh gấu biểu diễn còn người huấn luyện nhận tiền thì cũng thật đáng tiếc.

[kgcrom]

Đây là tài liệu tóm tắt những cải tiến đã được thực hiện trong Valkey 8, được đăng trong nhóm Facebook "Redis User Group".
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

Xem cùng với nội dung trên thì có lẽ sẽ giúp bạn dễ hiểu hơn.

[ndrgrd]

Thật ra không hẳn là Valkey đã làm gì đó... mà là bên kia tự lụn bại thôi...

[GN⁺]

Ý kiến Hacker News

• Tôi rất vui khi thấy Valkey đạt được những tiến bộ ấn tượng trong mảng I/O threading, và gần đây cũng bắt đầu đưa vào những thay đổi thú vị nhất; xin gửi lời cảm ơn lớn tới các cộng tác viên của Valkey. Tuy vậy, tôi nghĩ bài viết này có xu hướng gây hiểu nhầm phần nào. Ban đầu trong Redis, kiến trúc shared nothing là một triết lý rất quan trọng, và chính tôi là người đã trực tiếp đưa I/O threading vào từ năm 2020. Không làm tổn hại tinh thần của shared nothing, tôi đã đưa vào một cấu trúc mà tại thời điểm trả về từ event loop, do các syscall write(2)/read(2) có thể rất chậm, nên chỉ phần I/O được xử lý song song bằng N thread trong trạng thái zero contention, rồi ngay sau đó quay lại mô hình single-thread. Tôi ghi nhận và cảm ơn đội ngũ Valkey đã tiếp tục phát triển hệ thống này. Hệ thống đó vốn đã hoạt động từ lâu, và thành thật mà nói tôi thấy không thoải mái khi báo chí chỉ phóng đại những dữ liệu thực tế không thay đổi. Những tính năng kiểu này trên thực tế hấp dẫn hơn với người dùng doanh nghiệp hoặc các nhà cung cấp đám mây như Amazon, Google hơn là đa số người dùng Redis thông thường. Trừ khi buộc phải xử lý tải cực lớn hay rất nhiều người dùng cùng lúc, còn không thì trong hầu hết trường hợp Redis dùng CPU thấp nên chẳng cần bật những thứ này. Gần đây khi phát triển vector set data type trong Redis, chúng tôi đang lấy threading làm mặc định, và việc ghi vector set qua VADD cũng có thể thực hiện theo kiểu threaded. Các cấu trúc dữ liệu như HNSW mang đến thời gian hằng số rất lớn lần đầu tiên trong lịch sử Redis, nên bản thân không gian thiết kế đã khác đi. Trước đây tôi cũng đã từng triển khai hỗ trợ thread cho module. Việc có dùng thread hay không là một quyết định tùy bối cảnh.
  • Đây là một góc nhìn tinh tế nhưng không kéo được click
  • Tôi có cảm giác những bài chỉ trích kiểu này cứ mỗi tháng lại lên trang chủ HN, và tôi luôn muốn ủng hộ antirez. Tôi đồng ý với luận điểm kỹ thuật, nhưng tôi nghĩ những lời chỉ trích như vậy thường liên quan nhiều hơn đến kiểu tall poppy syndrome cổ điển — nhắm vào một người đã đạt được thành công lớn — hơn là nội dung cụ thể. Bạn không thể kiểm soát phản ứng của người khác, nên có lẽ lành mạnh hơn nếu xem những bài chỉ trích này như một sự thừa nhận gián tiếp rằng thành tựu của bạn rất lớn. Tôi cũng rất cảm kích vì đã được kết nối với bạn trên LinkedIn Xem về tall poppy syndrome
• Tôi nhớ antirez từng tuyên bố sẽ đưa Redis trở lại open source bài liên quan. Trước đây Node.js từng suýt sụp đổ vì vụ fork Io.js nhưng sau đó cộng đồng đã phục hồi được. Tôi tự hỏi Redis có thể hồi phục theo cách đó không. Ngày xưa tôi dùng Redis khá nhiều nhưng vài năm gần đây không theo dõi sát diễn biến cộng đồng nữa
  • Lần cuối tôi kiểm tra thì Redis vẫn yêu cầu CLA. Điều đó có nghĩa họ vẫn giữ quyền độc quyền để có thể đóng mã nguồn lại bất cứ lúc nào. Nếu người đóng góp phải đồng ý điều khoản như vậy thì không có lý do gì để tin rằng họ sẽ không lặp lại chuyện cũ
  • Redis được phát hành theo AGPL, còn Valkey theo giấy phép BSD (BSD là giấy phép Redis từng dùng trước đây). Cả hai đều là giấy phép open source chính thức, nhưng BSD tự do hơn nhiều
  • Thành thật mà nói, 99% người dùng không quan tâm ai sở hữu nó, miễn là có một kho key-value miễn phí chạy ổn là được. Xét về kinh doanh, Redis ở vị thế khá đặc biệt: nó cung cấp rất nhiều tính năng nhưng người dùng thực tế chỉ dùng 5%. Họ chẳng quan tâm các tính năng phức tạp như Sentinel hay Streams. Khi muốn thu phí, người dùng có nhiều lựa chọn: "đơn giản là không dùng nữa", "chuyển sang đối thủ", "tự làm đúng những tính năng mình cần", hoặc "fork phiên bản open source cuối cùng rồi tự bảo trì để tiết kiệm chi phí". So với PostgreSQL, một phiên bản đơn giản của Redis (hash map + network interface) khá dễ tự xây, nên với nhiều doanh nghiệp thì fork hoặc tự làm còn là lựa chọn tốt hơn
  • Tôi cũng thấy giờ có lẽ đã quá muộn. Sau cú xoay chính sách đột ngột của Redis, với tôi Redis giờ là đối tượng không đáng tin, và từ nay Valkey sẽ là lựa chọn mặc định. Bị lừa một lần thì sẽ không tin lần hai
  • Tôi đặt câu hỏi rằng sau những gì Redis đã làm thì làm sao còn có thể tin tưởng được nữa
• Tôi nghĩ Valkey nên có mặt trong package manager mặc định của các bản phân phối. Ví dụ khi muốn cài trên GitHub Action runner thì cứ phải thêm key rồi cập nhật bản phân phối mỗi lần, khá phiền
  • Không rõ là đang thiếu ở bản phân phối nào. Theo dữ liệu repology, nó đã có trong nixpkgs, Arch, Ubuntu, Fedora, Debian, EPEL v.v. Chỉ là trên Debian thì từ 13 hoặc 12+backports trở lên
  • Tham khảo thêm là trên Arch Linux, Valkey đã thay thế Redis rồi
  • Nếu trong CI, việc đầu tiên sau khi kéo container image về là cài đủ thứ, thì có lẽ tự tạo image riêng sẽ tốt hơn
• Tôi rất mừng khi thấy những thay đổi này diễn ra và Valkey tiếp tục tiến triển tốt. Mong Redis sớm biến mất
  • Giọng điệu châm biếm rằng open source là vì các công ty độc quyền; các hyperscaler như AWS đang kiếm hàng trăm triệu đô từ Redis nhưng các lập trình viên và người đóng góp thực tế lại không được hưởng lợi. Vì thế các startup làm database nên ngay từ đầu đi theo fair source — giấy phép có điều khoản chống hyperscaler — để mã nguồn thì ai cũng có thể dùng thoải mái, nhưng nếu AWS hay Google muốn tung ra sản phẩm managed service thì phải trả tiền. Với Redis và Elasticsearch vốn đã xuất phát bằng giấy phép cực kỳ permissive, đó là số phận rất khó đảo ngược
• Gần đây có nhiều dự án dotnet chuyển sang thương mại hóa. Với lập trình viên, những thay đổi như vậy có thể giống một cú rug pull — một màn đổi chính sách đột ngột làm mất niềm tin. Bầu không khí này có thể ảnh hưởng xấu đến sự lan rộng của các thư viện open source dotnet khác
  • Trong .NET, xu hướng thương mại hóa này không phải chuyện mới xảy ra gần đây; vốn dĩ nó luôn có khuynh hướng gắn với freeware/open-core và kinh doanh
• Tôi đã nghe về Valkey từ năm ngoái, và rất vui khi thấy nó vẫn đang phát triển tốt
• Tôi tò mò không biết Valkey có cung cấp thư viện client riêng không. Hiện tôi đang dùng cả Redis/Redis Cluster trên môi trường GCP, cả với MemoryStore lẫn môi trường tự quản lý. Thư viện C chính thức khá thất vọng khi dùng Redis Cluster+TLS, nên tôi phải dùng client không chính thức là hiredis-cluster (https://github.com/Nordix/hiredis-cluster). Tôi cũng không mấy hài lòng với Memorystore của GCP. Đang cân nhắc chuyển sang Scylla
  • Có một fork chính thức tên là libvalkey, kết hợp hiredis và hiredis-cluster, do chính các maintainer hiện tại của hiredis/hiredis-cluster quản lý Xem libvalkey
• Giờ Redis đã đổi chính sách, tôi tự hỏi liệu Valkey và Redis có thể nói chuyện để hợp nhất lại không
  • Cần chỉ ra rằng đây không phải quay về giấy phép cũ, mà là chuyển sang AGPL, nên không phải một cú quay đầu thực sự
• Chia sẻ liên kết đến một bài giải thích rất hay về FUD (sợ hãi, bất định và nghi ngờ) liên quan đến GPL như nhiều người dự đoán bài liên quan
  • Tôi thấy lập luận trong bài rằng giấy phép copyleft tự do hơn là một cách nói hơi đơn giản. Càng có nhiều nghĩa vụ thì ở một khía cạnh nào đó càng ít tự do hơn, nên việc tranh luận kiểu nào "tự do" hơn thực ra có chiều sâu hơn thế
• Tôi dùng Redis trong hàng chục ứng dụng. Vì AWS cung cấp Valkey với giá giảm nên tôi đã thử dùng từ 2 tháng trước và cũng không cảm nhận khác biệt hiệu năng. Nhưng rồi Valkey đột ngột treo cứng; AWS vẫn nhận là nó đang chạy nhưng kết nối thì hoàn toàn đứt. Hơn 12 tiếng vẫn không khôi phục được, rồi còn tái diễn lần nữa. AWS điều tra suốt 2 tuần nhưng không tìm ra nguyên nhân. Từ đó tôi thấy khó có thể dùng Valkey cho môi trường mission-critical. Sau đó tôi thay bằng Redis với cùng workload thì không còn vấn đề
  • Có lẽ đó là vấn đề của AWS. Chúng tôi cũng từng gặp chuyện tương tự với cụm RDS postgres production. Phản hồi mạng bị treo, có hỗ trợ enterprise của AWS nhưng cuối cùng vẫn phải tự phục hồi backup để dựng cụm mới, mất 4 tiếng. Từ đó chúng tôi tránh các dịch vụ encapsulated của AWS và chuyển sang EC2 thông thường với replication, snapshot, sao chép S3 v.v.
  • Cũng có thể là vấn đề vận hành của AWS; tôi mới chỉ tự chạy Redis thôi, nhưng chưa chắc đó là lỗi của chính Valkey
  • Tôi thắc mắc vì sao bạn không tự dựng instance Valkey
  • Không rõ bạn đã dùng loại instance nào, hỏi để tham khảo thôi