使用docker-compose創建主從模式 Redis集群


使用docker-compose創建主從模式 Redis集群

原文鏈接
版本信息:5.0.6

一、目錄結構如下

image.png

  • 創建一個redis_master_slave文件夾,用於存放redis集群的配置文件
  • 這里我對每個節點又單獨創建了master、slave1、slave2文件夾,也可以不創建

1.1 docker-compose.yaml內容

1.1.1 master節點的docker-compose.yaml

version: '3'

services:
  redis:
    image: redis:latest
    container_name: redis
    restart: always
    ports:
      - 6379:6379
    networks:
      mynetwork:
        ipv4_address: 172.19.0.10
    volumes:
      - ./redis.conf:/usr/local/etc/redis/redis.conf:rw
      - ./data:/data:rw
    command:
      /bin/bash -c "redis-server /usr/local/etc/redis/redis.conf "
networks:
  mynetwork:
    external: true

slave1節點、slave2節點的不同點在於 IP和端口映射不一樣。

1.1.2 slave1節點的docker-compose.yaml

version: '3'

services:
  redis:
    image: redis:latest
    container_name: redis_slave1
    restart: always
    ports:
      - 6380:6379
    networks:
      mynetwork:
        ipv4_address: 172.19.0.11
    volumes:
      - ./redis.conf:/usr/local/etc/redis/redis.conf:rw
      - ./data:/data:rw
    command:
      /bin/bash -c "redis-server /usr/local/etc/redis/redis.conf "
networks:
  mynetwork:
    external: true

1.1.3 slave2節點的docker-compose.yaml

version: '3'

services:
  redis:
    image: redis:latest
    container_name: redis_slave2
    restart: always
    ports:
      - 6381:6379
    networks:
      mynetwork:
        ipv4_address: 172.19.0.12
    volumes:
      - ./redis.conf:/usr/local/etc/redis/redis.conf:rw
      - ./data:/data:rw
    command:
      /bin/bash -c "redis-server /usr/local/etc/redis/redis.conf "
networks:
  mynetwork:
    external: true

1.2 redis.conf內容

1.2.1 master節點的redis.conf

bind 0.0.0.0
protected-mode no
port 6379
timeout 0
save 900 1 # 900s內至少一次寫操作則執行bgsave進行RDB持久化
save 300 10
save 60 10000
rdbcompression yes
dbfilename dump.rdb
dir /data
appendonly yes
appendfsync everysec
requirepass 12345678

1.2.2 slave1節點的redis.conf

bind 0.0.0.0
protected-mode no
port 6379
timeout 0
save 900 1 # 900s內至少一次寫操作則執行bgsave進行RDB持久化
save 300 10
save 60 10000
rdbcompression yes
dbfilename dump.rdb
dir /data
appendonly yes
appendfsync everysec
requirepass 12345678

slaveof 172.19.0.10 6379
masterauth 12345678

1.2.3 slave2節點的redis.conf

bind 0.0.0.0
protected-mode no
port 6379
timeout 0
save 900 1 # 900s內至少一次寫操作則執行bgsave進行RDB持久化
save 300 10
save 60 10000
rdbcompression yes
dbfilename dump.rdb
dir /data
appendonly yes
appendfsync everysec
requirepass 12345678

slaveof 172.19.0.10 6379
masterauth 12345678

二、啟動節點服務

依次啟動各個節點服務,當slave節點啟動的時候,會自動連接master節點,同時master節點也會顯示連接日志。

2.1 master節點日志

Creating redis ... done
Attaching to redis
redis    | 1:C 06 Sep 2020 01:05:44.001 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis    | 1:C 06 Sep 2020 01:05:44.001 # Redis version=5.0.6, bits=64, commit=00000000, modified=0, pid=1, just started
redis    | 1:C 06 Sep 2020 01:05:44.001 # Configuration loaded
redis    | 1:M 06 Sep 2020 01:05:44.005 * Running mode=standalone, port=6379.
redis    | 1:M 06 Sep 2020 01:05:44.005 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
redis    | 1:M 06 Sep 2020 01:05:44.005 # Server initialized
redis    | 1:M 06 Sep 2020 01:05:44.005 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
redis    | 1:M 06 Sep 2020 01:05:44.008 * Ready to accept connections
redis    | 1:M 06 Sep 2020 01:06:30.505 * Replica 172.19.0.11:6380 asks for synchronization
redis    | 1:M 06 Sep 2020 01:06:30.505 * Full resync requested by replica 172.19.0.11:6380
redis    | 1:M 06 Sep 2020 01:06:30.505 * Starting BGSAVE for SYNC with target: disk
redis    | 1:M 06 Sep 2020 01:06:30.506 * Background saving started by pid 10
redis    | 10:C 06 Sep 2020 01:06:30.521 * DB saved on disk
redis    | 10:C 06 Sep 2020 01:06:30.527 * RDB: 0 MB of memory used by copy-on-write
redis    | 1:M 06 Sep 2020 01:06:30.582 * Background saving terminated with success
redis    | 1:M 06 Sep 2020 01:06:30.589 * Synchronization with replica 172.19.0.11:6380 succeeded
redis    | 1:M 06 Sep 2020 01:07:53.029 * Replica 172.19.0.12:6381 asks for synchronization
redis    | 1:M 06 Sep 2020 01:07:53.029 * Full resync requested by replica 172.19.0.12:6381
redis    | 1:M 06 Sep 2020 01:07:53.029 * Starting BGSAVE for SYNC with target: disk
redis    | 1:M 06 Sep 2020 01:07:53.030 * Background saving started by pid 11
redis    | 11:C 06 Sep 2020 01:07:53.040 * DB saved on disk
redis    | 11:C 06 Sep 2020 01:07:53.041 * RDB: 0 MB of memory used by copy-on-write
redis    | 1:M 06 Sep 2020 01:07:53.057 * Background saving terminated with success
redis    | 1:M 06 Sep 2020 01:07:53.063 * Synchronization with replica 172.19.0.12:6381 succeeded
  • master節點啟動后,等待接收連接
  • 收到副本 172.19.0.11:6380 的同步請求
  • 和172.19.0.11:6380進行同步
  • 收到副本 172.19.0.12:6381 的同步請求
  • 和172.19.0.12:6381進行同步

2.2 slave1節點日志

Creating redis_slave1 ... done
Attaching to redis_slave1
redis_slave1 | 1:C 06 Sep 2020 01:18:21.869 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis_slave1 | 1:C 06 Sep 2020 01:18:21.869 # Redis version=5.0.6, bits=64, commit=00000000, modified=0, pid=1, just started
redis_slave1 | 1:C 06 Sep 2020 01:18:21.869 # Configuration loaded
redis_slave1 | 1:S 06 Sep 2020 01:18:21.872 * Running mode=standalone, port=6379.
redis_slave1 | 1:S 06 Sep 2020 01:18:21.872 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
redis_slave1 | 1:S 06 Sep 2020 01:18:21.873 # Server initialized
redis_slave1 | 1:S 06 Sep 2020 01:18:21.873 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
redis_slave1 | 1:S 06 Sep 2020 01:18:21.878 * Reading RDB preamble from AOF file...
redis_slave1 | 1:S 06 Sep 2020 01:18:21.879 * Reading the remaining AOF tail...
redis_slave1 | 1:S 06 Sep 2020 01:18:21.881 * DB loaded from append only file: 0.009 seconds
redis_slave1 | 1:S 06 Sep 2020 01:18:21.881 * Ready to accept connections
redis_slave1 | 1:S 06 Sep 2020 01:18:21.881 * Connecting to MASTER 172.19.0.10:6379
redis_slave1 | 1:S 06 Sep 2020 01:18:21.882 * MASTER <-> REPLICA sync started
redis_slave1 | 1:S 06 Sep 2020 01:18:21.882 * Non blocking connect for SYNC fired the event.
redis_slave1 | 1:S 06 Sep 2020 01:18:21.882 * Master replied to PING, replication can continue...
redis_slave1 | 1:S 06 Sep 2020 01:18:21.884 * Partial resynchronization not possible (no cached master)
redis_slave1 | 1:S 06 Sep 2020 01:18:21.886 * Full resync from master: 83cf8d4614610468aa53c43c553ca46a26c1e3be:924
redis_slave1 | 1:S 06 Sep 2020 01:18:21.976 * MASTER <-> REPLICA sync: receiving 176 bytes from master
redis_slave1 | 1:S 06 Sep 2020 01:18:21.981 * MASTER <-> REPLICA sync: Flushing old data
redis_slave1 | 1:S 06 Sep 2020 01:18:21.982 * MASTER <-> REPLICA sync: Loading DB in memory
redis_slave1 | 1:S 06 Sep 2020 01:18:21.986 * MASTER <-> REPLICA sync: Finished with success
redis_slave1 | 1:S 06 Sep 2020 01:18:21.988 * Background append only file rewriting started by pid 10
redis_slave1 | 1:S 06 Sep 2020 01:18:22.020 * AOF rewrite child asks to stop sending diffs.
redis_slave1 | 10:C 06 Sep 2020 01:18:22.020 * Parent agreed to stop sending diffs. Finalizing AOF...
redis_slave1 | 10:C 06 Sep 2020 01:18:22.020 * Concatenating 0.00 MB of AOF diff received from parent.
redis_slave1 | 10:C 06 Sep 2020 01:18:22.023 * SYNC append only file rewrite performed
redis_slave1 | 10:C 06 Sep 2020 01:18:22.024 * AOF rewrite: 0 MB of memory used by copy-on-write
redis_slave1 | 1:S 06 Sep 2020 01:18:22.088 * Background AOF rewrite terminated with success
redis_slave1 | 1:S 06 Sep 2020 01:18:22.097 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
redis_slave1 | 1:S 06 Sep 2020 01:18:22.109 * Background AOF rewrite finished successfully

2.3 slave2節點日志

Creating redis_slave2 ... done
Attaching to redis_slave2
redis_slave2 | 1:C 06 Sep 2020 01:18:51.630 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis_slave2 | 1:C 06 Sep 2020 01:18:51.630 # Redis version=5.0.6, bits=64, commit=00000000, modified=0, pid=1, just started
redis_slave2 | 1:C 06 Sep 2020 01:18:51.630 # Configuration loaded
redis_slave2 | 1:S 06 Sep 2020 01:18:51.636 * Running mode=standalone, port=6379.
redis_slave2 | 1:S 06 Sep 2020 01:18:51.637 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
redis_slave2 | 1:S 06 Sep 2020 01:18:51.637 # Server initialized
redis_slave2 | 1:S 06 Sep 2020 01:18:51.638 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
redis_slave2 | 1:S 06 Sep 2020 01:18:51.651 * Reading RDB preamble from AOF file...
redis_slave2 | 1:S 06 Sep 2020 01:18:51.653 * Reading the remaining AOF tail...
redis_slave2 | 1:S 06 Sep 2020 01:18:51.657 * DB loaded from append only file: 0.019 seconds
redis_slave2 | 1:S 06 Sep 2020 01:18:51.657 * Ready to accept connections
redis_slave2 | 1:S 06 Sep 2020 01:18:51.657 * Connecting to MASTER 172.19.0.10:6379
redis_slave2 | 1:S 06 Sep 2020 01:18:51.658 * MASTER <-> REPLICA sync started
redis_slave2 | 1:S 06 Sep 2020 01:18:51.658 * Non blocking connect for SYNC fired the event.
redis_slave2 | 1:S 06 Sep 2020 01:18:51.659 * Master replied to PING, replication can continue...
redis_slave2 | 1:S 06 Sep 2020 01:18:51.661 * Partial resynchronization not possible (no cached master)
redis_slave2 | 1:S 06 Sep 2020 01:18:51.664 * Full resync from master: 83cf8d4614610468aa53c43c553ca46a26c1e3be:966
redis_slave2 | 1:S 06 Sep 2020 01:18:51.717 * MASTER <-> REPLICA sync: receiving 176 bytes from master
redis_slave2 | 1:S 06 Sep 2020 01:18:51.730 * MASTER <-> REPLICA sync: Flushing old data
redis_slave2 | 1:S 06 Sep 2020 01:18:51.731 * MASTER <-> REPLICA sync: Loading DB in memory
redis_slave2 | 1:S 06 Sep 2020 01:18:51.739 * MASTER <-> REPLICA sync: Finished with success
redis_slave2 | 1:S 06 Sep 2020 01:18:51.747 * Background append only file rewriting started by pid 11
redis_slave2 | 1:S 06 Sep 2020 01:18:51.782 * AOF rewrite child asks to stop sending diffs.
redis_slave2 | 11:C 06 Sep 2020 01:18:51.782 * Parent agreed to stop sending diffs. Finalizing AOF...
redis_slave2 | 11:C 06 Sep 2020 01:18:51.782 * Concatenating 0.00 MB of AOF diff received from parent.
redis_slave2 | 11:C 06 Sep 2020 01:18:51.786 * SYNC append only file rewrite performed
redis_slave2 | 11:C 06 Sep 2020 01:18:51.786 * AOF rewrite: 0 MB of memory used by copy-on-write
redis_slave2 | 1:S 06 Sep 2020 01:18:51.859 * Background AOF rewrite terminated with success
redis_slave2 | 1:S 06 Sep 2020 01:18:51.861 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
redis_slave2 | 1:S 06 Sep 2020 01:18:51.864 * Background AOF rewrite finished successfully

三、測試

這里以RDM工具作為redis連接的客戶端,分別連接redis的三個實例。
image.png
在master上輸入 set name zhangsan,在slave1中通過 get name 可以查看
image.png

四、原理

主從的原理是比較簡單的,一主多從,主數據庫可以讀也可以寫,從數據庫僅讀。

但是,主從模式一般實現讀寫分離,主數據庫僅寫,減輕主數據庫的壓力。原理圖如下:
image.png
下面是工作機制:
image.png

  1. 當slave啟動后會向master發送SYNC命令,master節點收到從數據庫的命令后通過bgsave保存快照(rdb持久化),並且從此時起執行的命令會被緩存起來。
  2. master會將保存的快照發送給slave,並且繼續緩存期間的寫命令。
  3. slave收到主數據庫發送過來的快照就會加載到自己的數據中。
  4. 最后master將緩存的命令同步給slave,slave收到命令后執行一遍,這樣master與slave數據就保持一致了。

五、優缺點

5.1 優點

  1. 之所以運用主從復制,是因為主從一定程度上解決了單機版並發量大,導致親求延遲或者redis宕機服務停止的問題
  2. 從數據庫分擔主數據庫的讀壓力,若是主數據庫只是寫模式,那么實現讀寫分離,主數據庫就沒有讀壓力了
  3. 另一方面解決了單機版單點故障的問題,若是主數據庫掛了,那么從數據庫可以隨時頂上來

綜上來說,主從模式一定程度上提高了系統的可用性和性能,是實現哨兵和集群的基礎。主從同步是以異步方式進行同步,期間redis仍然可以響應客戶端提交的查詢和更新的請求。

5.2缺點

主從模式好是好,但是也有自己的缺點。

  1. 比如數據的一致性問題,假如主數據庫寫操作完成,那么他的數據會被復制到從數據庫,若是還沒有及時復制到從數據庫,讀請求又來了,此時讀取的數據就不是最新的數據。
  2. 若是主從同步的過程網絡出故障了,導致主從同步失敗,也會出現數據一致性的問題
  3. 主從模式不具備自動容錯和恢復的功能,一旦主數據庫掛掉,從節點晉升為主數據庫的過程需要人為操作,維護的成本就會升高,並且主節點的寫能力,存儲能力都會受到限制。

到此結束。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM