由简入繁,水滴石穿。
Redis 的架构模式
单机版
直接说,就是只有一个redis,坏了就没得用那种。
- 特点:简单,很简单。
- 缺点:
- 存储容量有限制,取决于所在服务器的能力
- 处理能力有限,也取决于所在服务器的能力
- 高可用性无,没有高可用,坏了就没得用
主从复制
高端点的单机版,Redis的复制(replication)功能允许用户根据一个Redis服务器来创建多个任意的复制品,其中被复制的服务器就是主服务器(master),而通过复制出来的服务器就是从服务器(slave)。只要主从服务器之间的网络连接正常,主从服务器之间就具有相同的数据,主服务器会一直将自身数据同步给从服务器,保证主从服务器上面的数据相同。
- 特点:
- master、slave两个角色
- master、slave数据是相同的
- 可以降低master读数据压力,可以将读操作交给slave
- 缺陷:
- 没有高可用,master宕机后还是没得用
- slave为master减轻读压力,但是master还是存在写压力
哨兵模式
高端模式,解决了高可用、自动进行故障转移。
- 监控(monitoring):Sentinel会不断检查主服务器和从服务器是否正常工作;
- 提醒(Notification):当被监控的某个Redis服务器出现问题,Sentinel可以通过API向管理员或者其他程序发送通知;
- 自动故障迁移(Automatic failover): 当一个主服务器不能正常工作,Sentinel会进行一次自动故障迁移。
- 特点:
- 高可用
- 监控所有节点
- 可以自动故障迁移
- 缺点:
- 主从模式切换时间中,数据会丢失
- master写压力没有解决
集群模式(Proxy)
高端玩法。使用Twitter开源的Twemproxy,一个Redis和Memcache快速/轻量级代理服务器,他是一个快速的单线程代理程序,支持Memcached ASCII协议和Redis协议。
- 特点鲜明:
- 1.支持多种hash算法:MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins;
- 2.支持自动删除失败节点。
- 3.后端Sharding分配逻辑对业务透明,业务的读写方式和操作单个Redis一致;
- 缺点:
- 维护高可用的成本增加,因为同样要维护proxy的高可用
集群模式(直连)
Redis 3.0后版本支持Redis-cluster集群,采用的是无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。
- 特点:
- 无中心架构,少了proxy代理层
- 数据按照slot存储分布在多个节点,节点间数据共享,可动态调整数据分布
- 可扩展性,节点可以动态增加或者减少
- 高可用性,当有节点不可用时,集群仍然可用,可以增加slave做备份数据副本
- 实现故障自动failover,节点之间通过gossip协议交换状态信息,通投票机制完成slave到master的角色提升
- 缺点:
- 资源隔离性差,很容易出现相互影响
- 数据通过异步复制,强一致性不能保证
高可用
从上面的几种Redis架构中可以看到,Redis的高可用主要由Cluster集群模式、sentinel哨兵模式,当主服务器挂掉后,会从节点中选择出一个新的主服务器,并调整其他从服务器Slave关联到新的master上。
选举策略一般分三种:
- Slave的Priority设置的越低,优先级就越高;
- 相同情况slave复制的数据越多,优先级越高;
- runid越小,越容易被选中升为master;
如果使用Sentinel模式,为了保证Sentinel的高可用,通常会部署3个Sentinel。那么多个Sentinel之间通过Raft协议来保证自身的高可用。
关于Raft协议,这个协议是大师提出的,非常的牛,解决了很多分布式一致性的问题,这个理解起来也不容易,我也没怎么看这个算法。
Sentinel用三个实例去保证健壮性,虽然不能保证数据不丢失,但是在高可用上是可以保证的。
- 监控:负责监控集群内的Redis Master和Slave进程是否正常工作;
- 消息通知:如果发现某一个Redis实例出现问题,可以发送消息通知出去;
- 故障转移:如果Master故障了,可以自动转移到slave上;
- 配置中心:故障转移后,能通知client去新的Master;