欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

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

程序员文章站 2022-07-09 19:54:34
文章目录AKF数据一致性(主从复制原理)强一致性弱一致性最终一致性CAP主从集群搭建哨兵机制(过半机制)哨兵之间通信的原理?AKFAKF扩展立方体(Scalability Cube),是《架构即未来》一书中提出的可扩展模型,这个立方体有三个轴线,每个轴线描述扩展性的一个维度,他们分别是产品、流程和团队:X轴 —— 代表无差别的克隆服务和数据,工作可以很均匀的分散在不同的服务实例上;Y轴 —— 关注应用中职责的划分,比如数据类型,交易执行类型的划分;Z轴 —— 关注服务和数据的优先级划分,如分地域...

AKF

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

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

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

解决问题
Redis再战之AKF、CAP、哨兵机制

  • 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的写操作了,等于丢了一批数据。

问题: 如何解决数据丢失问题?
最终一致性(扯远了)

最终一致性

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

  • 在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)这三项中的两项

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

  • 主备: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是否活着进行裁决
Redis再战之AKF、CAP、哨兵机制

#建立三个配置文件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再战之AKF、CAP、哨兵机制

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

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

相关标签: redis