System架構及環境

架構確認

• 架構（典型做法）
  台北：3 個 Master（各管一部分 slot）＋每個 Master 在台北本地放 1 個 Slave（本地 HA）。
  台中：每個 Master 再在台中放 1 個 遠端 Slave（AS/DR）。
  → 總數 = 3 Masters + 6 Slaves = 9 個節點（每個 Master 底下有 2 個 Slave：台北 1、台中 1）。

• 寫入進到其中一個 Master：
  這個 Master 會把自己的資料（它負責的那些 slot）複寫給它名下的 2 個 Slave（台北那個 + 台中那個）。
  其它兩個 Master（及其 Slave）不會收到這筆資料（因為不是它們的 slot）。

• 一致性特性：
  Redis 複寫是 非同步。兩個 Slave 都會「最終拿到」這筆寫入，但在 WAN 抖動、全量同步時可能有秒級落差（RPO>0）。
  想壓低風險：主節點可設 min-replicas-to-write 1、min-replicas-max-lag 2，確保至少有 1 個（通常台北本地）Slave 追得上才允許持續寫。

• 確認 slot 歸屬指令:
  redis-cli -a pass.123 -c -h 192.168.10.201 -p 7011 CLUSTER SLOTS
  redis-cli -a pass.123 -c -h 192.168.10.201 -p 7015 CLUSTER NODES | awk '{printf "%-40s %-22s %-20s %-20s\n",$1,$2,$3,$4}'
  

• 測試 205 master 打資料，201 slave 會不會有相同的 key
  先打一筆: v-1756262036
  

• 驗證: 201 兩個 slave 都有資料
  (要先 READONLY 才不會被重導向到 Master)
  

停滯