一、Redis主從同步原理

1.1 Redis主從同步的過程

配置好slave服務(wù)器連接的master后，slave會建立和master的連接，然后發(fā)送sync命令。無論是第一次同步建立的連接還是連接斷開后的重新連接，master都會啟動一個后臺進程，將數(shù)據(jù)庫快照保存到文件中.同時master主進程會開始收集新的寫命令并緩存起來。當后臺進程完成寫文件后，master就將快照文件發(fā)送給slave，slave將文件保存到磁盤上，然后加載到內(nèi)存將數(shù)據(jù)庫快照恢復(fù)到slave上。slave完成快照文件的恢復(fù)后，master就會把緩存的命令都轉(zhuǎn)發(fā)給slave，slave更新內(nèi)存數(shù)據(jù)庫。后續(xù)master收到的寫命令都會通過開始建立的連接發(fā)送給slave。從master到slave的同步數(shù)據(jù)的命令和從 client到master發(fā)送的命令使用相同的協(xié)議格式。當master和slave的連接斷開時，slave可以自動重新建立連接。如果master同時收到多個slave發(fā)來的同步連接命令，只會使用啟動一個進程來寫數(shù)據(jù)庫鏡像，然后發(fā)送給所有slave。

1.2 Redis主從同步的特點

主從同步具有明顯的分布式緩存特點，主要包括這些方面：

1）一個master可以有多個slave，一個slave也可以有多個slave；
2）slave不僅可以連接到master，slave也可以連接其他slave形成樹狀結(jié)構(gòu)；
3）主從同步不會阻塞master，但是會阻塞slave。也就是說當一個或多個slave與master進行初次同步數(shù)據(jù)時，master可以繼續(xù)處理client發(fā)來的請求。相反slave在初次同步數(shù)據(jù)時則會阻塞不能處理client的請求；
4）主從同步可以用來提高系統(tǒng)的可伸縮性，我們可以用多個slave專門處理client的讀請求，也可以用來做簡單的數(shù)據(jù)冗余或者只在slave上進行持久化從而提升集群的整體性能。

1.3 Redis主動同步設(shè)置方法

有兩種方式可以用來完成進行主從Redis服務(wù)器的同步設(shè)置。都需要針對slave服務(wù)器上進行，指定slave需要連接的Redis服務(wù)器（可能是master，也可能是slave）。

1.3.1 在配置文件中設(shè)置

在作為slave的Redis服務(wù)器的配置文件(redis.conf)中設(shè)置。

Conf代碼

slaveof 10.1.1.102 6379 #指定master的ip和端口

很明顯，這種設(shè)置方式非常簡單，但是需要修改配置文件，并且配置文件是在服務(wù)器啟動時加載的。所以服務(wù)器不啟動無法修改，操作不靈活。

這種配置方式適合于作為部署時的初始配置。

1.3.2 在Redis客戶端中進行設(shè)置

這里以Redis官方推薦的Jedis為例來說明，后文中的測試也基于Jedis來進行。這里jedis對象實例是屬于slave的，參數(shù)是服務(wù)器的地址和端口。

Java代碼

slaveJdedis.slaveOf("10.1.1.102", 6379); #指定master的ip和端口 
slaveJdedis.slaveofNoOne(); #取消指定master，自己成為一個master了

通過客戶端指定的方式，可以方便的修改master和slave服務(wù)器的主從關(guān)系。所以這種方式非常適合于根據(jù)需要在線調(diào)整master和slave服務(wù)器。

1.3.3 當前主從同步存在的問題

由于master和slave服務(wù)器的不是Redis自動選舉產(chǎn)生，需要人工參與，因此主從倒換無法自動完成。這樣就存在一個問題，什么時候以及由誰來觸發(fā)倒換。我看了下客戶端是沒有這個能力的，一定要的話需要自己增加。

Jedis目前隨機選擇讀取的哪臺Redis服務(wù)器，因此實現(xiàn)自動分布式讀取我們需要對Jedis做二次封裝。

1）  需要開發(fā)一種機制，盡快檢測到master和slave的工作狀態(tài)；
2）  需要定義一種master和slave的自動切換策略；
3）  需要定義一種可以隨機讀取任何一臺Redis服務(wù)器的機制；

這些功能都可以在客戶端實現(xiàn)，不過效果不會太好。如果服務(wù)器自身能夠支持就比較完美了，不過從Redis官網(wǎng)的介紹情況來看，好像目前還沒有看到有人提這樣的需求，也沒有這樣的規(guī)劃。

二、Redis主流客戶端介紹

在Redis的官方網(wǎng)站，列出了5款Redis的java客戶端軟件。其中Jedis是Redis官方推薦的java客戶端，這款一直有維護并更新。目前服務(wù)器最新穩(wěn)定版本是Redis2.4.17，最新的測試版本Redis 2.6.0 RC7。

2.1 Jedis

Jedis是Redis官方推薦的Java客戶端版本。目前最新為Jedis 2.1.0-5版本，完全兼容Redis 2.0.0版本。這個客戶端一直都有維護和更新。

2.2 JRedis

JRedis之前很長一段時間沒有更新，可以完全兼容Redis 2.0.0版本。今天5月份前做過更新后可以兼容最新的Redis2.6.0測試版本。

2.3 JDBC-Redis

JDBC-Redis是用于Redis這個NoSQL數(shù)據(jù)庫的JDBC驅(qū)動。只能下載到2009年3月發(fā)布的jdbc-redis_0.1_beta版本，目前已經(jīng)無人維護了。

2.4 RJC

RJC提供Apache DBCP風格的連接池。1年前已經(jīng)停止更新，可以完全兼容Redis 2.0.0版本。

2.5 redis-protocol

這個更新是最快和最頻繁的，可以兼容最新的Redis 2.6.0版本。不過它定位于完整支持Redis協(xié)議，更加高效和Redis服務(wù)器進行數(shù)據(jù)交互。所以，并沒有充分發(fā)揮redis服務(wù)器的功能。

2.6 各個Java客戶端總體評價

整體來講，各個客戶端基本都實現(xiàn)了Redis協(xié)議協(xié)議定義的基本功能。Redis-protocol更新最近對Redis協(xié)議的支持最完整；Jedis提供對Redis服務(wù)器的更多配置操作，使用起來是最方便的。其他客戶端都很少維護，功能也是一般。

如果要少量擴展客戶端的功能，基于Jedis來做開發(fā)是最快捷的。

如果要最大限制兼容和擴展客戶端的功能，基于Redis-protocol是最好的選擇。

三、Redis主從同步的使用建議

Redis主從同步在目前所有的Java客戶端都支持不好。主要原因應(yīng)該還是Redis服務(wù)器本身的實現(xiàn)機制限制導致的。如果一定要做也是可能的，不過效果可能會打折扣。

3.1 通過封裝Jdedis來實現(xiàn)

1）新增一個管理類，負責維護Redis服務(wù)器集群的服務(wù)器拓撲關(guān)系；
2）新增一個監(jiān)測類，負責監(jiān)測和維護Redis服務(wù)器集群中的服務(wù)器運行狀態(tài)；
3）新增一個Master選擇策略類，負責確定master和slave的切換時機，并選擇最合適的Redis服務(wù)器充當master。
4）新增一個代理類，接管當前的Jedis客戶端對Redis服務(wù)器的讀寫操作。應(yīng)用層通過代理類來使用Jedis客戶端。代理類需要保證Redis服務(wù)器集群對應(yīng)用層透明。

總結(jié)

以上就是本文關(guān)于Redis的主從同步解析的全部內(nèi)容，希望對大家有所幫助。感興趣的朋友可以繼續(xù)參閱本站：Java編程redisson實現(xiàn)分布式鎖代碼示例、redis中事務(wù)機制及樂觀鎖的實現(xiàn)等，有什么問題可以隨時留言，小編一定知無不言言無不盡。感謝朋友們對本站的支持！