x轴：全量、镜像。复制多个镜像，解决单点故障
y轴：按业务功能拆分为多个实例，同时在x轴方向同时创建多份镜像。
z轴：优先级、逻辑再拆分。比如说某个模块数据过多，可以拆分为多个Redis客户端，全量数据分为多份，每个Redis中存一部分数据。
此时虽然解决了单实例存在的三个问题，那么又会带来数据一致性问题。
Redis一般使用主从复制的模式，但是此时主自己又是一个单点。
对主做高可用并不是说不让主出现问题，而是对外表现为没有出现问题。人工可以去把其中一个从机设置为主，让另一个从去追随它。但是人往往是不可靠的，所以需要技术或程序来实现，主要是一个程序就会有单点故障的问题，所以程序也必须是一个集群。
假如说有三个监控程序监控一个主Redis的存活状态，那么也就是说Redis的存活状态由三个监控程序说了算。
HA高可用（x轴）:
sentinel哨兵代替人工去自动修复故障，可以是单机也可以是集群，只监控master节点，因为master节点上有slave节点信息，通过发布订阅发现其他哨兵。
上述算法都是发生在客户端的，那么当客户端连接Redis的时候，socket连接过多，对server端的影响是连接成本很高。
此时可以用代理的方式解决，让所有的客户端去连接中间代理，此时server端的socket连接压力不大，只需要关心代理层性能即可。
如果客户端很多，前面压力过大，一台代理撑不住的话，代理可以做一个集群，在代理之前还可以加一层LVS，不需要对代理层做高可用，因为如果LVS挂掉的话，后面服务都不可用了，所以LVS会做一个主备，主备之间靠keepalived来管理，除了可以监控LVS之外，还可以监控代理层的健康状态，如果其中一台代理挂了，那么只会走另一台。
不管是在client还是proxy的算法，新增一台Redis的时候总会有问题，要么重新取模全局洗牌，要么丢失一部分数据，所以干脆一开始取模值大一点，比如说取模为10，模数值的范围09。此时中间还需要一层`mapping`做映射，假如说一开始有两台Redis1和Redis12，Redis1上是04槽位，Redis2上是5~9槽位，这样新增一个节点的时候，只需要从之前的Redis上让出几个槽位即可。那么在数据迁移的过程中，允不允许修改？这时候可以先把时点数据RDB传过去，再把增量的日志传过去。
cluster模式：只需要一个client，并且是无主模型，client连哪一个都行，在每一个Redis都有hash算法，还需要有其他Redis上的映射关系，假如说client要get一个k1，而k1根据hash取模算出来在4号槽位，而此时client连接Redis2，那么会返回给客户端并跳转到key对应所在的Redis节点，找到之后直接返回给client即可。（查询路由）
数据分治会导致聚合操作难以实现，比如说求两个集合的交集，两个集合在不同的Redis节点上。事务也难以支持，Redis并没有去实现，但可以人为定义进行hash的算法，比如说用相同的前缀（键哈希标签），这样数据就会存储到同一Redis节点上。
Redis的key会有过期时间，包括自带的LRU、LFU导致的淘汰key，当在过期的时候，正好有大量并发请求来查询这个key，这个时候请求会直接打到数据库上，称为缓存击穿。强调的是高并发对某个过期key查询。
解决方案：
Redis是单进程单实例的，用setnx()加锁，第一个去获取key发现没有，然后加一把锁，加锁成功的话，就去访问数据库，后面的加锁失败，就sleep等待，一般根据实际业务场景选择等待时间。
问题1：只要加锁就可能会有死锁的问题，假如说第一个人挂了怎么办？
问题2：如果没挂，但是访问数据库阻塞了，导致锁超时了怎么办？
从业务系统接收到的查询请求的是系统中根本不存在的数据，称为缓存穿透。
解决方案：
布隆过滤器：三种使用方式
布隆过滤器的一个缺点是不能删除，如果有必要的话可以用布谷鸟过滤器，或者把key的值设为null。
大量的key同时失效，间接造成大量的访问到达数据库，为缓存雪崩。
解决方案：
两方面，一是时点性无关的话，把过期时间随机，防止大量key同时过期。
如果是业务上0点，或者1点失效的话，可以强依赖击穿方案，也可以在业务层加判断，做零点延迟，这样压力不会到Redis。
