Redis Replication 同步架構討論
Redis 使用非同步的方式，從主節點上複制資料到從節點上，而這一篇想進一步討論架構的建議。
以下有兩種 “只讀副本從節點(replica node)” 連接 “主節點(primary node)” 的連接方式，下面進一步說明，這兩種方案，不同的優缺點。
A ← B ← C : 上圖黃底的架構。
優點: 可以進一步分散主節點的負載。
缺點: 每一個節點的 “數據差異” 會加大，也會加大架構複雜度。
!!! 另外，ElastiCache Redis 也不支援上述架構。
A ← B + A← C : 上圖藍底的架構。
優點: 每一個節點的 “數據差異” 較低，因為所有的數據來自於同一個主節點(primary node)。
缺點: 過多的只讀副本從節點(replica node)，會加大主節點(primary node)的負載，所以在 ElastiCache Redis 中，會有每一個主節點，最多 5 個只讀副本從節點(replica node)的限制。
[+] Understanding Redis replication — https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html
Each shard in a replication group has a single read/write primary node and up to 5 read-only replica nodes.
!!! 基本上，Redis 一般的使用情況，是寫入(write)少，而有大量的讀取(read)需求，例如 1: 10 的比例，所以確保數據一致性，是優先要考量的。
!!! 高寫入的需求，可以使用 “多個主節點” cluster mode enable 的架構，來達到這個需求。
以下測試，是啟動 3 Redis 服務，分別使用不同的 port，實踐的是 A ← B ← C 的連接方式。
A : Primary ./redis-server *:6381
B : Replica ./redis-server *:6391 ≤== 這一台連接到 *:6381
C : Replica ./redis-server *:6379 ≤== 這一台連接到 *:6391
$ ps -ef | grep redis
root 17062 1 0 08:08 ? 00:00:00 ./redis-server *:6381 <--- primary
root 17070 1 0 08:08 ? 00:00:00 ./redis-server *:6391 <--- replca
root 17088 1 0 08:09 ? 00:00:00 ./redis-server *:6379 <--- replca
6381 <-- 6391 <--- 6379
127.0.0.1:6391> info Replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
127.0.0.1:6379> replicaof 127.0.0.1 6391
OK
$ redis-cli -p 6379 info replication
# Replication
role:slave <---- 角色是 replica
master_host:127.0.0.1
master_port:6391
master_link_status:up
...
connected_slaves:0 <--- 沒有人連接他。
$ redis-cli -p 6391 info replication
# Replication
role:slave <---- 角色是 replica
master_host:127.0.0.1
master_port:6381
master_link_status:up
...
connected_slaves:1
slave0:ip=127.0.0.1,port=6379,state=online,offset=364,lag=0 <---- 但有 p=127.0.0.1,port=6379 跟他同步。
$ redis-cli -p 6381 info replication
# Replication
role:master <---- 角色是 primary
connected_slaves:1
slave0:ip=127.0.0.1,port=6391,state=online,offset=378,lag=0 <---- 只有一個從節點，跟他相連。
