Di chuyển từ Redis sang Valkey 8 trong môi trường Production: Nhân bản không downtime & Kiểm tra độ trễ

Hướng dẫn này trình bày chi tiết việc di chuyển các tác vụ Redis 7 quan trọng sang Valkey 8, tập trung vào các chiến lược không gián đoạn, xác thực hiệu suất và sẵn sàng sản xuất. Động lực chính cho việc di chuyển này thường là các vấn đề về cấp phép (Redis thay đổi sang RSALv2/SSPLv1) và mong muốn tận dụng một giải pháp thay thế mã nguồn mở, do cộng đồng phát triển. Valkey, là một nhánh của Redis, duy trì khả năng tương thích giao thức và cung cấp một lộ trình nâng cấp trực tiếp.

Tổng quan kiến trúc & Khả năng tương thích

Valkey 8 là một nhánh trực tiếp của Redis 7.2.4, duy trì khả năng tương thích RESP (REdis Serialization Protocol) hoàn toàn. Điều này đảm bảo các thư viện client được thiết kế cho Redis 7.x sẽ hoạt động mà không cần sửa đổi đối với một phiên bản Valkey 8. Các cấu trúc dữ liệu cốt lõi, lệnh và cơ chế sao chép vẫn giống hệt nhau. Sự khác biệt chính là mô hình cấp phép (BSD 3-Clause cho Valkey) và quỹ đạo phát triển trong tương lai.

Tuân thủ Giấy phép BSD

Việc Valkey tuân thủ giấy phép BSD 3-Clause là một yếu tố quan trọng đối với các tổ chức yêu cầu cấp phép mã nguồn mở có tính cho phép. Điều này trái ngược với sự thay đổi của Redis sang RSALv2/SSPLv1, có thể gây ra những hạn chế cho các nhà cung cấp dịch vụ đám mây và phân phối thương mại. Đối với hầu hết người dùng cuối, tác động chức năng là tối thiểu, nhưng tuân thủ pháp lý là tối quan trọng.

Chiến lược di chuyển: Chuyển đổi sao chép không gián đoạn

Việc di chuyển không gián đoạn từ Redis 7 sang Valkey 8 tận dụng khả năng sao chép gốc của Redis. Chiến lược này bao gồm việc thiết lập Valkey làm bản sao của Redis primary hiện có, cho phép nó đồng bộ hóa tập dữ liệu, sau đó thăng cấp phiên bản Valkey và chuyển hướng lưu lượng truy cập.

Giai đoạn 1: Thiết lập bản sao Valkey

1. Cung cấp phiên bản Valkey: Triển khai một phiên bản Valkey 8. Đảm bảo tài nguyên phần cứng của nó (CPU, RAM, I/O mạng) ít nhất phải tương đương với Redis primary hiện tại.

2. Cấu hình sao chép: Cấu hình phiên bản Valkey để sao chép từ Redis 7 primary hiện có. Điều này đạt được bằng cách đặt chỉ thị replicaof trong valkey.conf hoặc sử dụng lệnh REPLICAOF.

   bashCopy

   # valkey.conf snippet for replica
   # Replace with your Redis primary's IP and port
   replicaof <redis_primary_ip> <redis_primary_port>
   
   # If your Redis primary requires a password
   masterauth <redis_primary_password>
   
   # Ensure AOF is enabled for durability on the Valkey replica
   appendonly yes
   appendfsync everysec
   

   Ngoài ra, thông qua valkey-cli:

   bashCopy

   # Connect to the Valkey replica
   valkey-cli -h <valkey_replica_ip> -p <valkey_replica_port>
   
   # Set it as a replica of the Redis primary
   REPLICAOF <redis_primary_ip> <redis_primary_port>
   

3. Giám sát đồng bộ hóa: Quan sát trạng thái sao chép. Lệnh INFO replication trên bản sao Valkey sẽ hiển thị master_link_status:up và master_sync_in_progress:0 sau khi đồng bộ hóa hoàn tất.

   bashCopy

   valkey-cli -h <valkey_replica_ip> -p <valkey_replica_port> INFO replication
   

Giai đoạn 2: Chiến lược ghi kép (Tùy chọn, cho các kịch bản rủi ro cao)

Đối với các ứng dụng cực kỳ nhạy cảm, giai đoạn ghi kép có thể giảm thiểu rủi ro. Điều này liên quan đến việc sửa đổi logic ứng dụng để ghi vào cả Redis primary hiện có và bản sao Valkey mới. Đọc vẫn tiếp tục từ Redis primary. Điều này đảm bảo cả hai cơ sở dữ liệu đều được cập nhật trước khi chuyển đổi.

// Example Node.js client using ioredis
import Redis from 'ioredis';

const redisPrimary = new Redis({ host: 'redis-primary', port: 6379 });
const valkeyReplica = new Redis({ host: 'valkey-replica', port: 6379 }); // This will become primary

async function dualWriteSet(key: string, value: string, ttl?: number) {
  const primaryPromise = ttl ? redisPrimary.setex(key, ttl, value) : redisPrimary.set(key, value);
  const replicaPromise = ttl ? valkeyReplica.setex(key, ttl, value) : valkeyReplica.set(key, value);

  // Execute writes concurrently, handle potential errors
  await Promise.allSettled([primaryPromise, replicaPromise]).then(results => {
    results.forEach((res, index) => {
      if (res.status === 'rejected') {
        console.error(`Dual-write failed for ${index === 0 ? 'Redis Primary' : 'Valkey Replica'}:`, res.reason);
        // Implement robust error handling: logging, alerting, fallback
      }
    });
  });
}

async function readFromPrimary(key: string) {
  return redisPrimary.get(key);
}

// Usage
// await dualWriteSet('user:123:session', JSON.stringify({ token: 'abc' }), 3600);
// const sessionData = await readFromPrimary('user:123:session');

Giai đoạn 3: Chuyển đổi

1. Dừng ghi vào Redis Primary: Tạm dừng ghi ứng dụng vào Redis primary. Điều này đảm bảo không có dữ liệu mới nào được ghi vào primary cũ mà sẽ không được sao chép sang Valkey. Đối với các hệ thống có lưu lượng truy cập cao, đây có thể là một khoảng thời gian rất ngắn hoặc liên quan đến một trang bảo trì ngắn.

2. Xác minh độ trễ sao chép: Xác nhận INFO replication trên bản sao Valkey hiển thị master_repl_offset khớp với repl_backlog_first_byte_offset trên Redis primary, cho thấy độ trễ bằng 0.

3. Thăng cấp Valkey: Trên bản sao Valkey, thực thi REPLICAOF NO ONE. Điều này thăng cấp nó thành một primary.

   bashCopy

   valkey-cli -h <valkey_replica_ip> -p <valkey_replica_port> REPLICAOF NO ONE
   

4. Chuyển hướng lưu lượng truy cập: Cập nhật cấu hình ứng dụng (ví dụ: biến môi trường, khám phá dịch vụ) để trỏ đến Valkey primary mới.

5. Tiếp tục ghi: Kích hoạt lại ghi ứng dụng.

6. Giám sát: Giám sát chặt chẽ hiệu suất Valkey, tỷ lệ lỗi và tình trạng ứng dụng.

Giai đoạn 4: Dọn dẹp sau di chuyển

1. Ngừng hoạt động Redis Primary cũ: Sau khi Valkey đã được xác nhận ổn định (ví dụ: sau 24-48 giờ hoạt động ổn định), Redis primary cũ có thể được ngừng hoạt động.
2. Cấu hình Valkey High Availability: Nếu sử dụng Sentinel hoặc Cluster, hãy cấu hình chúng cho Valkey primary mới.

Phân mảnh bộ nhớ & jemalloc

Redis (và do đó Valkey) sử dụng jemalloc làm bộ cấp phát bộ nhớ mặc định trên Linux. jemalloc được tối ưu hóa cho các ứng dụng đa luồng, đồng thời và thường thể hiện khả năng sử dụng bộ nhớ và đặc tính phân mảnh tốt hơn so với glibc's malloc.

Phân mảnh bộ nhớ có thể dẫn đến used_memory_rss (Kích thước tập hợp cư trú) cao hơn đáng kể so với used_memory (kích thước dữ liệu thực tế), cho thấy RAM bị lãng phí.

# Check memory fragmentation ratio
valkey-cli INFO memory | grep frag_ratio
# Example output: mem_fragmentation_ratio:1.05
# A ratio > 1.5 might indicate significant fragmentation.

Nếu jemalloc không được sử dụng (ví dụ: trên macOS hoặc nếu được biên dịch rõ ràng mà không có nó), hoặc nếu phân mảnh trở thành một vấn đề, hãy xem xét:

• Khởi động lại Valkey: Khởi động lại hoàn toàn có thể thu hồi bộ nhớ bị phân mảnh. Đây là phương sách cuối cùng cho các hệ thống sản xuất.

• ACTIVEDEFRAG: Valkey 6+ (và do đó Valkey 8) hỗ trợ chống phân mảnh chủ động. Kích hoạt nó trong valkey.conf:

  bashCopy

  # valkey.conf snippet for active defragmentation
  activedefrag yes
  active-defrag-ignore-bytes 100mb # Start defrag if fragmentation exceeds 100MB
  active-defrag-threshold-lower 10 # Start defrag if fragmentation ratio exceeds 10%
  active-defrag-threshold-upper 100 # Stop defrag if fragmentation ratio exceeds 100% (i.e., 2x memory usage)
  active-defrag-cycle-min 5 # Min percentage of CPU time to use for defrag
  active-defrag-cycle-max 75 # Max percentage of CPU time to use for defrag
  

Điểm chuẩn độ trễ (p99 dưới 100k OPS)

Điểm chuẩn là rất quan trọng để xác thực các đặc tính hiệu suất của Valkey phù hợp hoặc vượt trội so với Redis 7 dưới tải giống như sản xuất. Chúng ta sẽ sử dụng valkey-benchmark (có chức năng giống hệt redis-benchmark).

Thiết lập

• Máy khách: Máy chuyên dụng, tách biệt với máy chủ Valkey, với đủ CPU và băng thông mạng.
• Máy chủ Valkey: Được cung cấp đủ tài nguyên.
• Mạng: Mạng có độ trễ thấp, băng thông cao giữa máy khách và máy chủ.

Lệnh điểm chuẩn

Chúng ta sẽ nhắm mục tiêu các hoạt động phổ biến: SET, GET, LPUSH, LRANGE (danh sách nhỏ), HSET, HGET.

# Benchmark SET operations: 100,000 requests, 100 concurrent clients, 100-byte value
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 -d 100 SET

# Benchmark GET operations: 100,000 requests, 100 concurrent clients
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 GET

# Benchmark LPUSH operations: 100,000 requests, 100 concurrent clients, 100-byte value
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 -d 100 LPUSH mylist

# Benchmark LRANGE operations (small list, e.g., 10 elements): 100,000 requests, 100 concurrent clients
# First, populate a list:
# valkey-cli LPUSH mylist item1 item2 ... item10
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 LRANGE mylist 0 9

# Benchmark HSET operations: 100,000 requests, 100 concurrent clients, 100-byte value
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 -d 100 HSET myhash field value

# Benchmark HGET operations: 100,000 requests, 100 concurrent clients
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 HGET myhash field

# Comprehensive benchmark with latency distribution
# This will output p50, p90, p99, p99.9 latencies
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 --csv --latency-dist

Giải thích kết quả

Tập trung vào phân phối độ trễ, đặc biệt là p99 và p99.9. Đối với các ứng dụng tương tác, độ trễ p99 lý tưởng nhất là dưới 5ms, và đối với các dịch vụ backend, dưới 20ms, tùy thuộc vào SLA. Thông lượng (số yêu cầu mỗi giây) cũng quan trọng, nhưng độ trễ thấp ổn định thường quan trọng hơn đối với trải nghiệm người dùng.

So sánh trực tiếp các số liệu này giữa các phiên bản Redis 7 và Valkey 8 của bạn dưới các cấu hình tải giống hệt nhau. Mong đợi sự khác biệt không đáng kể, vì công cụ cốt lõi là như nhau.

Danh sách kiểm tra di chuyển

Các vấn đề và khắc phục sự cố trong sản xuất

1. Lỗi liên kết sao chép (master_link_status:down):

   • Nguyên nhân: Sự cố kết nối mạng, tường lửa chặn, IP/cổng replicaof không chính xác, không khớp masterauth.
   • Khắc phục:
     • Xác minh khả năng truy cập mạng (ping, telnet <ip> <port>).
     • Kiểm tra các quy tắc tường lửa trên cả primary và replica.
     • Đảm bảo replicaof và masterauth (nếu được sử dụng) được cấu hình chính xác trong valkey.conf hoặc thông qua valkey-cli.
     • Kiểm tra nhật ký Redis primary để tìm các lần thử/lỗi kết nối.

2. Tỷ lệ phân mảnh bộ nhớ cao (mem_fragmentation_ratio > 1.5):

   • Nguyên nhân: Các mẫu tác vụ liên quan đến việc xóa khóa thường xuyên, cập nhật đối tượng lớn hoặc bộ cấp phát không phải jemalloc.
   • Khắc phục:
     • Bật activedefrag yes trong valkey.conf và điều chỉnh các tham số (active-defrag-threshold-lower, active-defrag-cycle-min).
     • Nếu jemalloc không được sử dụng, hãy đảm bảo Valkey được biên dịch với nó (mặc định trên Linux).
     • Xem xét chiến lược khởi động lại luân phiên nếu chống phân mảnh chủ động không đủ và used_memory_rss cực kỳ cao.

3. Lỗi kết nối client sau khi chuyển đổi:

   • Nguyên nhân: Ứng dụng vẫn trỏ đến Redis primary cũ, sự cố bộ nhớ đệm DNS, cổng/IP Valkey không chính xác, Valkey không lắng nghe trên giao diện dự kiến.
   • Khắc phục:
     • Xác minh cấu hình ứng dụng trỏ đến Valkey primary mới.
     • Xóa bộ nhớ đệm DNS nếu sử dụng tên máy chủ.
     • Kiểm tra valkey.conf để tìm chỉ thị bind và port. Đảm bảo Valkey đang lắng nghe trên giao diện mạng chính xác.
     • Sử dụng netstat -tulnp | grep valkey trên máy chủ Valkey để xác nhận các cổng đang lắng nghe.

4. Hoạt động chậm / Độ trễ cao trên Valkey:

   • Nguyên nhân: Tài nguyên phần cứng không đủ (CPU, RAM, mạng), tranh chấp I/O đĩa (nếu AOF/RDB thường xuyên đồng bộ hóa với đĩa chậm), các lệnh chạy dài, số lượng client đồng thời cao.
   • Khắc phục:
     • Giám sát valkey-cli INFO cpu, INFO memory, INFO clients.
     • Kiểm tra valkey-cli SLOWLOG GET 128 để tìm các lệnh chậm. Tối ưu hóa các truy vấn ứng dụng.
     • Đảm bảo tính bền vững AOF/RDB được cấu hình cho bộ nhớ nhanh (ví dụ: SSD).
     • Mở rộng tài nguyên phiên bản Valkey.
     • Xem xét maxmemory và các chính sách loại bỏ. Nếu maxmemory bị đạt và loại bỏ quá mạnh, nó có thể gây ra các đột biến độ trễ.

5. Không nhất quán dữ liệu trong quá trình ghi kép:

   • Nguyên nhân: Bản chất không đồng bộ của ghi kép, phân vùng mạng, lỗi trong một đường dẫn ghi không được xử lý chính xác.
   • Khắc phục:
     • Triển khai cơ chế xử lý lỗi và thử lại mạnh mẽ cho cả hai lần ghi.
     • Ghi nhật ký sự khác biệt và thiết lập cảnh báo.
     • Xem xét một công việc đối chiếu định kỳ so sánh dữ liệu giữa Redis và Valkey trong giai đoạn ghi kép, đặc biệt đối với dữ liệu quan trọng.
     • Đối với dữ liệu thực sự quan trọng, việc xác thực dữ liệu đầy đủ sau khi chuyển đổi có thể là cần thiết.

Câu hỏi thường gặp

Q1: Valkey có phải là một thay thế trực tiếp cho Redis 7.x không?

A1: Có, Valkey 8 là một nhánh trực tiếp của Redis 7.2.4 và duy trì khả năng tương thích RESP hoàn toàn. Các thư viện client và mã ứng dụng hiện có được thiết kế cho Redis 7.x sẽ hoạt động mà không cần sửa đổi đối với một phiên bản Valkey 8. Sự khác biệt chính là mô hình cấp phép và quản trị phát triển trong tương lai.

Q2: Sự khác biệt chính giữa Redis 7 và Valkey 8 từ góc độ kỹ thuật là gì?

A2: Về mặt chức năng, chúng gần như giống hệt nhau ở mức cơ sở 7.2.4. Valkey 8 kế thừa tất cả các tính năng, lệnh và cấu trúc dữ liệu từ Redis 7.2.4. Sự khác biệt kỹ thuật chính sẽ xảy ra trong các phiên bản tương lai khi mỗi dự án phát triển độc lập. Đối với mục tiêu di chuyển, trải nghiệm vận hành thực tế là như nhau.

Q3: Valkey xử lý tính bền vững (AOF/RDB) như thế nào so với Redis?

A3: Valkey xử lý tính bền vững giống hệt Redis. Nó hỗ trợ cả cơ chế bền vững RDB (chụp nhanh) và AOF (Append-Only File), bao gồm định dạng RDB-AOF hỗn hợp. Các chỉ thị cấu hình như appendonly yes, appendfsync, save và no-appendfsync-on-rewrite hoạt động chính xác như trong Redis.

Q4: Tôi có thể sử dụng Redis Sentinel hoặc Redis Cluster với Valkey không?

A4: Có. Valkey hoàn toàn tương thích với Redis Sentinel để có tính sẵn sàng cao và Redis Cluster để phân mảnh. Bạn có thể cấu hình thiết lập Sentinel hoặc Cluster hiện có của mình để quản lý các phiên bản Valkey bằng cách đơn giản cập nhật cấu hình để trỏ đến các tệp nhị phân và cổng của Valkey. Không yêu cầu thay đổi đối với các giao thức Sentinel hoặc Cluster.

Q5: Phương pháp được khuyến nghị để giám sát các phiên bản Valkey là gì?

A5: Các công cụ và thực hành giám sát Redis tiêu chuẩn áp dụng trực tiếp cho Valkey. Điều này bao gồm:

• Đầu ra lệnh INFO (ví dụ: INFO memory, INFO replication, INFO clients).
• SLOWLOG GET để xác định các lệnh chậm.
• Các bộ xuất Prometheus (ví dụ: valkey_exporter hoặc redis_exporter) để thu thập số liệu.
• Bảng điều khiển Grafana để trực quan hóa.
• Tổng hợp nhật ký và cảnh báo cho các sự kiện quan trọng. Các số liệu và định dạng nhật ký giống hệt Redis 7.