redis docker搭建主从复制

docker 命令

docker run -p 6381:6379 --name redisMaster -v /home/tools/redis/masterSlave/master/redis.conf:/etc/redis/redis.conf -v /home/tools/redis/masterSlave/master/data:/data -d redis:6.0 redis-server /etc/redis/redis.conf

docker run -p 6382:6379 --name redisSlave -v /home/tools/redis/masterSlave/slave/redis.conf:/etc/redis/redis.conf -v /home/tools/redis/masterSlave/slave/data:/data -d redis:6.0 redis-server /etc/redis/redis.conf

slaveof 192.168.0.134 6381

测试主从


服务端配置slaveof的方式slave服务不可达后不会断点续传。每次重启都需要重新配置slaveof

修改配置 redis.conf slave服务重启后会断点续传

# 配置主从复制
#从本机6379的redis实例复制数据，Redis5.0之前使用slaveof
replicaof 192.168.0.134 6381
# 配置从节点只读
replica‐read‐only yes 

原理

Redis主从工作原理 如果你为master配置了一个slave，不管这个slave是否是第一次连接上Master，它都会发送一个PSYNC命令给master请求复制数据。

master收到PSYNC命令后，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件，持久化期间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。

当持久化进行完毕以后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后再加载到内存中。然后，master再将之前缓存在内存中的命令发送给slave。

当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送给多个并发连接的slave。

断点续传

当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，redis改用可以支持部分数据复制的命令PSYNC去master同步数据，slave与master能够在网络连接断开重连后只进行部分数据复制(断点续传)。

master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的 slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master 继续进行未完成的复制，从所记录的数据下标开始。

如果master进程id变化了，或者从节点数据下标 offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。

主从复制(部分复制，断点续传)流程图:

一致性问题

什么情况会导致一致性问题：主节点挂机了，数据还没有同步到从节点，重新选举master节点时，数据丢失；虽然会发生，但是几率小

redis 主从集群或者哨兵集群或集群模式，不是强一致性，所以会有可能数据一不一致的问题，但是可以容忍。

例如：

• 分布式锁：当前场景必须要求强一致性可以选择zookeeper，但是性能没有redis好，各有优缺点各有取舍，因为考虑redis 就是因为性能好，高并发，单线程；虽然有redis客户端（redlock）可以实现强一致性，但是性能或者存在bug不推荐使用
  • 分布式场景复杂的情况可以使用redission实现分布式锁，因为内部使用的是lua脚本hash方式实现的
  • 简单场景可以自己写setnx实现，保证锁能释放即可满足一般的场景
  • 如减库存场景，实现一个高并发的分布式锁，可以将库存分段，这样加锁的key就是落在不同的redis集群节点上，实现类似水平扩容提高锁性能，可以参考ConcurrentHashMap源码