Redis复制机制
一、Redis的復制機制
在生產(chǎn)環(huán)境中，單個數(shù)據(jù)庫實例常常存在諸如系統(tǒng)崩潰、網(wǎng)絡連接閃斷或突然斷電等單點故障問題。與其他大多數(shù)數(shù)據(jù)庫系統(tǒng)一樣，Redis也提供了一個復制機制，使得數(shù)據(jù)能夠從一個Redis服務器（master, 主實例）復制到一個或多個其他的Redis服務器（slave，從實例）。
復制不僅提高了整個系統(tǒng)的容錯能力，還可以用來對系統(tǒng)進行水平擴展。在一個重讀取的應用中，可以通過增加多個Redis只讀從實例來減輕主實例的壓力。
Redis的復制機制是Redis Cluster的基礎，而Redis Cluster在此基礎上提供了高可用性。
二、Redis復制機制的工作原理
當主從實例之間網(wǎng)絡連接通暢且建立了復制關系后，主實例會把將其接收到的寫入命令轉(zhuǎn)發(fā)給從實例執(zhí)行，以實現(xiàn)主從實例之間的數(shù)據(jù)同步。
在Redis的復制機制中，共有兩種重新同步機制：部分重新同步和完全重新同步。
當一個Redis的從實例啟動并連接到主實例時，從實例總是會嘗試通過發(fā)送請求進行部分重新同步。如果主實例接受部分重新同步的請求，那么它會從從實例停止時的最后一個偏移處開始增量地進行命令同步。否則，需要進行完全重新同步。
當從實例第一次連接到它的主實例時，總是需要進行完全重新同步。在進行完全重新同步時，為了將所有的數(shù)據(jù)復制到從實例中，主實例需要將數(shù)據(jù)轉(zhuǎn)儲到一個RDB文件中，然后將這個文件發(fā)送給從實例。從實例接收到RDB文件后，會先將內(nèi)存中的所有數(shù)據(jù)清除，再將RDB文件中的數(shù)據(jù)導入。
主實例上的復制過程完全是異步的，因此并不會阻塞服務器處理客戶端的請求！
與完全重新同步相比，部分重新同步不需要從主實例中傳輸完整的數(shù)據(jù)轉(zhuǎn)儲文件。另外，將數(shù)據(jù)轉(zhuǎn)儲到RDB文件中會創(chuàng)建一個后臺進程，還會有內(nèi)存開銷。
為避免主從實例之間的數(shù)據(jù)不一致，大多數(shù)情況下，在redis的配置文件中配置slave-read-only yes，使得服務器處于只讀模式，在這種情況下，在從實例上創(chuàng)建一個新鍵或修改已有鍵的值時，會得到一個錯誤，禁止修改！
三、Redis復制機制調(diào)優(yōu)
Redis調(diào)優(yōu)：對Redis的關鍵配置參數(shù)進行優(yōu)化來達到更好的Redis性能。
Redis中使用replication backlog緩沖區(qū)來決定究竟是進行完全重新同步還是部分重新同步，更具體地說，在發(fā)出SLAVEOF命令后，從實例使用最后一個offset和最后一個主實例的ID向主實例發(fā)送一個部分重新同步請求。當主實例和從實例之間的連接建立后，主實例首先會檢查請求中的master_replid是否與它自己的master_replid一致。然后，主實例會檢查請求中的offset能否從backlog緩沖區(qū)中獲取。如果offset位于backlog的范圍內(nèi)，那么就可以從中獲取到連接斷開前的所有寫入命令，即意味這可以進行部分重新同步。否則，如果主實例在連接斷開期間接收到的寫入命令的數(shù)量超過了backlog緩沖區(qū)的容量，那么部分重新同步請求會被拒絕，此時完全重新同步會執(zhí)行。
默認情況下，backlog緩沖區(qū)的大小是1MB，這個容量在連接斷開期間只能容納少量的寫入命令。多數(shù)情況下，需要把這個參數(shù)調(diào)整為更高的值以滿足需求。
通過在峰值期間使用INFO命令來計算master_repl_offset的變化量，可以估算backlog緩沖區(qū)的合適大小為：
t * (master_repl_offset2 - master_repl_offset1) / (t2 - t1), t is how long the disconnection may last in seconds.
總結
- 上一篇： Prezi实战 ------ 一款颠覆性
- 下一篇： AI人工智能将引入证券监管，数据库蓝海时