Từ Redis sang Valkey: "Trinh sát" tiền di chuyển để phát hiện toàn bộ ứng dụng và kết nối
Valkey ngày càng trở nên phổ biến nhờ hiệu suất vượt trội, đặc biệt là phiên bản AWS Valkey. Bài viết này hướng dẫn quy trình "trinh sát" trước khi di chuyển, sử dụng các tính năng tích hợp sẵn của Redis như CLIENT LIST và CLIENT SETNAME để xác định chính xác các dịch vụ và mẫu dữ liệu trong môi trường phân tán phức tạp.

Abraham Lincoln: "Hãy cho tôi sáu giờ để chặt một cái cây, và tôi sẽ dành bốn giờ đầu tiên để mài rìu."
Valkey đang ngày càng trở nên phổ biến nhờ hiệu suất tăng trưởng so với phiên bản Redis cổ điển, đặc biệt là AWS Valkey. Trong khuôn khổ loạt bài viết về việc di chuyển từ Redis truyền thống sang AWS Valkey, bước quan trọng nhất chính là "trinh sát" (reconnaissance) tiền di chuyển.
Bài viết này sẽ giải thích cách sử dụng các tính năng tích hợp sẵn của Redis để xác định tất cả các dịch vụ đang kết nối đến Redis — một nhiệm vụ đầy thách thức trong hạ tầng doanh nghiệp với môi trường phân tán, nhiều ngôn ngữ lập trình và thường thiếu tài liệu.
Lịch sử ngắn gọn của dự án Valkey
Redis ra mắt phiên bản đầu tiên vào năm 2009, từ đó phát triển từ một bộ nhớ đệm key-value đơn giản thành giải pháp hỗ trợ PubSub, Stream và Database. Các nhà cung cấp đám mây lớn như AWS, GCP, Azure, Oracle đều bắt đầu cung cấp Redis dưới dạng dịch vụ được quản lý (managed service).
Tuy nhiên, từ phiên bản Redis 7.4, công ty Redis đã thay đổi giấy phép để yêu cầu các nhà cung cấp đám mây khác phải trả phí nếu cung cấp Redis dưới dạng dịch vụ quản lý. Điều này dẫn đến sự ra đời của dự án fork Valkey (https://github.com/valkey-io/valkey), được duy trì bởi cộng đồng mã nguồn mở và các nhà cung cấp đám mây dựa trên giấy phép BSD gốc.
Hiện tại, hai dự án này phát triển song song với các tính năng riêng biệt, ví dụ như đa luồng (multithreading) được thêm vào gần đây.
Trinh sát trước khi di chuyển (Pre-migration Reconnaissance)
Khi chuẩn bị di chuyển các instance Redis từ Redis Cloud sang AWS Valkey, việc đầu tiên cần làm là thu thập thông tin về mẫu truy cập dữ liệu và tất cả các ứng dụng sản xuất/người tiêu dùng (producers/consumers) của Redis.
Trong một môi trường thực tế của doanh nghiệp, bạn thường phải đối mặt với:
- Môi trường phân tán phức tạp.
- Triển khai đa tài khoản AWS, PrivateLink, VPC peering.
- Hàng tấn dịch vụ chạy bằng nhiều ngôn ngữ (Go, Java, TypeScript, Ruby...).
- Thiếu tài liệu và người chịu trách nhiệm.
Sử dụng redis-cli để xác định Client
Redis có sẵn các tính năng cho phép thu thập thông tin về client mà không cần cài đặt tác nhân của bên thứ ba.
CLIENT LIST
Lệnh CLIENT LIST trả về thông tin và thống kê về các kết nối client đến máy chủ.
Ví dụ kết quả:
id=3066004040000 addr=xx.xx.xx.135:30746 laddr=xx.20.4.124:18585 ... cmd=get user=xxx resp=2 lib-name=go-redis(,go1.24.13) lib-ver=9.17.2
Các dữ liệu quan trọng bao gồm:
- addr: Địa chỉ IP và cổng của client.
- name: Tên do client đặt (thông qua
CLIENT SETNAME). - cmd: Lệnh cuối cùng được thực hiện.
- lib-name / lib-ver: Tên và phiên bản thư viện client đang sử dụng.
Thông tin này giúp phát hiện tất cả client, phân biệt chúng theo session ID và theo dõi phiên bản thư viện.
MONITOR
Lệnh MONITOR là công cụ debug giúp luồng lại mọi lệnh được xử lý bởi Redis server.
1774787120.638084 [0 xx.xx.xx.222:40277] "get" "prefixkey:namespacea:default_data"
1774787120.649084 [0 xx.xx.xx.243:58512] "get" "prefixkey:namespace2:default_data"
Lưu ý: Việc chạy MONITOR sẽ tốn chi phí hiệu năng, nên chỉ nên dùng trong thời gian ngắn để debug.
Tính năng CLIENT NAME: Giải pháp cho Kubernetes
Trong hầu hết các trường hợp, việc map địa chỉ IP đến các pod/container là khả thi. Tuy nhiên, có một trường hợp khó khăn: Redis chạy trên RedisLabs (bên ngoài AWS account), trong khi các ứng dụng chạy trong cụm Kubernetes.
Do lưu lượng mạng đi qua node K8s, tất cả các pod trên cùng một node sẽ có chung một địa chỉ IP khi kết nối tới Redis. Điều này khiến việc xác định chính xác ứng dụng nào đang truy cập trở nên bất khả thi nếu không dùng node affinity.
Đây là lúc tính năng CLIENT SETNAME phát huy tác dụng. Tính năng này (có sẵn từ Redis 2.6.9) cho phép gán một tên cho kết nối hiện tại. Tên này sẽ hiển thị trong kết quả của lệnh CLIENT LIST.
Việc đặt tên cho các kết nối là một cách tốt để debug các rò rỉ kết nối (connection leaks) do lỗi ứng dụng.
Viết công cụ theo dõi và phân tích
Để trực quan hóa dữ liệu, ta có thể xây dựng một công cụ dựa trên Python sử dụng giao thức RESP để hiển thị thông tin dưới dạng bảng:
┌────────────────┬─────────────────┬───────────────────────┬─────────┬─────────┬──────────────────────────────────┬─────┐
│ Client IP │ Name │ Lib │ Lib Ver │ User │ Full Key │ GET │
├────────────────┼─────────────────┼───────────────────────┼─────────┼─────────┼──────────────────────────────────┼─────┤
│ 10.xx.xx.173 │ service1-writer │ go-redis(,go1.24.13) │ 9.17.2 │ xxxx │ prefixkey:namespace1:default_data│ 1 │
│ 10.xx.xx.149 │ service2-reader │ go-redis(,go1.24.13) │ 9.17.2 │ default │ prefixkey:namespace1:default_data│ 1 │
...
Công cụ này cho phép theo dõi theo thời gian thực các thao tác trên Redis server và xác định ai là người thực hiện.
Instrument Client với ClientName
Bạn cần cấu hình Redis SDK để đặt tên cho client. Ví dụ với Go:
rdb := redis.NewClient(&redis.Options{
Addr: "REDIS_HOST:REDIS_PORT",
Password: "REDIS_PASSS",
DB: 0,
ClientName: "service1-writer",
})
Hoặc ở mức độ thấp hơn với Python và giao thức RESP:
def set_client_name(sock, client_name):
"""Gán tên client cho kết nối Redis hiện tại."""
if not client_name:
return
send_command(sock, "CLIENT", "SETNAME", client_name)
response = read_line(sock)
if not response.startswith("+OK"):
raise ConnectionError(f"CLIENT SETNAME failed: {response}")
Các thách thức khi trinh sát
Thách thức 1: Quá nhiều kết nối
Khi instance Redis được sử dụng bởi nhiều dịch vụ, danh sách kết nối có thể quá dài. Nếu bạn chỉ quan tâm đến một tập hợp con các khóa (key) có tiền tố nhất định, hãy sửa đổi công cụ monitor để lọc theo tiền tố khóa đó. Điều này giúp thu hẹp phạm vi phân tích.
Thách thức 2: Phiên bản client quá cũ
Đây là vấn đề quan trọng. Các thư viện client SDK quá cũ có thể không hỗ trợ các tính năng mới hoặc giao thức của Valkey. Nếu bạn chỉ thay đổi endpoint URL trong cấu hình mà không nâng cấp thư viện, ứng dụng sẽ gặp lỗi kết nối hoặc lệnh RESP.
Lời khuyên: Nâng cấp và đồng bộ hóa phiên bản client lên SDK Redis mới nhất được hỗ trợ trước khi di chuyển.
Tổng kết bước trinh sát
Sau khi nâng cấp tất cả mã nguồn client lên phiên bản thư viện mới nhất (ví dụ: go-redis v9.18.0) và thêm tên client vào các phiên Redis, bạn sẽ có được cái nhìn rõ ràng:
- Các phiên bản thư viện đã được cập nhật và đồng bộ.
- Tên client và tất cả kết nối có thể theo dõi chính xác.
- Đã xác định đầy đủ tất cả writer/reader cần di chuyển sang AWS Valkey.
- Hiểu rõ mẫu truy cập dữ liệu (đọc/ghi vào kho khóa).
Với những thông tin này, bạn đã sẵn sàng để lập kế hoạch chi tiết cho quá trình di chuyển thực tế trong bài viết tiếp theo.
Bài viết liên quan

Phần mềm
Anthropic ra mắt Claude Opus 4.7: Nâng cấp mạnh mẽ cho lập trình nhưng vẫn thua Mythos Preview
16 tháng 4, 2026

Công nghệ
Qwen3.6-35B-A3B: Quyền năng Lập trình Agentic, Nay Đã Mở Cửa Cho Tất Cả
16 tháng 4, 2026

Công nghệ
Spotify thắng kiện 322 triệu USD từ nhóm pirate Anna's Archive nhưng đối mặt với bài toán thu hồi
16 tháng 4, 2026
