在Redis集群中，節點除了存儲數據外，還會持有其他節點的信息：包括把key映射到恰當的節點上去。

同時，集群中的節點能夠自動發現其他節點、檢測失效節點、把從節點提升為主節點等。

那么，節點是如何做到這些的呢？在Redis集群中，所有的節點通過一個TCP總線和二進制協議彼此進行連接，這就是Redis集群總線。

每個節點都通過集群總線與其他節點建立連接。使用gossip協議，可以達到故障檢測、節點發現、配置信息同步等功能。每個節點都會定期向隨機選擇的其他節點發送自己的狀態信息，通過多次傳播，最終所有節點都能獲得整個集群的狀態。

圖片

所以，對于集群的信息，不是存在于某個節點上，而是在節點之間不斷的相互通信，從而保持集群中的節點信息是完整的。

由于集群總線的存在，需要每個節點都有一個總線端口，它默認等于數據端口加上10000，比如16379。

由于集群總線的存在，所以節點都清楚了解彼此的存在，而對于客戶端的請求，Redis并不是通過代理的方式來處理的，而是把命令重定向到正確的節點上。我們來實踐看看：

先連上集群，查看fullstack的hash值，然后設置它的value，看看會發生什么：

127.0.0.1:7000> cluster keyslot fullstack
(integer) 15274
127.0.0.1:7000> set fullstack good
-> Redirected to slot [15274] located at 127.0.0.1:7002
OK

我們先連接的是7000的客戶端，而fullstack的hash槽位是15274，不是7000所存儲的范圍，所以自動重定向到了7002端口。

所以客戶端不需要保存集群的狀態，只要連接任意一個節點，剩下的事情就交給集群吧。

另外，我想說的是，編程技術很多時候都是細節，那一張張所謂高大上的架構圖，并不能解決所有問題，所以我想通過這些“碎碎念”的系列文章把Redis集群講得透徹、深入，不論是日常開發、維護，還是應對面試，這些都是很有價值的。

當然，除了Redis，后續會有系列文章講解Kafka、MySQL、Java、CI/CD、Docker、分布式事務、AI等，敬請期待。

最后，插播一句，不要過于依賴或者過于相信AI。對于Redis集群總線，它告訴我，使用如下的命令可以查看集群總線的狀態：

redis-cli -h host -p port CLUSTER BUS LIST

然而，執行上面的命令會報錯（替換ip、端口等信息），我使用cluster help也沒有找到bus相關的命令，恕我無知，不知道這個命令是怎么來的。給人的感覺是，就像有人說的，AI在一本正經的胡說八道。