REDIS DOCUMENT - WordPress.comREDIS DOCUMENT | DUCDT - PMT 4 1. Giới thiệu Redis is an open source, BSD licensed, avanced key-value cache and store. Redis được biết đến

REDIS DOCUMENT | DUCDT - PMT

1

REDIS DOCUMENT


2

MỤC LỤC 1. Giới thiệu .......................................................................................................................... 4

2. Các tính năng chính .......................................................................................................... 4

2.1. Data Model ................................................................................................................. 4

2.2. Persistance .................................................................................................................. 6

2.3. Replication .................................................................................................................. 7

2.4. Transaction.................................................................................................................. 8

2.5. Distributed lock ........................................................................................................ 10

2.6. LRU eviction of keys ................................................................................................ 12

2.7. Automatic failover .................................................................................................... 12

3. Redis Cluster Specification ............................................................................................ 12

3.1. Main Properties and rationales of the design ............................................................ 12

3.1.1. Goal ................................................................................................................ 12

3.1.2. Implement Subset ........................................................................................... 13

3.1.3. Cluster and server roles in Redis Cluster protocal ......................................... 13

3.1.4. Write safety ..................................................................................................... 13

3.1.5. Availability ..................................................................................................... 13

3.1.6. Performance .................................................................................................... 14

3.2. Overview main component ....................................................................................... 14

3.2.1. Keys distributed model ................................................................................... 14

3.2.2. Keys hash tags ................................................................................................ 14

3.2.3. Cluster nodes attributes .................................................................................. 15

3.2.4. The Cluster Bus .............................................................................................. 15

3.2.5. Cluster topology ............................................................................................. 15

3.2.6. Node handshake .............................................................................................. 15

3.3. Redirection and Resharding ...................................................................................... 16

3.3.1. MOVED Redirection ...................................................................................... 16


3

3.3.2. Cluster live configuration ............................................................................... 16

3.3.3. ASK redirection .............................................................................................. 16

3.3.4. Clients first connection and handling of redirections ..................................... 16

3.3.5. Multiple keys operations ................................................................................ 16

3.3.6. Scaling reads using slave nodes ..................................................................... 16

3.4. Failt Tolerance .......................................................................................................... 17

3.4.1. Node heartbeat and gossip messages .............................................................. 17

3.4.2. Heartbeat packages content ............................................................................ 17

3.4.3. Failure detection ............................................................................................. 17

3.5. Configuration handling , propagration and failover ................................................. 18

3.5.1. Cluster current epoch ...................................................................................... 18

3.5.2. Configuration epoch ....................................................................................... 18

3.5.3. Slave rank ....................................................................................................... 18

3.5.4. Masters reply to slave vote request ................................................................ 18

3.5.5. Practical example of configuraton epoch usefulness during partitions .......... 18

3.5.6. Hash slot configuration propagation .............................................................. 18

3.5.7. UPDATE messages, a closer look .................................................................. 18

3.5.8. How node rejoin cluster .................................................................................. 18

3.5.9. Replica Migration ........................................................................................... 19

3.5.10. Replica Migration Algorithms ........................................................................ 19

3.5.11. configEpoch conflicts resolution algorithms .................................................. 19

3.5.12. Node reset ....................................................................................................... 19

3.6. Publish/Subscribe ..................................................................................................... 20

4. Tham khảo ...................................................................................................................... 20


4

1. Giới thiệu

Redis is an open source, BSD licensed, avanced key-value cache and store.

Redis được biết đến như một data structures server. Bởi vì nó có thể chứa các kiểu

dữ liệu: strings, hashs, lists, sets, sorted sets, bitmaps và hyperloglogs. Có thể

thực hiện các thao tác trên các kiểu dữ liệu đó như cộng chuỗi string, tăng giá trị

trong hash, thêm phần tử vào list, lấy phần tử xếp hạng cao nhất trong sorted set...

Để đạt hiệu năng vượt trội, Redis làm việc với tập dữ liệu in-memory. Ngoài ra,

Redis còn hỗ trợ lưu dữ liệu xuống ổ đĩa hoặc ghi các lệnh vào log.

Redis hỗ trợ cơ chế sao chép bất đồng bộ trên master-slave, transactions, LRU

eviction, automatic failover... (được trình bày ở phần II).

Redis hỗ trợ các ngôn ngữ lập trình tốt nhất: C, C#, Clojure, Dart, Erlang, Go,

Haskell, Java, Lua, Node.js, PHP, Python, Ruby, Rust,..

Redis được viết bằng ANCI C và hoạt động trên phần lớn ở các hệ thống POSIX như

Linux, *BSD, OS X. Trong đó, Linux được khuyến khích chọn để deploying. Redis

không hỗ trợ Windows, nhưng Microsoft đã phát triển Redis on Windows.

2. Các tính năng chính

2.1. Data Model

Redis hỗ trợ key-values cache và lưu trữ dữ liệu.

Redis thực chất là một data structures server, hỗ trợ nhiều kiểu dữ liệu.

a) Redis keys

Redis keys là binary-safe. Mỗi chuỗi nhị phân có thể coi sử dụng như một key. Chính

vì thế, chuỗi rỗng là một key hợp lệ.

Một số lưu ý:

Không sử dụng key quá dài. Tốn bộ nhớ và chi phí so sánh key.

Không nên sử dụng key quá ngắn. Key ngắn tiết kiệm một chút ít bộ nhớ

nhưng có thể gây khó đọc và hiểu ý nghĩa của key. Sử dụng key

“user:1000:followers” thay cho “u1000flw”.

Cố gắng gán với một schema. Ví dụ một schema: “object-type:id” . Sử dụng

dấu chấm và ngạch nối để liên kết các trường như "comment:1234:reply-to".


5

Kích thước tối đa của key là 512 MB.

b) Redis values

i. Binary-safe strings

Là kiểu dữ liệu cơ bản nhất liên kết với một Redis key. Kích thước lớn nhất không

quá 512 MB.

ii. Lists

Redis Lists được cài đặt bằng Linked List.

Thao tác thêm một phần tử vào List luôn thực hiện trong một thời gian cố định

(Độ phức tạp thời gian O(1)).

Truy xuất một phần tử bất kỳ tốn khối lượng công việc tỷ lệ thuận với chỉ số

truy cập của phần tử trong List.

Lợi thế của việc cài đặt này là việc thêm phần tử vào một danh sách rất dài

trong khoảng thời gian ngắn.

Capped lists (danh sách giới hạn)

Giữ lại những phần tử mới nhất trong danh sách.

Chặn các hoạt động trên danh sách

Trong một vài trường hợp, các lệnh thực thi không trả về kết quả mong muốn (hoặc

không có kết quả). Người dùng lặp lại việc gửi các lệnh này để lấy kết quả. Hiện

tượng này là polling.

Tự động tạo và hủy key

Khi thêm một phần tử vào tập hợp kiểu dữ liệu, nếu key không tồn tại, một tập hợp

kiểu dữ liệu rỗng được tạo trước khi thêm thêm phần tử.

Khi xóa phần tử khỏi tập hợp kiểu dữ liệu, nếu giá trị còn lại rỗng, key tự động bị

hủy.

Gọi lệnh chỉ đọc (read-only) luôn cho cùng một kết quả với key rỗng.

iii. Hashes

Redis Hashes đại diện cho đối tượng (objects), các trường của nó không có giới hạn.

Hash lưu trữ đối tượng với các trường dữ liệu của nó.

Đối với những hashes nhỏ (vài phần tử với giá trị nhỏ) được mã hóa đặc biệt tăng

hiệu quả lưu trữ.

iv. Sets


6

Redis Sets là tập hợp các phần tử không có thứ tự. Các phần tử có giá trị duy nhất,

không lặp lại.

v. Sorted Sets

Sorted Sets là kiểu dữ liệu có sự pha trộn của Set và Hash.

Sorted Sets lưu các phần tử duy nhất, không lặp lại (giống Sets).

Sorted Sets liên kết mỗi phần tử với một giá trị kiểu floating point gọi là score (giống

Hashes).

Sorted Sets sắp xếp theo luật:

A > B nếu A.score > B.score

A > B nếu A.score = B.score và chuỗi A đứng trước B trong thứ tự từ điển.

Sorted Sets score có thể cập nhật bất kỳ lúc nào (ZADD để cập nhật).

vi. Bit arrays (Bitmaps)

Bit arrays có lợi thế lớn khi sử dụng rất ít bộ nhớ khi lưu trữ một số loại thông tin. Ví

dụ như 512 MB có thể lưu trữ hơn 4 tỷ UserID.

vii. HyperLogLogs

Là cấu trúc dữ liệu xác suất sử dụng trong sắp xếp để đếm các phần tử phân biệt.

Thông thường, công việc đếm các phần tử này yêu cầu bộ nhớ bằng với số phần tử,

bởi vì chúng ta phải xem xét sự xuất hiện của phần tử và tránh đếm nó nhiều lần.

Trong trường hợp xấu nhất, Redis sử dụng 12 KB. Hoặc ít hơn rất nhiều nếu HLL chỉ

chứa một vài phần tử.

HLL trong Redis được encode như String. Sử dụng GET để serialize một HLL và

SET để deserizlize trở lại.

2.2. Persistance

Redis cung cấp các tùy chọn:

The RDB persistance tạo một snapshot của tập dữ liệu trong những khoảng thời

gian nhất định. Tùy chọn này thích hợp với tập dữ liệu nhỏ, nhưng có thể không

phục hồi đầy đủ dữ liệu khi gặp sự cố bất ngờ (sau khi thực hiện các thao tác trên

tập dữ liệu, server down trước khi snapshot).

The AOF persistance ghi mọi thao tác làm thay đổi dữ liệu truyền tới server. Nó

được dùng khi khởi động lại server, khôi phục dữ liệu gốc. Redis có khả năng ghi


7

log ngầm khi dữ liệu quá lớn.

Tùy từng trường hợp, có thể không sử dụng cơ chế persistance. Khi đó, dữ liệu sẽ

luôn trong bộ nhớ in-memory.

Có khả năng kết hợp RDB và AOF. Khi server khởi động lại, AOF được chọn để

khôi phục tập dữ liệu gốc, vì nó đảm bảo dữ liệu hoàn chỉnh nhất.

2.3. Replication

Tính năng đồng bộ dữ liệu giữa master và slave của nó.

Một số thông tin cần lưu ý:

Redis Replication cho phép slave Redis server sao chép chính xác dữ liệu của

master server.

Redis sử dụng cơ chế sao chép bất đồng bộ. Bắt đầu từ phiên bản Redis 2.8,

slave sẽ định kỳ nhận thông tin về lượng dữ liệu trong replication stream.

Một master có thể có nhiều slave.

Slave có khả năng chấp nhận kết nối từ nhiều slave khác.

Redis replication ở phía master là non-blocking. Điều này có nghĩa là master

sẽ tiếp tục xử lý trong khi các slave tiến hành đồng bộ hóa ban đầu.

Redis replication ở phía slave là non-blocking. Trong khi thực hiện đồng bộ

hóa ban đầu, slave có thể xử lý dữ liệu trên tập dữ liệu cũ. Tuy nhiên, bạn có

thể trả về lỗi cho client nếu replication stream không hoạt động. Sau khi đồng

bộ, dữ liệu cũ phải được xóa và thay vào bằng tập dữ liệu mới. Slave đóng

mọi kết nối trong suốt quá trình này.

Replication có thể được dùng cho việc mở rộng. để có nhiều slave cho các

truy vấn chỉ đọc. Hoặc chỉ đơn giản phục vụ lưu dữ liệu dự phòng.

Có khả năng sử dụng để giảm chi phí trên các master ghi đầy đủ dữ liệu xuống

đĩa.

Sao chép an toàn khi master tắt chế độ persistance

Khi master gặp sự cố và tự động khởi động lại. Vì master đang tắt chế dộ persistance

nên dữ liệu sau khi khởi động là rỗng. Các slave đang chứa dữ liệu của master (dữ

liệu trước khi có sự cố) tái tạo dữ liệu rỗng trên master. Việc này đã phá hủy bản sao

của dữ liệu.

Với dữ liệu quan trọng, sao chép không sử dụng persistance hãy tắt chế độ tự khởi


8

động lại của master.

Redis replication hoạt động thế nào?

Nếu cài đặt một slave, khi kết nối nó sẽ gửi một lệnh SYNC (không quan trọng là lần

kết nối đầu tiên hay kết nối lại).

Master sẽ bắt đầu lưu ngầm và đưa các lệnh sẽ làm thay đổi dữ liệu vào buffer. Sau

khi lưu hoàn tất, master chuyển file dữ liệu cho slave. Dữ liệu được lưu xuống ổ đĩa,

sau đó tải lên bộ nhớ (RAM). Master gửi tiếp buffer chứa tập lệnh.

Slave có thể tự kết nối lại khi kết nối master-slave hư hại. Nếu master và slave kết

nối lại với nhau, một lệnh đồng bộ đầy đủ (full sync) luôn được thực thi. Tuy nhiên,

từ phiên bản Redis 2.8 đã có thể đồng bộ lại từng phần dữ liệu.

Diskless replication

Một lệnh resynchronize yêu cầu tạo một file RDB trên ổ đĩa, tải lên và gửi cho các

slave. Điều này đôi khi trở nên bất tiện (ổ đĩa xử lý chậm...).

Phiên bản Redis 2.8 hỗ trợ cơ chế diskless replication. Tiến trình con gửi RDB qua

mạng không thông qua qua trung gian (lưu trên ổ đĩa). Master chia nhỏ file và gửi

cho slave.

Phục vụ nhiều slave đồng thời có vẻ như không thể thực hiện. Vì khi truyền dữ liệu

RDB, slave khác không thể attach. Tuy nhiên, có một số mẹo trong trường hợp này.

Khi slave đầu tiên muốn sao chép, ta chờ một vài giây cho các slave khác gửi yêu cầu

tới. Sau đó gửi song song các file dữ liệu được chia nhỏ tới các slave cùng một lúc.

Khi quá trình gửi RDB bị chấm dứt đột ngột, tiến trình con báo cáo slave đang sao

chép dữ liệu và tiếp tục thực hiện sao chép.

2.4. Transaction

Redis cho phép thực hiện một nhóm các lệnh trong một thao tác duy nhất, với 2 điều

kiện:

Tất cả các lệnh trong transaction là tuần tự và được thực hiện tuần tự. Nó đảm

bảo không có bất kỳ yêu cầu nào được thực thi trong quá trình thực thi một

Redis transaction. Điều này đảm bảo lệnh được thực thi như một thao tác biệt

lập.

Hoặc tất cả các lệnh trong transaction không được thực hiện. Vì thế, một

Redis transaction là không thể phân tách.


9

Bắt đầu từ version 2.2, Redis đảo bảo thêm 2 điều trên. Hình thức optimistic locking

phần nào giống cơ chế check-and-set (CAS).

Cách sử dụng

MULTI để bắt đầu transaction (đưa các lệnh vào queue)

Các lệnh đọc ghi …

EXEC thực thi transaction (thực thi các lệnh trong queue)

Lỗi bên trong transaction

Trong một transaction có thể gặp phải 2 lỗi:

Trước khi lệnh EXEC được gọi: sai tên hàm, thiếu tham số hoặc bộ nhớ vượt

quá mức cho phép...

Redis sẽ trả về lỗi và hủy transaction.

Sau khi lệnh EXEC được gọi (lỗi khi thực thi): thực thi một thao tác sai kiểu

giá trị trên key (thao tác trên kiểu list-LPOP và string-SET trên cùng một khóa

sẽ gây lỗi).

Redis thực thi tất cả các lệnh ngay cả khi một vài lệnh gặp lỗi. Redis không hỗ trợ cơ

chế roll back.

Discarding the command queue

DISCARD dùng để hủy bỏ transaction. Không cỏ lệnh nào được thực thi và kết nối

trở về trạng thái bình thường.

Optimistic locking using check-and-set

Lệnh WATCH (key) được sử dụng để cung cấp cơ chế check-and-set (CAS) cho

Redis Transaction.

Key được theo dõi phát hiện sự thay đổi dữ liệu. Nếu có ít nhất một key được theo

dõi bị thay đổi dữ liệu trước lệnh EXEC, transaction bị hủy bỏ và trả về kết quả null

báo hiệu thất bại.

Một số lưu ý:

WATCH có thể gọi nhiều lần, mỗi lần WATCH một hoặc nhiều key.

Key expire sau khi gọi WATCH, EXEC vẫn được thực hiện.

Sau khi EXEC thực thi, mọi key được UNWATCH.


10

2.5. Distributed lock

Distributed lock được sử dụng để chia sẻ tài nguyên theo cách loại trừ lẫn nhau. Tức

là tại một thời điểm, chỉ có một đối tượng kiểm soát được tài nguyên.

Redlock là thuật toán thích hợp để cài đặt Distributed Lock Manager. Các cài đặt

thuật toán này cùng với ngôn ngữ lập trình tương ứng:

Redlock-rb (Ruby implementation). There is also a fork of Redlock-rb that

adds a gem for easy distribution and perhaps more.

Redlock-py (Python implementation).

Redlock-php (PHP implementation).

Redsync.go (Go implementation).

Redisson (Java implementation).

Redis::DistLock (Perl implementation).

Redlock-cpp (Cpp implementation).

Redlock-cs (C#/.NET implementation).

Safety and Liveness guarantees

Safety property: Mutual Exclution. Tại bất kỳ một thời điểm, chỉ có 1 client có

thể giữ lock.

Liveness property A: Deadlocks free. Cuối cùng, luôn có thể thu được lock,

ngay cả khi nó đã bị giữ bởi một client khác bị crash (time-out).

Liveness property B: Failt Tolerance. Khi nào phần lớn Redis nodes còn hoạt

động, client có khả năng acquire và release lock.

Why failover based implementations are not enough

Cách đơn giản nhất để Redis lock tài nguyên là tạo một key K trong thực thể đó. Key

K được tạo có thời gian sống giới hạn, sử dụng cơ chế Redis Expire. Vì thế, tài

nguyên có thể được release bằng nhiều cách (khi hết thời gian sống của key K,..). Khi

client muốn release tài nguyên, nó xóa key K.

Có vẻ như cách này hoạt động ổn. Nhưng nó sẽ gặp sự cố khi có tình huống:

Client A giữ lock tài nguyên T ở master.

Master bị crash trước khi key K được ghi xuống slave.

Slave được đưa lên làm master (không có key K).

Client B giữ lock tài nguyên T giống Client A.

https://github.com/antirez/redlock-rb

https://github.com/leandromoreira/redlock-rb

https://github.com/SPSCommerce/redlock-py

https://github.com/ronnylt/redlock-php

https://github.com/hjr265/redsync.go

https://github.com/mrniko/redisson

https://github.com/sbertrang/redis-distlock

https://github.com/jacket-code/redlock-cpp

https://github.com/kidfashion/redlock-cs


11

Tình huống trên đã vi phạm cơ chế an toàn (Safety Violation).

Correct implementation with single instance

Trước khi giải quyết vấn đề cài đặt trên một instance, ta xử lý việc tạo và hủy key K.

Tạo key K với lệnh:

SET resource_name random_values NX PX 30000

Đoạn lệnh trên tạo key K nếu chưa tồn tại (NX - Not Exist) và thời gian sống 30000

ms (PX - Expire time in miniseconds).

Giá trị random_values dùng để hủy key K. Với lệnh DEL thông thường, bất kỳ client

nào cũng có thể hủy key nếu biết tên của nó.

Hủy key bằng đoạn script:

if redis.call("get",KEYS[1]) == ARGV[1] then

return redis.call("del",KEYS[1])

else

return 0

end

KEY[1] là tên kên key K

ARGV[1] là random_value.

Key K được xóa khi client gửi đúng random_value. Tức là chỉ client tạo key K mới

có thể hủy.

The Redlock algorithm

Thay vì chỉ lock trên master giữ tài nguyên, ta sẽ lock trên tất cả các master.

Lấy thời gian hiện tại T0 theo miliseconds.

Thử lock trên tất cả các instance với cùng giá trị key và random_value. Trong

suốt quá trình này, client sử dụng time-out để tránh liên lạc quá lâu với những

node không hoạt động và chuyển sang node tiếp theo.

Client tính thời gian trôi qua để thu giữ lock bằng cách trừ thời gian hiện tại

với thời gian T0 ở bước 1. Chỉ khi client có khả năng lock phần lớn các

instance (ít nhất 3) và tổng thời gian trôi qua để thu giữ lock nhỏ hơn thời gian

lock có hiệu lực thì lock đó coi như đã được giữ.

Nếu client thất bại khi thu giữ lock, nó unlock trên tất cả các instance.


12

2.6. LRU eviction of keys

Khi Redis được sử dụng như một cache, đôi khi nó tự động loại bỏ dữ liệu cũ và

thêm vào dữ liệu mới. LRU chỉ là một phương pháp loại bỏ dữ liệu được hỗ trợ.

Maxmemory configuration directive

Dùng để cấu hình Redis sử dụng dung lượng bộ nhớ cho tập dữ liệu.

Maxmemory trong hệ thống 32 bit giới hạn trong 3GB, và gần như không giới trong

hệ thống 64 bit.

Khi bộ nhớ đạt tới ngưỡng cho phép, nó có thể có các xử lý như trả về lỗi đối với các

lệnh gây vượt quá dung lượng bộ nhớ hoặc loại bỏ dữ liệu cũ...

Maxmemory được cấu hình trong file redis.conf hoặc dùng lệnh CONFIG SET.

2.7. Automatic failover

Khi một master hoạt động không như mong đợi (hoặc gặp sự cố), quá trình failover

bắt đầu. Quá trình này đòi hỏi master cần có ít nhất một slave đi kèm (slave này đồng

bộ dữ liệu với master để bảo toàn dữ liệu). Slave sẽ được cấu hình để trở thành

master và đảm nhiệm chức năng mới trong hệ thống. Các ứng dụng sử dụng Redis

server sẽ được thông báo địa chỉ kết nối mới.

3. Redis Cluster Specification

3.1. Main Properties and rationales of the design

3.1.1. Goal

Hiệu suất cao và khả năng mở rộng tuyến tính đến 1000 node.

Mức độ chấp nhận ghi an toàn: hệ thống cố gắng giữ lại các bản ghi gốc từ client kết

nối với phần lớn master nodes.

Availability: Cluster có khả năng tồn tại tại một phân vùng nơi phần lớn master node

có thể truy xuất và có ít nhất một slave truy xuất cho mỗi master node gặp sự cố (khi

đó slave được đưa lên làm master). Sử dụng cơ chế Replica Migration để đưa một

slave từ master có nhiều slave sang cho một master không còn slave. Cơ chế này làm

tăng tính high availability.


13

3.1.2. Implement Subset

Redis Cluster thực hiện phân chia dữ liệu trên nhiều hash slot. Nhưng các thao tác

của client trên Cluster giống như trên cùng một server.

Redis Cluster có hỗ trợ hash tag để các key có thể lưu chung hash slot.

Redis Cluster chỉ có một database duy nhất DB0 (không hỗ trợ nhiều database).

3.1.3. Cluster and server roles in Redis Cluster protocal

Redis cluster nodes có trách nhiệm tổ chức dữ liệu, lấy trạng thái cluster, bao gồm

mapping key tới đúng node. Cluster node có thể tự phát hiện các node khác, xác định

các node không làm việc, thực hiện đưa slave node lên làm master khi cần thiết, theo

thứ tự để hoạt động khi có sự cố xảy ra.

Redis Cluster Bus kết nối tất cả Cluster node sử dụng TCP bus và binary protocol.

Node sử dụng gossip protocol để lan truyền thông tin cluster để phát hiện các node

mới, gửi các gói tin ping để chắc rằng các node khác hoạt động bình thường, và gửi

cluster message cần thiết để báo hiệu. Redis Cluster Bus còn sử dụng Pub/Sub

message để lan truyền thông tin.

Cluster node không có khả năng có proxy request, client có thể được redirect tới node

khác sử dụng redirection error -MOVED và -ASK. Trên lý thuyết, client có khả năng

gửi request đến tất cả các node trong cluster, chuyển hướng nếu cần, vì thế client

không cần giữ trạng thái của cluster. Tuy nhiên, client có khả năng cache map giữa

key và node có thể cải thiện hiệu suất (key thuộc node nào).

3.1.4. Write safety

Redis cluster sử dụng cơ chế sao chép bất đồng bộ, theo luật last failover win. Nghĩa

là sau khi một slave được đưa lên làm master, dữ liệu của nó sẽ thay thế tất cả các

bản sao chép khác trong node (một node gồm một master và ít nhất một slave). Điều

này có thể dẫn đến việc mất dữ liệu khi master chưa kịp sao chép cho slave.

3.1.5. Availability

Mỗi node của Redis cluster gồm một master server và ít nhất một slave server. Tập

hợp các node tạo thành một phân vùng (partition).

Redis Cluster không có trạng thái available ở phân vùng thiểu số của cluster. Giả sử ở

phân vùng đa số (nhiều hơn N/2 + 1 node), nơi có phần lớn master và slave cho mỗi


14

master có thể truy xuất. Cluster trả về trạng thái avalable sau một khoảng thời gian

NODE_TIMEOUT, cộng thêm vài giây trong trường hợp có yêu cầu để slave được

đưa lên làm master khi có sự cố xảy ra.

Redis Cluster hỗ trợ cơ chế Repication Migration tăng tính availability cho cluster

(trình bày ở phần III).

3.1.6. Performance

Redirect

Redis Cluster không sử dụng proxy chỉ đến đúng node cần tương tác mà đự động

redirect client đến được node chứa không gian key cần sử dụng.

Client có thể ghi nhớ key nằm ở node nào trong cluster, nhằm tăng tốc độ truy xuất.

Replication

Sử dụng cơ chế sao chép bất đồng bộ nên một node không cần chờ các node khác xác

nhận lệnh ghi.

Các thao tác trên Cluster giống như trên một instance duy nhất. Điều này có nghĩa là

với một Redis Cluster N node, có thể xem hiệu suất bằng một Redis instance nhân

lên N lần. Client giữ kết nối liên tục với các node trong Clutster, vì vậy độ trễ cũng

tương đương như với một Redis node.

3.2. Overview main component

3.2.1. Keys distributed model

Không gian key được chia đều vào 16384 slot, thực tế có thể cấu hình cluster gồm

16384 master (tuy nhiên, cấu hình đề nghị khoảng 1000 nodes).

Mỗi master nodes trong cluster là một subset của 16384 hash slot. Thuật toán map

key với hash slot tương ứng là công thức:

HASH_SLOT = CRC16(key) mod 16384

3.2.2. Keys hash tags

Sử dụng để đưa nhiều key vào cùng một hash slot.

Cơ bản, key sẽ chứa một phần '{string}'. Server sẽ tính 'string' trong ngoặc để tính vị

trí hash slot.


15

3.2.3. Cluster nodes attributes

Mỗi node có một tên phân biệt duy nhất trong cluster. Tên node là chuỗi hex 160 bit

random.

3.2.4. The Cluster Bus

Mỗi Redis node có một TCP port để giao tiếp với các node khác.

Mỗi node trong cluster yêu cầu 2 port:

Port giao tiếp với client (mặc định 6379). Giao tiếp giữa node với client và với các

node khác trong cluster.

Port dùng cho Cluster Bus (client port + 10000). Giao tiếp với tất cả các node trong

cluster.

Cluster Bus được các node dùng để pháp hiện lỗi, cập nhật cấu hình, ủy quyền khi có

sự cố,...

3.2.5. Cluster topology

Redis cluster là một đồ thị đầy đủ, nơi mà mỗi node đều có kết nối với mọi node

khác.

Mỗi node đều có N-1 TCP kết nối ra ngoài và N-1 kết nối vào.

Node sử dụng gossip protocal và cơ chế cập nhật cấu hình để tránh trao đổi quá nhiều

tin nhắn giữa các node trong điều kiện bình thường.

3.2.6. Node handshake

Node luôn chấp nhận kết nối với các node trong cluster và loại bỏ các gói tin từ bên

ngoài.

Một node chấp nhận một node khác trong cluster theo 2 cách:

Một node gửi MEET message cho các node khác khi system administrator gửi

lệnh yêu cầu: CLUSTER MEET ip port.

Một node được đăng ký vào cluster khi được trust bởi node khác. A biết B, B biết

C. B gửi gossip message tới A và C. Lúc này A đăng ký C như một phần cluster

và thử kết nối với C.


16

3.3. Redirection and Resharding

3.3.1. MOVED Redirection

Một client gửi truy vấn đến tất cả các node trong cluster, kể cả slave. Các node sẽ

phân tích và tìm node có trách nhiệm với key trong hash slot của mình.

Nếu hash slot đang được giữ bởi node nhận truy vấn, nó sẽ xử lý bình thường.

Ngược lại, node trả về lỗi: -MOVE <hash slot của key> <ip:port chứa hash

slot của key>. Lỗi này yêu cầu client kết nối tới node chịu trách nhiệm xử lý

key trong truy vấn.

Client kết nối tới node thích hợp và lưu liên kết giữa hash slot chứa key và node.

3.3.2. Cluster live configuration

Redis Cluster cho phép thêm hoặc xóa node trong khi đang chạy. Điều này dẫn đến

việc phải cân bằng lại Cluster (resharding hash slot).

Mỗi khi cân bằng Cluster thay đổi hash slot, thông tin sẽ được lan truyền trên Cluster

để cấu hình lại.

3.3.3. ASK redirection

3.3.4. Clients first connection and handling of redirections

Có trường hợp client không nhớ slot configuration mà chỉ gửi truy vấn cho một node

ngẫu nhiên và chờ redirect. Cách làm này thật sự không có hiệu quả.

Một client nên dành bộ nhớ để lưu slot configuration. Dùng lệnh CLUSTER SLOT

để lấy cấu hình hash slot trên Cluster.

3.3.5. Multiple keys operations

3.3.6. Scaling reads using slave nodes

Thông thường, client sẽ kết nối với master để thực thi. Tuy nhiên, client có thể kết

nối với slave để đọc dữ liệu bằng lệnh READONLY. Dùng lệnh READWRITE để

xóa bỏ trạng thái kết nối readonly.


17

3.4. Failt Tolerance

3.4.1. Node heartbeat and gossip messages

Redis Cluster node liên tục trao đổi thông tin bằng các gói tin ping và pong. Các gói

tin này cùng cấu trúc và chỉ khác nhau ở một số trường. Chúng được gọi chung là

heartbreat packages.

Mỗi node gửi gói tin ping cho một vài node ngẫu nhiên khác để thử nhận gói tin

pong. Dùng để xác định lỗi trong Cluster.

3.4.2. Heartbeat packages content

Trong header của gói tin heartbeat (ping và pong) có các trường:

Node ID: 160 bit random định danh node.

currenEpoch và configEpoch sử dụng trong các thuật toán của Cluster.

Node flag: xác định node là master, slave.

Một bitmap (bit array) xác định hash slot được giữ bới node gửi tin. Nếu node gửi

là slave, bitmap xác định hash slot mà master của nó giữ.

Cổng TCP cơ bản của node gửi.

Trạng thái Cluster từ góc nhìn của node gửi tin.

Master node ID của node gửi tin nếu nó là slave.

Ping và pong là một phần của gossip session, nó cho node nhận góc nhìn của node

gửi tin về các node khác trong Cluster. Điều này hữu ích cho việc phát hiện lỗi

(failure detection) và phát hiện các node trong Cluster.

3.4.3. Failure detection

Redis Cluster phát hiện lỗi khi một server không thể truy xuất bởi phần lớn các node

trong cluster. Lúc này, tùy trường hợp mà một slave được đưa lên làm master hoặc

Cluster có thể nhận trạng thái lỗi và ngừng nhận truy vấn từ client.

Mỗi node có một danh sách các cờ (flag) liên kết với các node khác. Có 2 loại cờ là

PFAIL (có khả năng lỗi - possible failure - không biết loại lỗi) và FAIL xác định lỗi

và được xác nhận với phần lớn master trong một khoảng thời gian.


18

3.5. Configuration handling , propagration and failover

3.5.1. Cluster current epoch

currentEpoch là một số 64 bit không dấu. Dùng như một biến đi cùng với các sự kiện

để các node khác biết được trạng thái mới nhất.

Giá trị của currentEpoch sử dụng trong quá trình đưa slave lên làm master.

3.5.2. Configuration epoch

i. Slave election and promotion

Slave kiểm soát việc tiến cử (election) và thăng cấp (promotion), cùng với sự giúp đỡ

của master nodes để slave trở thành master.

3.5.3. Slave rank

Trong trường hợp master có nhiều slave. SLAVE_RANK là cấp bậc của slave liên

quan đến số lượng dữ liệu nó sao chép từ master. Cấp bậc này là độ ưu tiên khi chọn

slave làm master.

3.5.4. Masters reply to slave vote request

3.5.5. Practical example of configuraton epoch usefulness

during partitions

3.5.6. Hash slot configuration propagation

Redis Cluster có cơ chế làn truyền thông tin về node và hash slot của từng node.

Heartbeat messages. Mỗi gói tin ping và pong đều chứa thông tin hash slot mà nó

hoặc master của nó nắm giữ.

UPDATE messages. Nếu một node nhận gói tin heartbeart nhận thấy node gửi

chưa update, nó sẽ gửi một gói tin bắt node gửi cập nhật thông tin mới.

3.5.7. UPDATE messages, a closer look

3.5.8. How node rejoin cluster

Một node A giữ hash slot 1 và 2. Sau khi gặp sự cố, hash slot 1, 2 chuyển sang cho

node B. A phục hồi và trở thành slave của B.

Nhưng nếu hash slot của A chia cho cả B và sau đó là C (C lấy hash slot cuối cùng


19

của A), node A sẽ trở thành slave của master lấy hash slot cuối cùng của mình

(trường hợp này là C).

Trong trường hợp không resharding hash slot, vấn đề này không cần quan tâm.

3.5.9. Replica Migration

Replica Migration là một khái niệm được hiện thực hóa nhằm tăng tính sẵn sàng cho

hệ thống.

Một cluster theo mô hình master-slave kết nối không thay đổi. Đặc điểm này làm khả

năng sẵn sàng bị giới hạn khi có sự cố với các thành phần độc lập trong một node

(master và nhiều slave kèm theo) xảy ra đồng thời hoặc các server chưa kịp hồi phục.

Ví dụ: Một master A có một slave A1 đi kèm. Khi master A gặp sự cố, slave A1

được đưa lên làm master. Sau một thời gian ngắn, khi node A vẫn chưa hồi phục,

cluster không thể tiếp tục hoạt động .

Vì vậy, nếu liên kết master-slave không thể thay đổi thì cần thêm slave cho mỗi

master để khắc phục tình trạng trên. Nhưng điều này tốn rất nhiều chi phí.

Có một cách có thể giải quyết vấn đề trên. Đó là thêm một hoặc một số slave vào

cluster, tự động thay đổi cấu trúc cluster.

Ví dụ: Cluster gồm 3 node A, B, C có các slave tương ứng A1, B1, C1. Master C có

thêm một slave C2. Khi A gặp sự cố và A1 được đưa lên làm master thay thế, C2

được chuyển thành slave của A1. Khi A1 gặp sự cố, C2 lúc này được chuyển thành

master.

Replica Migration là quá trình tái cấu trúc tự động. Nó chuyển một slave (thuộc

master có nhiều hơn 1 slave) cho master không còn slave nào kèm theo.

3.5.10. Replica Migration Algorithms

3.5.11. configEpoch conflicts resolution algorithms

3.5.12. Node reset

Dùng lệnh CLUSTER RESET để xóa cấu hình của node. Master node còn chứa dữ

liệu không thể reset. Khi đó cần sử dụng lệnh FLUSHALL để xóa toàn bộ dữ liệu.

ii. Removing node from a cluster

Khi xóa một node khỏi cluster (có thể phải resharding nếu là master) và tắt nó đi. Các

node khác vẫn nhớ node ID, địa chỉ và cố gắng kết nối với nó.


20

Vì vậy, khi xóa một node cần phải xóa thông tin của nó trên tất cả các node table.

Dùng lệnh CLUSTER FORGET <node-id>. Lệnh này làm 2 việc:

Xóa node với node id chỉ định khỏi node table.

Cấm thêm một node mới cùng node ID trong 60 giây (thời gian để Cluster xóa

node ID trên tất cả node table).

3.6. Publish/Subscribe

Client trong Redis Cluster có thể subscribe và publish với mọi node. Cluster sẽ đảm

bảo publish message được chuyển tiếp khi cần thiết.

Cài đặt hiện tại chỉ đơn giản broadcast publish message cho tất cả các node. Nhưng

client có thể optimized để tối ưu hoặc sử dụng cho các thuật toán khác.

Tham khảo

4. Tham khảo

Antirez. (n.d.). Antirez. Retrieved from http://antirez.com/

Redis. (n.d.). Retrieved from http://redis.io/documentation

Redis Cluster. (n.d.). Retrieved from http://redis.io/topics/cluster-spec

Documents

REDIS DOCUMENT - WordPress.comREDIS DOCUMENT | DUCDT - PMT 4 1. Giới thiệu Redis is an open source, BSD licensed, avanced key-value cache and store. Redis được biết đến