redis主從 - 簡書

redis主從

主服務器接受讀寫請求簇搅，從服務器只接受讀請求完域。通常如果是主從模式，client會通過proxy來訪問redis瘩将，proxy會對請求進行解析吟税，如果是寫請求，轉發(fā)給master_redis姿现，如果是讀請求肠仪，則轉發(fā)給slave_redis。

redis主從關系圖

前提：通過github下載了最新的redis源碼备典，并且通過make的方式編譯好了可執(zhí)行文件异旧。切到redis/src/路徑下。

./redis-server --port 6377
./redis-server --port 6378
./redis-server --port 6379

其中以6377服務器作為master拌屏。

./redis-cli -p 6378
./redis-cli -p 6379

slaveof 127.0.0.1 6378
slaveof 127.0.0.1 6379

此時會看到6377的master_redis服務器輸出了以下日志：

master的日志

測試主從效果每篷，連接主redis 6377，輸入set master 6377端圈。分別連接6378和6379焦读，輸入get master可獲得"6377"。
slave服務器和主斷開連接成為新的主舱权，命令:

slaveof no one

總結：通過使用redis原生的主從功能吨灭，可以發(fā)現(xiàn)，主從機制可以有效的分散來自客戶端的數(shù)據(jù)讀取的壓力刑巧，但是寫數(shù)據(jù)依然是瓶頸并且未突破單機上限喧兄，總的存儲功能受限于所在的主機的內存和磁盤。而且需要通過客戶端手動配置主從啊楚，非常的落后吠冤，還需要健全的配套設施輔助主從功能。

從服務器首次連到主服務器時恭理，主服務器將數(shù)據(jù)全量的同步到從服務器中拯辙，通常使用RDB的方式，將內存數(shù)據(jù)以RDB的方式打包，然后通過網(wǎng)絡傳輸?shù)綇姆掌髦小?/li>
當從服務器收到了主服務器通過過來的全量數(shù)據(jù)后涯保，后續(xù)的數(shù)據(jù)采用增量的方式將數(shù)據(jù)同步給slave服務器诉濒。
主從服務器狀態(tài)一致性的判定。
主從服務器網(wǎng)絡波動導致狀態(tài)不一致時夕春，斷線重連未荒。

slave服務器：

連接建立。在serverCron中定期執(zhí)行replicationCron及志，調用connectWithMaster和master服務器建立連接片排。
在syncWithMaster 剛建立連接時通過該處理函數(shù)來做一些信息同步。
在readSyncBulkPayload 建立連接后首先需要同步一次全量的主的數(shù)據(jù) 通過該函數(shù)來接受master的RDB文件速侈，之后再replicationCreateMasterClient 承接上一步在這里一路設置處理函數(shù)為下面的readQueryFromClient率寡。
后續(xù)網(wǎng)絡事件處理函數(shù)都調用readQueryFromClient進行處理。由于后續(xù)Master會把寫命令同步給slave服務器倚搬，因此從服務器可以把master服務器作為客戶端進行處理冶共，處理其傳輸過來的每一個命令。
master服務器：
始終使用通用的readQueryFromClient處理函數(shù)處理網(wǎng)絡消息每界，將Slave服務器作為特殊的客戶端進行處理比默。

master定時發(fā)送 "REPLCONF GETACK"獲取slave服務器的一些信息。
slave服務器調用replconfCommand命令處理replconf請求盆犁，該函數(shù)會回發(fā) "REPLCONF ACK c->reploff" 返回其已經接收到的包的字節(jié)數(shù)命咐。
master收到slave的ack后，修改slave服務器收到的字符的長度谐岁，后續(xù)已收到的字節(jié)將不再發(fā)送給slave醋奠。

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者