reids複製的原理和優化

reids複製的原理和優化

原理

主庫經過RDB文件傳給從庫,從而進行復制redis

複製的原則

  1. 一個master能夠有多個slave;
  2. 一個slave只能又一個master;
  3. 數據流向是單向的,master到slave;

主從複製的做用

  • 數據副本
  • 擴展讀性能

方式

  • 命令行

slaveof 127.0.0.1 6379 #直接指向須要複製的master服務器

取消複製服務器

slaveof no one

注意:取消複製時,master不會對slave的數據進行清零,當slave從新對新的master進行斷定時,新的master會對slave清零網絡

  • 配置文件

slaveof ip port
slave-read-only yes

clipboard.png

由於我是在同一臺服務器上去測試,端口6001的redis服務器是slave服務器,且只有以上配置,開啓複製以後,會發現已經默認地做爲端口爲6000的從庫了性能

clipboard.png

兩種方式的比較

方式 命令 配置
優勢 無需重啓 統一配置
缺點 不便於管理 須要重啓

全量複製和部分複製

runid

redis-cli -p 6379 info server| grep run

由上述命令能夠知道該 redis服務器的runid是多少,但服務器被重啓或者是網絡的緣由,runid會發生變化,而從庫探測到主庫的runid發生了變化,會認爲進行了很大的改動,則會進行一次全量複製。測試

偏移量

偏移量是用來檢測從庫和主庫數據是否一致優化

redis-cli -p 6379 info replication

clipboard.png

全量複製

clipboard.png

  1. psync是從庫內部本身調用的,在第一次的複製的時候,很明顯從庫是不知道主庫的runid和偏移量,因此須要作一個全量的複製。
  2. 主庫檢測出了從庫是第一次複製,由於從庫不知道主庫的runid和偏移量,因此主庫把本身的runid和偏移量傳給了從庫
  3. 從庫保存了主庫的runid和偏移量
  4. 主庫開始建立快照(bgsave),與其同時主庫也會把在建立快照的時間間期中產生的數據傳到了自身的複製緩衝區
  5. 主庫向從庫發送RDB文件
  6. 主庫向從庫發送複製緩衝區的數據,並添加到了從庫接受到的RDB文件中
  7. 從庫清除自身本來有的數據
  8. 從庫執行RDB文件,從而達到複製
全量複製開銷
  • bgsave的時間
  • RDB文件網絡傳輸時間
  • 從節點清空數據的時間
  • 從節點加載RDB的時間
  • 可能的AOF重寫的時間

部分複製

由於若是所有都是全量複製,這無疑給服務器帶來了很大的開銷,因此出現了部分複製spa

clipboard.png

  1. 有時候由於網絡的抖動或者其餘緣由,致使從庫對主庫失去鏈接。
  2. 主庫會把這個時間段新增的數據寫入複製緩衝區。
  3. 當從庫再次鏈接以後
  4. 從庫會告訴主庫說,主庫對應的runid以及最新的偏移量值
  5. 主庫會判斷從庫是否須要部分複製,並判斷偏移量是不是在複製緩衝區的偏移量範圍內,若是不在證實從過錯過的數據已經不少了。
  6. 若是是在範圍內的話,主庫會把剩下從庫沒有的數據傳給從庫,從而達到部分複製,減小開銷
相關文章
相關標籤/搜索