iwehdio的：
學習自：
顯然，出現的上述問題是因為一台redis伺服器不夠，所以多搞幾台redis伺服器就可以了。為了實現我們服務的高可用性，可以將這幾台redis伺服器做成是主從來進行管理。
redis的主從架構特點：
主從架構的好處：
主從架構的特點之一：主伺服器和從伺服器的資料是一致的。
在redis中，使用者可以通過執行salveof命令或者設定salveof選項，讓乙個伺服器去複製(replicate)另乙個伺服器，我們稱呼被複製的伺服器為主伺服器(master)，而對主伺服器進行複製的伺服器則被稱為從伺服器(salve)
複製功能分為兩個操作：
命令傳播(command propagate)
從伺服器對主伺服器的同步又可以分為兩種情況：
在redis2.8以前，斷線後複製這部分其實缺少的只是部分的資料，但是要讓主從伺服器重新執行sync命令，這樣的做法是非常低效的。(因為執行sync命令是把所有的資料再次同步，而不是只同步丟失的資料)。
redis從2.8版本開始，使用psync命令來替代sync命令執行複製時同步的操作。psync命令具有完整重同步和部分重同步兩種模式(其實就跟上面所說的初次複製和斷線後複製差不多個意思)。
複製的前置的工作：
完整重同步是怎麼實現的：
部分重同步，可以讓我們斷線後重連只需要同步缺失的資料。部分重同步功能由以下部分組成：
複製偏移量：執行複製的雙方都會分別維護乙個複製偏移量
斷線重連以後，從伺服器向主伺服器傳送psync命令，報告現在的偏移量是36，那麼主伺服器該對從伺服器執行完整重同步還是部分重同步呢？？這就交由複製積壓緩衝區來決定。
伺服器執行的id(run id)實際上就是用來比對id是否相同。如果不相同，則說明從伺服器斷線之前複製的主伺服器和當前連線的主伺服器是兩台伺服器，這就會進行完整重同步。
當完成了同步之後，主從伺服器就會進入命令傳播階段。這時主伺服器只要將自己的寫命令傳送給從伺服器，而從伺服器接收並執行主伺服器傳送過來的寫命令，就可以保證主從伺服器一直保持資料一致了！
哨兵(sentinel)機制主要用於實現redis的高可用性，主要的功能如下：
sentinel可以讓我們的redis實現高可用，sentinel作為這麼乙個元件，自身也必然是高可用的(不可能是單點的)。
sentinel本質上只是乙個執行在特殊模式下的redis伺服器。因為sentinel做的事情和redis伺服器是不一樣的，所以它們的初始化是有所區別的(比如，sentinel在初始化的時候並不會載入aof/rdb檔案，因為sentinel根本就不用資料庫)。
啟動和初始化哨兵：
獲取和更新資訊：
判斷主伺服器是否下線有兩種情況：
客觀下線
在多少毫秒內無效回覆才認定主伺服器是主觀下線的，以及多少個sentinel認為主伺服器是下線的，才認定為客觀下線。這都是可以配置的
選舉領頭sentinel和故障轉移：
目前為止的主從+哨兵架構可以說redis是高可用的，但要清楚的是：redis還是會丟失資料的：
腦裂導致的資料丟失
iwehdio的：
Redis主從複製 哨兵搭建（Redis安裝包）
docker怎麼搞就是一台機器宕機後，仍然選舉已宕機的主機作為主節點，搞了三天了，網上各種帖子都看了，都不好使，放棄了，不用docker了，使用基本的redis搭建了！不用docker一下就成功了，心態崩了啊.docker部署在多台伺服器上沒問題，可以參考我的另一篇部落格！1.安裝 wget tar...
Redis 主從複製
主從複製的開啟，完全是在從節點發起的，不需要我們在主節點做任何事情，從節點開啟主從複製，有3種方式 主從複製主要可分為 連線建立階段 即準備階段 資料同步階段 命令傳播階段 主要作用是在主從節點之間建立連線，為資料同步做好準備 從節點資料的初始化，具體執行的方式是 從節點向主節點傳送psync命令 ...
Redis 主從複製
就是將一台 redis 伺服器的資料，複製到其他的 redis 伺服器，前者為主節點 master leader 後者稱為從節點 sl e follower 資料的複製是單向的，只能從主節點到從節點，一般 master 以寫為主，sl e 以讀為主。redis 主從複製可以根據是否是全量分為全量同步...