为什么需要关注缓存命中率
缓存命中率 = 命中缓存的请求数 / 总请求数假设系统 QPS 为
10000/s ，每次调用会访问 10 次缓存或者数据库。当缓存命中率下降 1 %，那么数据库每秒就会增加 10000 * 10 * 1% = 1000 次请求。一般来说，我们的单节点 MySQL 的读请求量峰值为 1500/s ，这增加的 1000 次可能会给数据库带来极大的冲击。为什么需要缓存高可用
因为缓存命中率仅仅下降 1% 造成的影响就如此可怕，更不用说缓存节点故障了。
因此，单节点的缓存就成了系统中最大的隐患，所以我们需要解决这个问题，来提升缓存的可用性。
分布式缓存的高可用方案
- 客户端方案
- 中间代理方案
- 服务端方案
客户端方案
一般也成为 Smart Client 。通过制定一些数据分片和数据读写的策略，可以实现缓存的高可用。
需要关注两个方面：
- 写入数据时，需要把被写入缓存的数据分散到多个节点中，进行数据分片。如使用哈希一致性算法
- 读数据时，可以利用多组的缓存做容错，提升缓存系统的可用性。读数据这里可以使用主从或者多副本两种策略。
缓存数据如何分片
原理：不要把鸡蛋放在同一个篮子里
中间代理层方案
客户端方案限定了只能在单一语言系统之间复用，而采用中间代理层方案就能解决跨语言的客户端做到缓存高可用。
比如，我们可以通过通用协议（如 Redis）来实现在其他语言中的复用。
服务端方案
Redis Sentinel 模式解决主从 Redis 部署时的高可用问题。
Redis 主从选取模式涉及到 Raft 算法。
总结
客户端方案：
好处：性能没有损耗
缺点：客户端的逻辑复杂切在多语言环境下不能复用
中间代理层方案：
缺点：性能上会有一些损耗
服务端方案：
依赖于组件的实现。
运维上会增加一些复杂度。
思考时间
结合过往项目经历，聊一聊缓存高可用的重要性。如当缓存可用性下降会造成什么严重问题？如何保证缓存的高可用呢？
//TODO