Bối cảnh: Cuộc tháo chạy khỏi Redis lúc 2 giờ sáng
2 giờ 15 phút sáng, chuông điện thoại reo dồn dập. Không phải cảnh báo sập database, mà là email hỏa tốc từ team compliance: toàn bộ cụm Redis trên staging lẫn production phải dừng sử dụng khẩn cấp do thay đổi bản quyền sang RSALv2/SSPL. Với hệ thống phục vụ hơn 40.000 người dùng hoạt động đồng thời (CCU), bài toán open-source compliance lúc nửa đêm thực sự khiến cả team toát mồ hôi.
Cứu cánh thực tế nhất lúc đó là Valkey. Dự án này trực thuộc Linux Foundation, nhận tài trợ từ AWS, Google Cloud, Oracle và do chính đội ngũ core maintainer kỳ cựu của Redis phát triển. Valkey giữ trọn giấy phép BSD 3-Clause và tương thích tuyệt đối với tập lệnh Redis 7.2.4. Các client phổ biến như redis-py, ioredis hay predis đều kết nối bình thường mà không cần sửa dù chỉ một dòng code backend.
Team mình vận hành cụm Fedora Server cho các microservice nội bộ. Rất may, đội ngũ Fedora đã đưa Valkey vào official repo từ Fedora 40 để thế chỗ hoàn toàn các package Redis cũ. Nhờ vậy, kế hoạch chuyển đổi diễn ra ngay trong ca trực mà không tốn công biên dịch mã nguồn.
Cài đặt Valkey trên Fedora Server
Sau khi SSH vào máy chủ, việc cài đặt diễn ra rất nhanh vì package đã nằm sẵn trong kho phần mềm chính thức.
Kiểm tra thông tin phiên bản có sẵn trên hệ thống:
sudo dnf info valkey
Cài đặt Valkey server kèm package tương thích ngược:
sudo dnf install -y valkey valkey-compat-redis
Gói valkey-compat-redis giải quyết triệt để vấn đề legacy script. Nó tự tạo symlink chuyển hướng redis-cli sang valkey-cli và redis-server sang valkey-server. Tất cả cron job, deployment pipeline hay script backup cũ vẫn chạy trơn tru mà không cần viết lại.
Cấu hình chuẩn hóa cho môi trường Production
Không bao giờ được để nguyên default config khi đưa lên production. Theo mặc định, Valkey không đặt mật khẩu và chỉ lắng nghe trên localhost. Mở file cấu hình chính để thiết lập lại:
sudo nano /etc/valkey/valkey.conf
1. Giới hạn dải mạng và bật xác thực
Chỉ cho phép service lắng nghe trên IP private nội bộ (ví dụ: 10.0.0.15), tuyệt đối không mở ra public Internet. Đồng thời, thiết lập mật khẩu đủ mạnh:
# Lắng nghe localhost và IP private của cụm ứng dụng
bind 127.0.0.1 10.0.0.15
# Bật chế độ bảo vệ
protected-mode yes
# Port tiêu chuẩn
port 6379
# Mật khẩu dài tối thiểu 32 ký tự ngẫu nhiên
requirepass vK9#mQ2$xL8!pZ4@wE7*rT1^yU5&iO3(
2. Giới hạn RAM và thiết lập chính sách Eviction
Để Valkey tự do ngốn RAM là nguyên nhân phổ biến nhất khiến tiến trình bị Linux OOM Killer tiêu diệt. Trên server 16GB RAM chạy chung một vài worker, bạn nên dành riêng một hạn mức an toàn:
# Giới hạn cứng 4GB RAM cho cache
maxmemory 4gb
# Tự động giải phóng key ít dùng nhất khi chạm trần bộ nhớ
maxmemory-policy allkeys-lru
3. Cấu hình cơ chế Persistence
Với cache session người dùng, bạn cần duy trì dữ liệu sống sót qua các lần restart. Hãy kết hợp RDB định kỳ và cơ chế Append-Only File (AOF):
# Kích hoạt AOF để ghi log từng thao tác ghi
appendonly yes
appendfilename "appendonly.aof"
# Ghi đĩa định kỳ mỗi giây một lần để đảm bảo IOPS không bị nghẽn
appendfsync everysec
4. Tinh chỉnh Kernel OS
Valkey khi khởi động trên Linux thường ghi log cảnh báo về bộ nhớ ảo và độ trễ. Hai vấn đề hay gặp nhất là thiếu vm.overcommit_memory và tính năng Transparent Huge Pages (THP) gây spike độ trễ từ 0.5ms lên hàng chục ms. Xử lý triệt để bằng cách nạp tham số kernel:
# Tránh lỗi fork tiến trình khi lưu snapshot RDB
echo 'vm.overcommit_memory = 1' | sudo tee /etc/sysctl.d/99-valkey.conf
sudo sysctl --system
Vô hiệu hóa Transparent Huge Pages bằng một systemd service khởi động cùng OS:
sudo nano /etc/systemd/system/disable-thp.service
Nội dung cấu hình service:
[Unit]
Description=Disable Transparent Huge Pages (THP) for Valkey
DefaultDependencies=no
After=sysinit.target local-fs.target
Before=valkey.service
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag'
[Install]
WantedBy=basic.target
Kích hoạt service:
sudo systemctl daemon-reload
sudo systemctl enable --now disable-thp.service
5. Phân quyền Firewall cho subnet nội bộ
Fedora Server mặc định bật firewalld. Cần mở port 6379 riêng cho subnet máy chủ ứng dụng (ví dụ dải 10.0.0.0/24) thay vì mở rộng toàn hệ thống:
sudo firewall-cmd --permanent --zone=internal --add-source=10.0.0.0/24
sudo firewall-cmd --permanent --zone=internal --add-port=6379/tcp
sudo firewall-cmd --reload
Kiểm thử và đánh giá hiệu năng thực tế
Khởi động dịch vụ và kích hoạt tự chạy khi reboot:
sudo systemctl enable --now valkey
sudo systemctl status valkey
Khi service báo trạng thái active (running), tiến hành kiểm tra kết nối trực tiếp bằng CLI:
valkey-cli -a "vK9#mQ2$xL8!pZ4@wE7*rT1^yU5&iO3("
Thử nghiệm các thao tác cơ bản:
127.0.0.1:6379> PING
PONG
127.0.0.1:6379> SET auth_token:user_4892 "active_session" EX 3600
OK
127.0.0.1:6379> GET auth_token:user_4892
"active_session"
127.0.0.1:6379> TTL auth_token:user_4892
(integer) 3594
Theo dõi chỉ số bộ nhớ và độ trễ
Kiểm tra tình trạng cấp phát RAM bằng lệnh:
127.0.0.1:6379> INFO memory
Tập trung vào 3 giá trị trọng yếu:
- used_memory_human: Bộ nhớ thực tế dữ liệu đang chiếm dụng.
- maxmemory_human: Hạn mức trần (ở ví dụ này là 4GB).
- mem_fragmentation_ratio: Tỷ lệ phân mảnh. Con số chuẩn nằm trong khoảng 1.0 đến 1.3; nếu vượt 1.5, RAM vật lý đang bị phân mảnh nhiều.
Đo đạc lưu lượng thực tế ứng dụng đẩy vào thông qua chế độ thống kê trực tiếp:
valkey-cli -a "vK9#mQ2$xL8!pZ4@wE7*rT1^yU5&iO3(" --stat
Công cụ này in ra thông số mỗi giây: số kết nối client, tổng số key, lượng RAM và số request/giây (RPS). Khi benchmark thử bằng lệnh valkey-benchmark -q -n 100000 -c 50, node đạt xấp xỉ 92.000 RPS với latency p99 dưới 0.8ms. Việc chuyển đổi từ Redis sang Valkey hoàn tất nhanh gọn, giải quyết triệt để rủi ro bản quyền mà hệ thống vẫn duy trì hiệu năng mượt mà.

