redis 集群&&高可用
集群
单机,单节点,单实例 存在的问题
- 单点故障
- 容量有限
- 压力(网络 && cpu)
CAP原则
- CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。 CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
同步策略(非redis的策略)
市面上的主备方案
- crud 操作只连主节点,备份节点只用来故障恢复
- 只可以解决单点故障的问题不能解决其他问题
市面上的主从复制方案(企业多为该方案)
- 对主节点做高可用
主从节点如何检查节点是否健康?
- 所有从节点都会监控主节点
- 可以设置策略当几个从节点检查到主节点异常时切换某个从节点为主节点
- redis判断主节点是否健康是通过从节点投票的形式,可以配置当多少个节点认为主节点不健康时就对redis进行主从切换。
脑裂问题
- 当节点选举主备切换策略时有可能两边打平的情况，比如一共4个子节点 配置策略为2时,会出现脑裂现象，此时可以追加1个字节点解决该问题
- 解决脑裂问题的方案是过半，节点数是配置切换参数的两倍+1 都可以解决该问题。配置参数推荐为(n/2 + 1)
- redis 从节点为基数台更靠谱，因为需要配置的故障台数和偶数是一致的并且更不容易出现脑裂
redis 主从复制
- redis主从复制
- Redis使用默认的异步复制，其特点是低延迟和高性能，是绝大多数 Redis 用例的自然复制模式。但是，从 Redis 服务器会异步地确认其从主 Redis 服务器周期接收到的数据量。
- redis 主从复制配置如下
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync
norepl-backlog-size 1mb #增量复制
min-replicas-to-write 3
min-replicas-max-lag 10
存在的问题
- 主从节点做到强一致性时很困难的，所以通常保证的是最终一致性
高可用
哨兵模式
- 检查主节点是否健康,可以部署多个哨兵同时监控。
如何解决redis 容量问题，以及并发压力问题
基于客户端解决
)
- 微服务理念按照业务拆分多个redis集群即可。
- 有时候拆分不了，比如淘宝商品数据就几百g,那么可以通过某些特定的规则，由客户端选择不同的redis集群，比如key 进行hash后取磨,判断其命中哪一个redis集群，这种做法有个弊端,一开始就要决定%的值,可扩展性比较差。
- random方式，随机写到任何一个集群里，这种形式比较少见，因为你不知道读取的时候去哪个redis集群中获取，除了生产者消费者模型会使用这种方式。
- hash环，会通过hash算法 算出命中哪一个redis集群(在增加节点后会造成一部分的缓存无法命中，解决方案是取两个)
使用代理层解决，这样客户端不用吃这块业务逻辑
- 使用代理层去负责和redis server 的调度工作。
- 可以使用twitter 的开源框架，这个框架支持很多分发逻辑github: twemproxy
使用预分区实现
- 比如我预分了10个区，但是我只有两个redis集群，则我只需要把0-4 分给第一个redis集群,5-9分给第二个redis集群,当我们需要新增一个集群时只需要把第一个集群和第二个集群合计三个模的数据移动到新的集群即可。
存在的问题
- 当要对多个redis 集群 无法进行事务控制(解决方案 一半由业务控制，业务保证同一事务里的数据打到同一个redis集群中。
redis 官方的解决方案
- 分区blog
- 分区可以在程序的不同层次实现。
- 客户端分区就是在客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取。大多数客户端已经实现了客户端分区。
- 代理分区 意味着客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据。代理根据分区规则决定请求哪些Redis实例，然后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy
- 查询路由(Query routing) 的意思是客户端随机地请求任意一个redis实例，然后由Redis将请求转发给正确的Redis节点。Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个redis节点转发到另一个redis节点，而是在客户端的帮助下直接redirected到正确的redis节点。