redis_主从复制搭建

单点弊端及解决方式

redis可以单机单进程，做缓存数据库都可以，持久化的方式可以通过rdb和aof。单机部署会有三个弊端:单点故障；容量有限；访问量过多会有压力。
为了解决单机部署的弊端可以通过主从，主备的方式。
主备:主机可用，备机正常状态不用，等主机故障备机顶上；
主从:从机复制主机数据，主机可读写，从机只负责读，分担读的压力；
还可以按照业务模块拆分，不同业务模块的数据放在不同的机器节点上，最终还是要对主机做高可用，多台部署。

做主从或者主备都要考虑多台机器数据一致性的问题，同步阻塞方式会破坏可用性，因为从机在同步主机数据的时候是阻塞的，等到同步成功才可继续响应，如果有机器没有同步成功会一直阻塞僵局，破坏可用性，这是强一致性；
主机同步数据可以采用异步方式，但是会丢失数据不方便；
redis主机同步部署到消息队列上，然后返回，消息队列连接从机，实现同步数据，这是最终一致性，会提高可用性。
主从复制的时候，如果主机宕机了，系统就不可用了，可以采用监控机制，多个监控器监控一个主节点，半数以上的监控认为主机宕机了，就选举一个从节点作为主节点继续服务。客户端访问分区数据可能得到版本不一致的数据，造成网络分区。网络分区是啥意思？网络分区就是这几个服务，是三台机器，我通过网络去访它们的时候，不同的客户端拿到不同的结果，一个被他带跑偏了，一个被他带跑偏了，然后整个的一个服务出现了两种答案，通过网络访问的时候，就出现网络分区了。分区它要容忍性，你能不能容忍它？也就是说它不一定是坏事，因为就看你的数据了，如果说我这边有很多的数据，一共10台机器，需要注册到服务里边，然后其他有几百个人想知道你的后边有哪些机子可以访问，其实每台只需要访问其中一台就可以了。
然后这时候如果出现分区了，他们之间通信出了问题了，然后那10台里边这边注册了2台，在那边注册了8台，或者8台里边还有2台已经挂掉了。无论怎么样，其实他们这10台里边数据会散在这里边，即便他们的数据是不一致的，从外界可以拿到不同的结果，但是他们一定会从这拿出的结果当中找到一个自己可用的，因为他只需要其中一批当中一个可用就可以了。所以这时候其实你就没必要给它做这种强制的一致性和最终一致性，就出现脑裂分区这事还可能容忍，你能容忍它出现分区，因为你不是要求他全量的数据一致。

多个监控，监控一个主机，根据过半原则，少数服从多数，多数认为可以就可以，多数认为有问题就有问题。奇数台更适合，且比较节省成本。

主从复制

1、daemonize介绍
A、redis.conf配置文件中daemonize守护线程，默认是NO。
B、daemonize是用来指定redis是否要用守护线程的方式启动。
2、daemonize 设置yes或者no区别
daemonize:yes:redis采用的是单进程多线程的模式。当redis.conf中选项daemonize设置成yes时，代表开启守护进程模式。在该模式下，redis会在后台运行，并将进程pid号写入至redis.conf选项pidfile设置的文件中，此时redis将一直运行，除非手动kill该进程。
daemonize:no: 当daemonize选项设置成no时，当前界面将进入redis的命令行界面，exit强制退出或者关闭连接工具(putty,xshell等)都会导致redis进程退出

daemonize no
logfile  # 注释掉  日志打印到前台 不在日志文件打印
appendonly no 关闭Aof备份 

redis-server /root/test/6379.conf 启动三台redis实例
5.0版本之前
127.0.0.1:6379> help SLAVEOF

  SLAVEOF host port
  summary: Make the server a replica of another instance, or promote it as master. Deprecated starting with Redis 5. Use REPLICAOF instead.
  since: 1.0.0
  group: server

5.0版本之后
127.0.0.1:6379> help REPLICAOF

  REPLICAOF host port
  summary: Make the server a replica of another instance, or promote it as master.
  since: 5.0.0
  group: server

6379作为主机，6380/6381作为从机

REPLICAOF 127.0.0.1 6379  80.81通过命令连接主机
6379界面显示
26183:M 09 Jan 2022 20:52:23.950 * Ready to accept connections
6380请求连接跟随
26183:M 09 Jan 2022 20:58:36.233 * Replica 127.0.0.1:6380 asks for synchronization
26183:M 09 Jan 2022 20:58:36.233 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'ca35e595a688e8bc2f89cd2878b23fb361e70f30', my replication IDs are 'fd49f94377778985974857e8a4d9a53bfeca37d6' and '0000000000000000000000000000000000000000')
26183:M 09 Jan 2022 20:58:36.233 * Starting BGSAVE for SYNC with target: disk
26183:M 09 Jan 2022 20:58:36.233 * Background saving started by pid 26220
26220:C 09 Jan 2022 20:58:36.235 * DB saved on disk
26220:C 09 Jan 2022 20:58:36.235 * RDB: 0 MB of memory used by copy-on-write
26183:M 09 Jan 2022 20:58:36.315 * Background saving terminated with success
26183:M 09 Jan 2022 20:58:36.315 * Synchronization with replica 127.0.0.1:6380 succeeded
6381请求连接跟随
26183:M 09 Jan 2022 20:59:34.281 * Replica 127.0.0.1:6381 asks for synchronization
26183:M 09 Jan 2022 20:59:34.281 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'e8276fae7804af97815fd65282e3c0dcde853271', my replication IDs are 'b9b7f869e63e7dc110211bbb8079f31aa634e0d0' and '0000000000000000000000000000000000000000')
26183:M 09 Jan 2022 20:59:34.281 * Starting BGSAVE for SYNC with target: disk
26183:M 09 Jan 2022 20:59:34.281 * Background saving started by pid 26224
26224:C 09 Jan 2022 20:59:34.284 * DB saved on disk
26224:C 09 Jan 2022 20:59:34.284 * RDB: 0 MB of memory used by copy-on-write
26183:M 09 Jan 2022 20:59:34.351 * Background saving terminated with success
26183:M 09 Jan 2022 20:59:34.351 * Synchronization with replica 127.0.0.1:6381 succeeded

6380界面显示

[root@iZuf6ir4og87e245nh5ltuZ ~]# redis-server /root/test/6380.conf
26187:C 09 Jan 2022 20:52:29.283 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
26187:C 09 Jan 2022 20:52:29.283 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=26187, just started
26187:C 09 Jan 2022 20:52:29.283 # Configuration loaded
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 5.0.5 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6380
 |    `-._   `._    /     _.-'    |     PID: 26187
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

26187:M 09 Jan 2022 20:52:29.284 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
26187:M 09 Jan 2022 20:52:29.284 # Server initialized
26187:M 09 Jan 2022 20:52:29.284 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
26187:M 09 Jan 2022 20:52:29.284 # 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.
26187:M 09 Jan 2022 20:52:29.284 * Ready to accept connections
26187:S 09 Jan 2022 20:58:35.632 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
26187:S 09 Jan 2022 20:58:35.632 * REPLICAOF 127.0.0.1:6379 enabled (user request from 'id=3 addr=127.0.0.1:38190 fd=7 name= age=323 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=44 qbuf-free=32724 obl=0 oll=0 omem=0 events=r cmd=replicaof')
26187:S 09 Jan 2022 20:58:36.232 * Connecting to MASTER 127.0.0.1:6379
26187:S 09 Jan 2022 20:58:36.232 * MASTER <-> REPLICA sync started
26187:S 09 Jan 2022 20:58:36.232 * Non blocking connect for SYNC fired the event.
26187:S 09 Jan 2022 20:58:36.232 * Master replied to PING, replication can continue...
26187:S 09 Jan 2022 20:58:36.233 * Trying a partial resynchronization (request ca35e595a688e8bc2f89cd2878b23fb361e70f30:1).
26187:S 09 Jan 2022 20:58:36.233 * Full resync from master: b9b7f869e63e7dc110211bbb8079f31aa634e0d0:0
26187:S 09 Jan 2022 20:58:36.233 * Discarding previously cached master state.
26187:S 09 Jan 2022 20:58:36.315 * MASTER <-> REPLICA sync: receiving 175 bytes from master
26187:S 09 Jan 2022 20:58:36.315 * MASTER <-> REPLICA sync: Flushing old data
26187:S 09 Jan 2022 20:58:36.315 * MASTER <-> REPLICA sync: Loading DB in memory
26187:S 09 Jan 2022 20:58:36.316 * MASTER <-> REPLICA sync: Finished with success

6381界面显示

26191:C 09 Jan 2022 20:52:33.169 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
26191:C 09 Jan 2022 20:52:33.169 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=26191, just started
26191:C 09 Jan 2022 20:52:33.169 # Configuration loaded
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 5.0.5 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6381
 |    `-._   `._    /     _.-'    |     PID: 26191
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

26191:M 09 Jan 2022 20:52:33.170 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
26191:M 09 Jan 2022 20:52:33.170 # Server initialized
26191:M 09 Jan 2022 20:52:33.170 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
26191:M 09 Jan 2022 20:52:33.170 # 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.
26191:M 09 Jan 2022 20:52:33.170 * Ready to accept connections
26191:S 09 Jan 2022 20:59:33.382 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.

26191:S 09 Jan 2022 20:59:33.382 * REPLICAOF 127.0.0.1:6379 enabled (user request from 'id=3 addr=127.0.0.1:52832 fd=7 name= age=372 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=44 qbuf-free=32724 obl=0 oll=0 omem=0 events=r cmd=replicaof')
26191:S 09 Jan 2022 20:59:34.281 * Connecting to MASTER 127.0.0.1:6379
26191:S 09 Jan 2022 20:59:34.281 * MASTER <-> REPLICA sync started
26191:S 09 Jan 2022 20:59:34.281 * Non blocking connect for SYNC fired the event.
26191:S 09 Jan 2022 20:59:34.281 * Master replied to PING, replication can continue...
26191:S 09 Jan 2022 20:59:34.281 * Trying a partial resynchronization (request e8276fae7804af97815fd65282e3c0dcde853271:1).
26191:S 09 Jan 2022 20:59:34.282 * Full resync from master: b9b7f869e63e7dc110211bbb8079f31aa634e0d0:70
26191:S 09 Jan 2022 20:59:34.282 * Discarding previously cached master state.
26191:S 09 Jan 2022 20:59:34.351 * MASTER <-> REPLICA sync: receiving 175 bytes from master
26191:S 09 Jan 2022 20:59:34.352 * MASTER <-> REPLICA sync: Flushing old data
26191:S 09 Jan 2022 20:59:34.352 * MASTER <-> REPLICA sync: Loading DB in memory
26191:S 09 Jan 2022 20:59:34.352 * MASTER <-> REPLICA sync: Finished with success

从机不可写只可读

127.0.0.1:6381> set k2 3
(error) READONLY You can't write against a read only replica.
127.0.0.1:6381> 

rdb形式保存到磁盘了

26191:S 09 Jan 2022 21:07:34.073 * 1 changes in 900 seconds. Saving...
26191:S 09 Jan 2022 21:07:34.074 * Background saving started by pid 26243
26243:C 09 Jan 2022 21:07:34.076 * DB saved on disk
26243:C 09 Jan 2022 21:07:34.077 * RDB: 0 MB of memory used by copy-on-write
26191:S 09 Jan 2022 21:07:34.174 * Background saving terminated with success

81断开连接主机知道

26183:M 09 Jan 2022 21:10:32.252 # Connection with replica 127.0.0.1:6381 lost.

启动的时候指定追随的主机,打开AOF备份

redis-server /root/test/6381.conf --replicaof 127.0.0.1 6379  --appendonly yes

开启aof和rdb备份，aof文件会显示rdb在上部分然后下边是追加时点之后的aof日志，rdb文件会记录曾经追随的pid。
主机断了从机会知道。

replica-server-stale-data yes/no

从机启动的时候。备份还原主机数据的时间已有数据是否支持查询等

replica-read-only yes   开启从机的只读模式

redis主从同步数据，可以通过网络直接传输rdb，也可以直接生成rdb到磁盘，然后磁盘读取到从机；

repl-backlog-size 1mb

主和从之间是会有一个增量复制，其实在redis，如果这是一个redis，然后它肯定是先通过rdb给过你一个全量的数据，然后且在他redis内部，它还维护一个小的消息队列，这个消息队列多大，你给出一个大小。
然后第一次的时候，这个文件如果发给了一个redis，redis会 load这个rdb对发送完、收完之后在短时间内比如他挂掉了，然后他又活了，活了之后，然后他肯定还想和别人同步，那么这个数据可能老数据了，他想要人家最全的数据，你可以让他重新落一遍，重新覆盖一遍，但是这样可能传几个g的数据，也可以拿着rdb里边的信息，然后以自己同步的一个数据的offset，然后去redis里的队列里边，你给出一个offset，给出一个偏移量，然后这个offset比如说8，你上次取得的8，人家到20了，那么你从8到20，给你传过就可以了，但是时候取决于队列大小。如果你设置的是1兆，然后你操作特别慢，变更的事特别慢，一年可能一兆都写不满，这事没问题，但是如果你如果写的很快，你就挂了三秒钟，那一秒钟的时候1兆写满了，那么数据会挤出，所以这里边，把8到12已经挤出去了，这时候也告诉你8、9取不到了，这时候要触发一个全量的落rdb的一个过程。

min-replicas-to-write 3
min-replicas-max-lag 10
就是最小给几个写成功。可以规定，最少写几个写成功这么一个数值。如果你关心数据的一个准确和一致性的时候，你是可以设置这件事情的。当然你看能不能给你注掉，所以这个时候是要跟你实际业务场景，你到底是不是要关心这件事情，因为如果开启他的话，就有点慢慢的追向强一致性那边去靠拢，是不是慢慢就在去靠拢了。