高并发系统设计十二-缓存的使用二（缓存的使用二-缓存如何高可用）

缓存的使用二-缓存如何高可用

为了减少数据库的压力，我们开始使用缓存承担大部分的读压力，在提升性能的同时也需要保证系统的稳定性。

分布式缓存的高可用方案有以下几种：

• 客户端方案
• 中间代理方案
• 服务端方案

1、客户端方案

• 写入数据时，需要把被写入缓存的数据分散到多个节点中，即进行数据分片
• 读数据时，利用多组的缓存来做容错，有主从和多副本两种策略 来提升缓存系统的可用性

1.1、缓存数据如何分片

按照分片算法将数据打散到多个不同的节点上，每个节点上存储部分数据，

分片算法常见的有：

• Hash 分片算法
• 一致性 Hash 分片算法

1.1.1、Hash 分片算法

对缓存中的 Key 做哈希计算，然后对总的缓存节点个数取余

缺点

当增加或者减少缓存节点时，缓存总的的节点个数发生变化造成计算出来的节点发生变化，从而造成缓存失效不可用。

1.1.2、一致性Hash 算法

将整个 Hash 值空间组成一个虚拟的圆环，然后将缓存节点的 IP 地址或者主机名做 Hash 取值后，放置在这个圆环上。当我们需要确定某一个 Key 需要存取到哪个节点上的时候，先对这个 Key 做相同的 Hash 取值，确定在环上的位置，然后按照顺时针方向在环上计数，遇到的第一个缓存节点就是要访问的节点。

缺点

• 缓存节点在圆环上分布不平均，会造成部分缓存节点的压力比较大，当某个节点发生故障时，这个节点所要承担的访问都会被顺移到另一个节点上，造成该节点压力变大

• 一致性Hash算法的脏数据问题

在使用一致性Hash算法时一定要设置缓存的过期时间这样当发生偏移时，之前存储的脏数据可能就过期了，就可以减少存在脏数据的几率。

2、中间代理层方案

为了解决客户端方案 只能在单一语言系统之间复用 的问题

业界也有很多中间代理层方案，比如 Facebook 的Mcrouter，Twitter 的Twemproxy，豌豆荚的Codis。

所有缓存的读写请求都是经过代理层完成的。代理层是无状态的，主要负责读写请求的路由功能，并且在其中内置了一些高可用的逻辑，不同的开源中间代理层方案中使用的高可用策略各有不同。

比如在 Twemproxy 中，Proxy 保证在某一个 Redis 节点挂掉之后会把它从集群中移除，后续的请求将由其他节点来完成；而 Codis 的实现略复杂，它提供了一个叫 Codis Ha 的工具来实现自动从节点提主节点，在 3.2 版本之后换做了 Redis Sentinel 方式，从而实现 Redis 节点的高可用

3、服务端方案

Redis 在 2.4 版本中提出了 Redis Sentinel 模式来解决主从 Redis 部署时的高可用问题，它可以在主节点挂了以后自动将从节点提升为主节点，保证整体集群的可用性

Redis Sentinel 也是集群部署的，这样可以避免 Sentinel 节点挂掉造成无法自动故障恢复的问题，每一个 Sentinel 节点都是无状态的。

在 Sentinel 中会配置 Master 的地址，Sentinel 会时刻监控 Master 的状态，当发现 Master 在配置的时间间隔内无响应，就认为 Master 已经挂了，Sentinel 会从从节点中选取一个提升为主节点，并且把所有其他的从节点作为新主的从节点。

Sentinel 集群内部在仲裁的时候，会根据配置的值来决定当有几个 Sentinel 节点认为主挂掉可以做主从切换的操作，也就是集群内部需要对缓存节点的状态达成一致才行。