Redis部分再同步和同步複製

來源:互聯網
上載者:User
原文:http://antirez.com/news/45

作者:Antirez weblog
正如我在以前的部落格文章中寫道,目前我正在開發Redis Slave的部分再同步功能。
我們的想法是,我們有複製流的後備日誌,可達到指定的位元組數量(預設將是幾百MB)。
如果一個Slave串連丟失時,它會再次建立串連,查看Master的RUNID 是否相同,並且要求從一個給定的位移量繼續。如果可能將繼續複製,沒有什麼損失,而完全重新同步是沒有必要的。否則,如果資料的位移量在後備日誌中不存在,將進行完全重新同步。
現在有趣的是,為了做到這一點,無論是Slave還是Master都必須知道一個全域的複製位移量。
現在,如果我們提供命令來返回這個位移量,用戶端可以僅通過發送查詢命令來簡單地類比同步複製,擷取位移量(想想MULTI/ EXEC如何做到這一點),然後向Slave做同樣的事情。因為Redis的複製只有非常低的延遲,用戶端可以簡單地做一個樂觀的“寫,讀位移量,讀Slave的位移量”("write, read-offset, read-offset-on-slave"),並從Slave上讀到的位移量有可能已經做好繼續的準備(或者,我們在暫停一會兒後再次讀取)。
這可能是有用的東西,但我不知道如果我們從那開始是否能夠建立更棒的東西,就是發送一種Redis命令,只要從至少N個串連的Slave中沒有得到對讀取複製位移量的確認,就阻塞,並返回傳生的時間及+OK。
當我們瞭解這是否有用及它的複雜度,我不確切它是否是可用的,但是從初步的分析看,實現快速可靠地...可能並非重要,聽起來不錯。

更多訊息待續。
相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.