Posted inDatabase

Valkey: Cài Đặt, Cấu Hình và Migrate từ Redis Sau Khi Đổi License

Database tutorial - IT technology blog
Database tutorial - IT technology blog

Ngày Hóa Đơn Redis Của Chúng Tôi Trở Thành Câu Hỏi Pháp Lý

Tháng 3 năm 2024. Nhóm chúng tôi đang tiến hành review định kỳ hạ tầng thì tin tức ập đến: Redis Ltd. đã đổi license của Redis từ BSD sang dual license — RSALv2 và SSPL. Với hầu hết các team nhỏ tự host Redis, điều này không ảnh hưởng gì. Nhưng chúng tôi không phải team nhỏ. Chúng tôi đang xây dựng nền tảng SaaS, và đột nhiên đội pháp lý bắt đầu đặt những câu hỏi khó chịu về ý nghĩa của SSPL đối với sản phẩm của mình.

Sáu tháng sau: ba môi trường đã migrate xong hoàn toàn — development, staging và production. Đây là toàn bộ những gì đã hoạt động, những gì không, và những điều chúng tôi ước mình đã biết từ đầu.

Chuyện Gì Thực Sự Đã Xảy Ra với License của Redis

Tóm tắt ngắn gọn: Redis Ltd. cho rằng các nhà cung cấp đám mây lớn (AWS, Azure, GCP) đang kiếm lợi khổng lồ từ Redis mà không đóng góp gì lại cho dự án. Giải pháp của họ là chuyển sang SSPL — license tương tự MongoDB đã dùng năm 2018 — về cơ bản yêu cầu bất kỳ công ty nào cung cấp Redis như một dịch vụ phải open-source toàn bộ stack của mình.

SSPL được thiết kế cố tình rất rộng. Nếu Redis là một thành phần trong sản phẩm thương mại của bạn, đội pháp lý sẽ mất nhiều tuần để xác định liệu cách sử dụng cụ thể của bạn có kích hoạt các điều khoản hay không. Sự mơ hồ đó có chi phí thực sự: quyết định kỹ thuật bị chặn lại, phí luật sư tốn kém, và cuối cùng vẫn phải migrate. Redis 7.2.x là phiên bản cuối cùng dưới BSD. Tất cả phiên bản sau đều nằm dưới license mới.

Nguyên Nhân Gốc Rễ: Tại Sao Các Giải Pháp Cũ Không Còn Phù Hợp

Mãi dùng Redis 7.2 nghe có vẻ hấp dẫn cho đến khi bạn nghĩ kỹ hơn. Các bản vá bảo mật, tính năng cấu trúc dữ liệu mới và tính tương thích của client library đều tiến lên phía trước. Đứng yên ở 7.2 nghĩa là bạn tích lũy technical debt với mỗi release cycle bỏ qua — và các chu kỳ đó không bao giờ dừng lại.

Chúng tôi cũng xem xét các giải pháp thay thế tồn tại trước khi Valkey xuất hiện, và không có giải pháp nào thực sự phù hợp:

  • Memcached thực sự có license BSD và nhanh, nhưng nó chỉ là pure key-value cache. Chúng tôi phụ thuộc nhiều vào sorted set cho leaderboard, stream cho event queue, và pub/sub cho thông báo real-time. Migrate sang Memcached đồng nghĩa với việc phải viết lại phần lớn logic ứng dụng.
  • KeyDB fork từ Redis và bổ sung multi-threading. Snapchat đã mua lại, open-source nó, và từ đó đến nay khá im ắng. Các bản phát hành thưa thớt, hoạt động cộng đồng yếu, và đây không phải canh bạc chúng tôi muốn đặt vào một dependency quan trọng.
  • Dragonfly áp dụng cách tiếp cận hoàn toàn khác về mặt nội tại — tái thiết kế lớp data structure, tuyên bố hiệu quả bộ nhớ tốt hơn. Hứa hẹn trên lý thuyết, nhưng còn quá mới nên có các khoảng cách tương thích lệnh Redis đòi hỏi phải thay đổi ứng dụng từ phía chúng tôi.

Sự thay đổi license, kết hợp với những hạn chế của các giải pháp thay thế hiện có, chính là lý do Linux Foundation can thiệp nhanh đến vậy.

Valkey vs. Các Giải Pháp Khác: Lý Do Chúng Tôi Chọn Nó

Valkey fork từ Redis 7.2.4 — bản phát hành cuối cùng dưới BSD — ngay sau khi license thay đổi. Linux Foundation hiện đang quản trị nó, với AWS, Google, Oracle và Ericsson là các contributor tích cực. Mô hình quản trị này rất quan trọng: không có nhà cung cấp đơn lẻ nào kiểm soát roadmap.

Lựa chọn License Tương thích API Cộng đồng
Redis 7.4+ RSALv2/SSPL Đầy đủ Lớn, do nhà cung cấp dẫn dắt
Valkey 8.x BSD 3-Clause Đầy đủ (7.2) Đang phát triển, có tổ chức hỗ trợ
KeyDB BSD Gần như đầy đủ Nhỏ
Dragonfly BSL 1.1 Một phần Nhỏ
Memcached BSD Không có Ổn định, tối giản

Thay thế trực tiếp, phát triển tích cực, license BSD, quản trị bởi tổ chức không có sự mơ hồ SSPL. Sự kết hợp đó đã giúp chúng tôi kết thúc cuộc thảo luận khá nhanh.

Cài Đặt Valkey

Ubuntu/Debian qua APT

curl -fsSL https://packages.valkey.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/valkey-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/valkey-archive-keyring.gpg] https://packages.valkey.io/apt $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/valkey.list

sudo apt update && sudo apt install valkey -y
sudo systemctl enable valkey --now

# Xác nhận
valkey-cli PING  # phải trả về PONG

Docker Compose (Cách Chúng Tôi Thực Tế Dùng)

services:
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped
    ports:
      - "6379:6379"
    volumes:
      - valkey_data:/data
      - ./valkey.conf:/usr/local/etc/valkey/valkey.conf
    command: valkey-server /usr/local/etc/valkey/valkey.conf

volumes:
  valkey_data:

Cấu Hình

Valkey đọc cùng định dạng cấu hình như Redis. Đã có sẵn redis.conf? Đổi tên thành valkey.conf, trỏ Valkey vào đó, và nó hoạt động mà không cần chỉnh sửa gì. Cấu hình production của chúng tôi như sau:

# Bộ nhớ
maxmemory 2gb
maxmemory-policy allkeys-lru

# Persistence — RDB + AOF
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

# Bảo mật
requirepass your_strong_password_here
bind 127.0.0.1

# Hiệu năng
tcp-backlog 511
hz 10
lazyfree-lazy-eviction yes

Migrate từ Redis: Ba Phương Pháp

Phương Pháp 1: RDB Dump (Tốt Nhất cho Maintenance Window Đã Lên Kế Hoạch)

Redis và Valkey dùng chung định dạng RDB cho 7.x. Đây là phương pháp chúng tôi dùng cho các môi trường không phải production:

# Trên server Redis của bạn — kích hoạt lưu nền
redis-cli BGSAVE

# Kiểm tra khi nào xong
redis-cli LASTSAVE

# Sao chép dump sang server Valkey mới
scp /var/lib/redis/dump.rdb user@new-server:/data/valkey/dump.rdb

# Khởi động Valkey — nó tự động load dump
sudo systemctl start valkey

# Xác nhận số lượng key khớp
valkey-cli DBSIZE

Phương Pháp 2: Dựa trên Replication (Zero Downtime)

Khi SLA uptime không cho phép maintenance window, hãy chạy Valkey như một replica của Redis primary trước. Đây là phương pháp chúng tôi dùng cho cutover production:

# Trên server Valkey — kết nối như replica của Redis hiện có
valkey-cli REPLICAOF redis-primary-ip 6379

# Theo dõi replication cho đến khi bắt kịp
valkey-cli INFO replication
# Tìm: master_sync_in_progress:0 và master_link_status:up

# Cập nhật connection string của ứng dụng để trỏ vào Valkey
# Sau đó thăng cấp Valkey thành primary
valkey-cli REPLICAOF NO ONE

# Tắt Redis cũ
sudo systemctl stop redis

Phương Pháp 3: Migrate Key Có Chọn Lọc (Hữu Ích để Dọn Dẹp)

Migration cũng là thời điểm tốt để xóa các key cũ thay vì mang chúng theo:

#!/bin/bash
# Migrate các pattern key cụ thể từ Redis sang Valkey
# Lưu ý: thay KEYS bằng SCAN trên dataset lớn để tránh blocking
REDIS_HOST="old-redis-host"
VALKEY_HOST="new-valkey-host"

for key in $(redis-cli -h $REDIS_HOST KEYS "session:*"); do
  ttl=$(redis-cli -h $REDIS_HOST TTL "$key")
  dump=$(redis-cli -h $REDIS_HOST DUMP "$key")
  if [ "$ttl" -gt 0 ]; then
    valkey-cli -h $VALKEY_HOST RESTORE "$key" $((ttl * 1000)) "$dump"
  else
    valkey-cli -h $VALKEY_HOST RESTORE "$key" 0 "$dump"
  fi
done

Thay Đổi Ứng Dụng Cần Thiết

Đang dùng redis-py trong Python? Chỉ một thay đổi: host. Vậy là xong:

# Trước
import redis
client = redis.Redis(host='old-redis-host', port=6379, password='secret')

# Sau — chỉ thay đổi host
import redis
client = redis.Redis(host='valkey-host', port=6379, password='secret')

# Hoặc cài package valkey để dependency rõ ràng hơn
# pip install valkey
import valkey
client = valkey.Valkey(host='valkey-host', port=6379, password='secret')

Package Python valkey là fork được duy trì của redis-py với API giống hệt. Người dùng Node.js với ioredis hoặc node-redis: tương tự — cập nhật connection string là xong.

Một điều dễ bỏ qua: các monitoring script và health check gọi redis-cli PING cần chuyển sang valkey-cli PING. Tên binary thay đổi. Lệnh thì không.

Sau Sáu Tháng: Những Gì Chúng Tôi Thực Sự Thấy

Mức sử dụng bộ nhớ thấp hơn khoảng 5–8% so với Redis 7.2 tương đương dưới khối lượng công việc của chúng tôi. Cải tiến I/O threading của Valkey 8.0 tạo ra sự khác biệt đáng đo được cho các service pub/sub-heavy của chúng tôi — throughput tốt hơn trên server đa nhân, không cần thay đổi cấu hình từ phía chúng tôi.

Tính tương thích lệnh rất vững chắc trên mọi thứ chúng tôi dùng: string, hash, sorted set, stream, pub/sub, Lua scripting và transaction. Không có xung đột nào trong sáu tháng lưu lượng production.

Trong quá trình migration, chúng tôi cần chuyển đổi một số export cấu hình CSV sang JSON để cập nhật các script triển khai. Chúng tôi dùng toolcraft.app/vi/tools/data/csv-to-json cho việc đó — nó chạy hoàn toàn trên trình duyệt, nên dữ liệu cấu hình không rời khỏi máy của bạn. Rất hữu ích cho công việc hạ tầng khi không thể dán các giá trị nhạy cảm vào một dịch vụ web không rõ nguồn gốc.

Tổng thời gian trên ba môi trường: khoảng hai ngày. Phần lớn thời gian đó dành cho kiểm thử và cập nhật monitoring dashboard, không phải di chuyển dữ liệu thực sự. Migration dữ liệu của mỗi môi trường mất chưa đến một giờ. Việc cutover production dựa trên replication có zero downtime.

Valkey Có Phù Hợp với Setup của Bạn Không?

Đang tự host Redis 7.2 hoặc cũ hơn với sản phẩm thương mại xây dựng trên đó? Hãy giải quyết câu hỏi SSPL trước khi luật sư của bạn nêu ra vào thời điểm không phù hợp. Valkey mang đến con đường rõ ràng: API giống nhau, bảo trì tích cực, license BSD và quản trị mà không có nhà cung cấp đơn lẻ nào kiểm soát.

Đã dùng Redis Enterprise hoặc dịch vụ quản lý như ElastiCache với license đã được xử lý? Chi phí migration có thể không xứng đáng — hãy giữ nguyên. Nhưng với Redis open-source tự host trong sản phẩm thương mại, Valkey là lối thoát trực tiếp nhất hiện có. Chúng tôi dự kiến một tuần làm integration. Trên thực tế, mỗi môi trường chỉ mất khoảng một buổi chiều.

Share:
Tags: