redis 主从同步&哨兵模式&codis

主从同步

　一、CPA原理

　　　1. CPA原理是分布式存储理论的基石： C(一致性)；   A(可用性)；  P(分区容忍性);

　　　2. 当主从网络没法连通时，修改操做没法同步到节点，因此“一致性”没法知足

　　　3. 除非咱们牺牲“可用性”，也就是暂停分布式节点服务，再也不提供修改数据功能，知道网络恢复

　　　一句话归纳CAP: 当网络分区发生时，一致性 和 可用性 两难全

　　二、redis主从同步介绍

　　　1. 和MySQL主从复制的缘由同样，Redis虽然读取写入的速度都特别快，可是也会产生读压力特别大的状况。
　　　2. 为了分担读压力，Redis支持主从复制，Redis的主从结构能够采用一主多从或者级联结构。
　　　3. Redis主从复制能够根据是不是全量分为全量同步和增量同步。

　　　注：redis主节点Master挂掉时，运维让从节点Slave接管（redis主从默认没法自动切换，须要运维手动切换）

　　　　　　

　　三、全量同步（快照同步）

　　　　注：Redis全量复制通常发生在Slave初始化阶段，这时Slave须要将Master上的全部数据都复制一份。具体步骤以下：

　　　　1）从服务器链接主服务器，发送SYNC命令；

　　　　2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的全部写命令；

　　　　3）主服务器BGSAVE执行完后，向全部从服务器发送快照文件，并在发送期间继续记录被执行的写命令；

　　　　4）从服务器收到快照文件后丢弃全部旧数据，载入收到的快照；

　　　　5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；

　　　　6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

　　　　7）完成上面几个步骤后就完成了从服务器数据初始化的全部操做，从服务器此时能够接收来自用户的读请求。

　　　　　　

　　四、增量同步

　　　　1. 主节点会将那些对本身状态产生修改性影响的指令记录在本地内存buffer中，而后异步将buffer中指令同步到从节点

　　　　2. 从节点一边执行同步指令达到主节点状态，一边向主节点反馈本身同步到哪里（偏移量）

　　　　3. 当网络状态很差时，从节点没法和主节点进行同步，当网络恢复时须要进行快照同步

　　五、Redis主从同步策略

　　　　1. 主从刚刚链接的时候，进行全量同步；全同步结束后，进行增量同步。

　　　　2. 固然，若是有须要，slave 在任什么时候候均可以发起全量同步。

　　　　3. redis 策略是，不管如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

　　六、注意点

　　　　1. 若是多个Slave断线了，须要重启的时候，由于只要Slave启动，就会发送sync请求和主机全量同步，当多个同时出现的时候，可能会致使Master IO剧增宕机。

 哨兵模式--sentinel

　一、sentinel做用

　　　1. 当用Redis作主从方案时，假如master宕机，Redis自己没法自动进行主备切换

　　　2. 而Redis-sentinel自己也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

　二、sentinel原理

　　　1. sentinel负责持续监控主节点的健康，当主节挂掉时，自动选择一个最优的从节点切换成主节点

　　　2. 从节点来链接集群时会首先链接sentinel，经过sentinel来查询主节点的地址

　　　3. 当主节点发生故障时，sentinel会将最新的主节点地址告诉客户端，能够实现无需重启自动切换redis

　三、Sentinel支持集群

　　　1. 只使用单个sentinel进程来监控redis集群是不可靠的，当sentinel进程宕掉后sentinel自己也有单点问题

　　　2. 若是有多个sentinel，redis的客户端能够随意地链接任意一个sentinel来得到关于redis集群中的信息。

　四、Sentinel版本

　　　1. Sentinel当前稳定版本称为Sentinel 2，Redis2.8和Redis3.0附带稳定的哨兵版本

　　　2. 安装完redis-3.2.8后，redis-3.2.8/src/redis-sentinel启动程序 redis-3.2.8/sentinel.conf是配置文件。

　五、运行sentinel两种方式（效果相同）

　　　法1：redis-sentinel /path/to/sentinel.conf
　　　法2：redis-server /path/to/sentinel.conf --sentinel

　　　　1. 以上两种方式，都必须指定一个sentinel的配置文件sentinel.conf，若是不指定，将没法启动sentinel。

　　　　2. sentinel默认监听26379端口，因此运行前必须肯定该端口没有被别的进程占用。

　六、sentinel.conf配置文件说明

　　　1. 配置文件只须要配置master的信息就好啦，不用配置slave的信息，由于slave可以被自动检测到

　　　2. 须要注意的是，配置文件在sentinel运行期间是会被动态修改的，例如当发生主备切换时候，配置文件中的master会被修改成另一个slave。

　　　3. 这样，以后sentinel若是重启时，就能够根据这个配置来恢复其以前所监控的redis集群的状态。

# sentinel.conf 配置说明
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

'''一、sentinel monitor mymaster 127.0.0.1 6379 2'''
#1）sentinel监控的master的名字叫作mymaster,地址为127.0.0.1:6379
#2）当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了

'''二、sentinel down-after-milliseconds mymaster 60000'''
#1）sentinel会向master发送心跳PING来确认master是否存活，若是master在60000毫秒内不回应PONG 
#2）那么这个sentinel会单方面地认为这个master已经不可用了

'''三、sentinel failover-timeout mymaster 180000'''
#1）若是sentinel A推荐sentinel B去执行failover，B会等待一段时间后，自行再次去对同一个master执行failover，
#2）这个等待的时间是经过failover-timeout配置项去配置的。
#3）从这个规则能够看出，sentinel集群中的sentinel不会再同一时刻并发去failover同一个master，
#4）第一个进行failover的sentinel若是失败了，另一个将会在必定时间内进行从新进行failover，以此类推。

'''四、sentinel parallel-syncs mymaster 1'''
#1）在发生failover主备切换时，这个选项指定了最多能够有多少个slave同时对新的master进行同步
#2）若是这个数字越大，就意味着越多的slave由于replication而不可用，这个数字越小，完成failover所需的时间就越长。
#3）能够经过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态。

 

　七、配置传播

　　1. 一旦一个sentinel成功地对一个master进行了failover，它将会把关于master的最新配置经过广播形式通知其它sentinel，其它的sentinel则更新对应master的配置。

　　2. 一个faiover要想被成功实行，sentinel必须可以向选为master的slave发送SLAVE OF NO ONE命令，而后可以经过INFO命令看到新master的配置信息。

　　3. 当将一个slave选举为master并发送SLAVE OF NO ONE`后，即便其它的slave还没针对新master从新配置本身，failover也被认为是成功了的。

　　由于每个配置都有一个版本号，因此以版本号最大的那个为标准：

　　　1）假设有一个名为mymaster的地址为192.168.1.50:6379。

　　　2）一开始，集群中全部的sentinel都知道这个地址，因而为mymaster的配置打上版本号1。

　　　3）一段时候后mymaster死了，有一个sentinel被受权用版本号2对其进行failover。

　　　4）若是failover成功了，假设地址改成了192.168.1.50:9000，此时配置的版本号为2

　　　5）进行failover的sentinel会将新配置广播给其余的sentinel，发现新配置的版本号为2时，版本号变大了，
　　　　  说明配置更新了，因而就会采用最新的版本号为2的配置。

codis

　一、为何会出现codis

　　　1. 在大数据高并发场景下，单个redis实例每每会没法应对

　　　2. 首先redis内存不易过大，内存太大会致使rdb文件过大，致使主从同步时间过长

　　　3. 其次在CPU利用率中上，单个redis实例只能利用单核，数据量太大，压力就会特别大

　二、什么是codis

　　　1. codis是redis集群解决方案之一，codis是GO语言开发的代理中间件

　　　2. 当客户端向codis发送指令时，codis负责将指令转发给后面的redis实例来执行，并将返回结果转发给客户端

　三、codis部署方案

　　　1. 单个codis代理支撑的QPS比较有限，经过启动多个codis代理能够显著增长总体QPS

　　　2. 多codis还能起到容灾功能，挂掉一个codis代理还有不少codis代理能够继续服务

　　　　　　

　四、codis分片的原理

　　　1. codis负责将特定key转发到特定redis实例，codis默认将全部key划分为1024个槽位

　　　2. 首先会对客户端传来的key进行crc32计算hash值，而后将hash后的整数值对1024进行取模，这个余数就是对应的key槽位

　　　3. 每一个槽位都会惟一映射到后面的多个redis实例之一，codis会在内存中维护槽位和redis实例的映射关系

　　　4. 这样有了上面key对应的槽位，那么它应该转发到那个redis实例就很明确了

　　　5. 槽位数量默认是1024，若是集群中节点较多，建议将这个数值大一些，好比2048,4096

　五、不一样codis槽位如何同步 

　　　1. 若是codis槽位值存在内存中，那么不一样的codis实例间的槽位关系得不到同步

　　　2. 因此codis还须要一个分布式配置存储的数据库专门来持久化槽位关系

　　　3. codis将槽位关系存储在zookeeper中，而且提供一个dashboard能够来观察和修改槽位关系

　六、codis优缺点

　　优势

• 对客户端透明,与codis交互方式和redis自己交互同样
• 支持在线数据迁移,迁移过程对客户端透明有简单的管理和监控界面
• 支持高可用,不管是redis数据存储仍是代理节点
• 自动进行数据的均衡分配
• 最大支持1024个redis实例,存储容量海量
• 高性能

　　缺点

• 采用自有的redis分支,不能与原版的redis保持同步
• 若是codis的proxy只有一个的状况下, redis的性能会降低20%左右
• 某些命令不支持,好比事务命令muti
• 国内开源产品,活跃度相对弱一些