一、前言
組內現在用的是redis 的sentinel。
本着實踐的原則，對sentinel的幾台服務器進行了網絡或者抓包方面的實踐。
一共三台redis服務器，
10.10.20.6, 10.10.20.9, 10.10.20.11
其中，10.10.20.11為主。
我代碼里是這么配置的：
#集群名稱
redis.sentinel.master=redisMaster
redis.sentinel.nodes=10.10.20.6:26379,10.10.20.9:26379,10.10.20.11:26379
二、實踐
1、進程查看
每台服務器上都開啟了兩個進程，各監聽一個端口，一個26379，一個6379.
以上只看了一台，實則，三台都是類似的。
2、長連接查看
另外，三台服務器的sentinel進程之間，應該都是有建立長連接的。我們看看是不是這么回事？
2.1 10.10.20.11上看到的長連接：
下面是從服務器上抓的11和6之間的長連接：
下面是從服務器上抓的11和9之間的長連接：
2.2 10.10.20.9上看到的長連接：
可以看出來，sentinel進程和另外兩台服務器上的sentinel進程，都建立了長連接。（另外一台就不一一截圖了）
那么，長連接上交換什么數據呢？
三、sentinel之間的數據
我這里，在11上抓了個包：（保存到了11cap這個文件）
tcpdump -i eth1 -w 11cap port 26379
在windows上用wireshark打開后，
這個圖里，可以看到，有大量的ping/pong心跳消息。
另外，也可以看到，有下面這樣的：
上面提到了53635端口，是sentinel進程打開的，而不是6379端口的進程打開的：
（lsof -p 2557 查看進程打開的文件）
這個我理解，應該就是各個sentinel之間，向別的sentinel表示自己觀察到master是誰，方便后續進行投票吧。
這部分我還沒有特別懂。
2、sentinel結構是否能夠實現讀寫分離？
答案：不能。
程序端采用spring-data-redis與sentinel集群連接后，
2019-07-10 16:22:56.249 [main] INFO [] redis.clients.jedis.JedisSentinelPool - Trying to find master from available Sentinels... 2019-07-10 16:22:56.295 [main] INFO [] redis.clients.jedis.JedisSentinelPool - Redis master running at 192.168.17.129:6379, starting Sentinel listeners... 2019-07-10 16:22:56.327 [main] INFO [] redis.clients.jedis.JedisSentinelPool - Created JedisPool to master at 192.168.17.129:6379
上面可以看到，192.168.17.129是我們的master所在服務器。 我們用netstat 看下，我們客戶端和另外兩台slave是否有連接呢？（slave為：192.168.17.128/192.168.17.130）
可以看到，只連接到了master。
3、模擬master宕機后，客戶端的反應
首先：
接下來：
Caused by: redis.clients.jedis.exceptions.JedisDataException: READONLY You can't write against a read only replica.
接着，這次才連到正確的新的master：
經過一番查找，發現第二步之所以有那個readonly提示，是因為128中配置了：
所以可看到，sentinel 選主期間（新的 master 還沒選出來之前），是不可用的。
4、sentinel的缺點
1、不支持讀寫分離，也就無法負載均衡
2、master掛掉，選主期間，不可用；如果master 和 其他服務器發生腦裂（master 沒掛，其他服務器和master之間網絡中斷），則客戶端會依然寫舊的master，新的master選出來后，舊的master的數據會被清掉，導致數據丟失，避免數據丟失的方式是設置下面兩個參數，當沒有slave時，不准寫，此時，也會喪失可用性：
# It is possible for a master to stop accepting writes if there are less than # N replicas connected, having a lag less or equal than M seconds. # # The N replicas need to be in "online" state. # # The lag in seconds, that must be <= the specified value, is calculated from # the last ping received from the replica, that is usually sent every second. # # This option does not GUARANTEE that N replicas will accept the write, but # will limit the window of exposure for lost writes in case not enough replicas # are available, to the specified number of seconds. # # For example to require at least 3 replicas with a lag <= 10 seconds use: # # min-replicas-to-write 3 # min-replicas-max-lag 10
四、參考資料
https://blog.csdn.net/qq_33394088/article/details/80587588
https://www.jianshu.com/p/d1636776bb40
https://blog.csdn.net/sunweiguo1/article/details/80303565#commentsedit
https://blog.csdn.net/pzysoft/article/details/75577534