Redis再战之AKF、CAP、哨兵机制

AKF

AKF扩展立方体（Scalability Cube），是《架构即未来》一书中提出的可扩展模型，这个立方体有三个轴线，每个轴线描述扩展性的一个维度，他们分别是产品、流程和团队：
X轴 —— 代表无差别的克隆服务和数据，工作可以很均匀的分散在不同的服务实例上；
Y轴 —— 关注应用中职责的划分，比如数据类型，交易执行类型的划分；
Z轴 —— 关注服务和数据的优先级划分，如分地域划分。

运行一个redis实例会有哪些问题

• 单点故障
• 容量瓶颈
• 访问压力

解决问题

• x轴：在x轴方向上，做N个主机的全量镜像数据的副本，主redis与这些副本的关系为主从。主机可以对外提供read / write ，从机可以对外提供read（读写分离）。结合高可用， 可以解决单点故障和容量瓶颈的问题，只是解决了 read 的压力，而没有解决 write 的压力。
• y轴：在y轴方向上，可以把之前一台redis中的数据按照业务功能来拆分成不同的redis实例存储，并且每个redis实例都可以再次做x轴的镜像副本进行读写分离，当然，x轴和y轴之间不是必须要结合使用。y轴的拆分解决了容量瓶颈问题和数据访问压力的问题。
• z轴：如果y轴的某个redis实例过于臃肿，还可以把这个redis实例进行z轴的拆分，也就是把这个redis实例里面的数据按照一定规则查分。比如：取模，优先级等规则再次查分成多个redis，使得不同的数据出现在固定的redis里。

问题： 如何解决数据一致性问题

数据一致性（主从复制原理）

强一致性

所有节点同步阻塞，直到数据全部一致。

• 引发问题：
  如果其中一台slave挂掉或者网络波动引起超时，即使其他salve都返回写入成功给master，master也会认为所有从机都写入失败，进而都进行回撤，最终客户端会认为写入失败。写入失败代表服务不可用，所以数据强一致性会破坏可用性！

为什么我们要把单机一变多为集群？

• 就是单点故障，解决可用性的问题。但是强一致性中，只要其中一台机器出现异常，就会导致整个模块不可使用，问题又回到了原点。
• 解决办法 : 给强一致性降级，采用异步的方式，容忍丢失一部分数据，就是弱一致性。

弱一致性

• master收到Client命令直接返回给客户端ok，
• master会异步的通知两个slave写操作，如果两个slave挂了导致写入失败，master也挂了。再重启之后slave就拿不到之前的master的写操作了，等于丢了一批数据。

问题: 如何解决数据丢失问题？
最终一致性（扯远了）

最终一致性

• 在master和slave之间，添加一个可靠、响应速度够快 的 集群（比如：kafka），master到kafka之间为同步阻塞状态。master在写入的时候并没有直接通知两个slave，而是通知kafka，由kafka通知两个slave。如果master和kafka之间能够足够快的写入响应成功的话，就可以直接给Client返回OK了。
• 只要最终两个slave从kafka中取到数据，那么最终两个slave就会和master的数据达成一致，数据就不会丢失。

问题： 最终一致性：master和slave之间维护一个可靠的集群。
但是一个客户端从一个黑盒化的集群中取数据。有可能会从master取到，也有可能从slave中取到，在slave和master数据最终达成一致之前，有可能取到不一致的数据。

CAP

CAP理论指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项

• 主备：Client只能访问master，不会访问slave。slave就是为了master挂了后接替master，使Client能够从新的master拿到数据，slave是不会参与业务的。
• 主从：Client可以访问master，也可以访问slave。

主从集群搭建

老版用法
help slaveof

#新版用法
help replicaof

replicaof 127.0.0.1 6379

redis-server ~/test/6381.conf --replicaof 127.0.0.1 6379			
//开启了aof，会导致6379发送全量rdb给6381
redis-server ~/test/6381.conf --replicaof 127.0.0.1 6379	--appendonly yes 

配置文件中配置主从复制：

1. replicaof <masterip> <masterport> ： 配置master的ip和端口
2. masterauth <master-password> ：访问master的密码
3. replica-serve-stale-data yes ： 在slave启动时，如果master中的数据量很大，在数据传输过程中，slave中的老的数据对外暴露，如果值为 no 需要同步完才能对外提供服务 。
4. replica-read-only yes ：yes表示salve只读；no表示slave支持写入。
5. repl-diskless-sync no ： 如果为yes，表示直接走网络发送RDB。
6. repl-backlog-size 1mb ： 在master里会维护一个消息队列缓存临时写入的数据，salve如果挂掉后又启动了，master可能会有一个数据的增量，slave可以重新在master里面拿一份RDB恢复数据，也可以用RDB文件给master一个offset，从master队列中根据offset取出增量的数据恢复，这个配置的1mb就是设置这个队列的大小，如果master访问量大，把slave给出的offset对应的数据挤出，那么slave是无法恢复被挤出的数据的，这个时候就触发一个全量的RDB。
7. min-replicas-to-write 3：要求有三个健康的slave，master才能写成功。
8. min-replicas-max-lag 10：延迟小于min-replicas-max-lag秒的slave才认为是健康的slave

总结：

• 主从复制搭建，可以在slave中使用replicaof 命令追随master。
• master对外提供全量读写，slave对外提供读。
• slave挂了可以直接重启，如果以前有追随master记录，那么就不会发生全量rdb。但是开启了aof就一定会发生全量rdb传输。

问题： 那么master挂了怎么办？ 答案：哨兵机制。

哨兵机制(过半机制)

多个哨兵根据过半原则监控redis是否活着进行裁决

#建立三个配置文件26379.conf，26380.conf，26381.conf 
port 26379
sentinel monitor mymaster 127.0.0.1 6379 2

port 26380
sentinel monitor mymaster 127.0.0.1 6379 2

port 26381
sentinel monitor mymaster 127.0.0.1 6379 2

redis-server 6379.conf
redis-server 6380.conf --replicaof 127.0.0.1 6379
redis-server 6381.conf --replicaof 127.0.0.1 6379

redis-server 26379.conf --sentinel
redis-server 26380.conf --sentinel
redis-server 26381.conf --sentinel

/*哨兵能自动发现master上面有哪些slave，因为master被slave追随的时候 master就能收到slave的信息，所以哨兵监控master就能知道有哪些slave.但是底层是如何实现的呢？*/

哨兵之间通信的原理？

• 哨兵使用了redis自带的发布订阅功能，哨兵会去监控master拿到两个slave分别是谁，同时在存活的master开启发布订阅发现其他的哨兵。

本文地址：https://blog.csdn.net/python_start/article/details/107525579