在业务开发中，缓存服务需要满足高可用性，最常用的手段是集群扩展
目前 Redis 流行的集群方案有 官方的Cluster方案，twemproxy 代理方案，哨兵模式，Codis 等方案。
缓存集群的高可用
假设缓存服务器有 3 台，每台缓存的数据是不同的。
在更新缓存时，该放置在哪台机器上呢？
根据 key 获取缓存时，该从哪台服务器上获取？
在数据同步的方案下，所有节点之间的数据都是一样的，不同节点互为副本
- 但会造成较多的服务器资源浪费
- 在更新缓存数据时，还要考虑不同节点之间的一致性
数据不同步的方案，每个缓存节点存储的数据不同，在缓存读写使用一定的策略进行分发
如果需要冗余数据，可以通过缓存集群主从同步实现
不同路由方案的扩容问题
分库分表以后，当存储节点发生增加或减少时
合理的配置分表策略，可以使得数据迁移最小
哈希取模路由
典型的操作—— 通过对缓存 hash (缓存的Key) / 节点数据
哈希取模的方式，适合对固定数量的缓存集群进行路由，但是对横向扩展不友好。
一致性哈希
在负载均衡策略中，可以应用一致性哈希，减少节点扩展时的数据失效或者迁移的情况
一致性哈希是一种特殊的哈希算法，在使用一致性哈希算法后，哈希表槽位数（大小）的改变平均只需要对 K/n 个关键字重新映射，其中 K 是关键字的数量，n 是槽位数量。然而在传统的哈希表中，添加或删除一个槽位几乎需要对所有关键字进行重新映射。
Hash 环的基本思路
获取所有的服务器节点 hash 值，然后获取 key 的 hash，与节点的 hash 进行对比
找出顺时针最近的节点进行存储和读取
假设有4台换成服务器
- A 服务器，地址 hash 结果是 100
- B 服务器，地址 hash 结果是 200
- C 服务器，地址 hash 结果是 300
- D 服务器，地址 hash 结果是 400
某条数据的 key 进行哈希操作，得到200 则存储 B 服务器
某条数据的 key 进行哈希操作，得到260 则存储 C 服务器
某条数据的 key 进行哈希操作，得到500 则存储 A 服务器
如果 D 服务器下线，原先路由到 D 服务器的数据，只要顺时针迁移到 A 服务器就可以
假设有 A, B, C ... J 总共10台服务器，组成一个 哈希环
如果从 F 服务器一直到 J 服务器的 5 个节点宕机
这 5 台 服务器原来的访问，都会被转移到服务器 A 之上，直到把 服务器 A 打爆
这时候流量继续转移到 B 服务器上，出现 缓存雪崩
以上问题属于 数据倾斜，如何解决数据倾斜呢？
添加虚拟节点，对服务器节点进行哈希操作，在整个 哈希环上，均匀添加若干个节点
比如 a1 , a2 都属于 A 节点，b1, b2 都属于 B 节点
在 哈希时 可以平衡各个节点的数据
如何实现一致性哈希？？？
总结
本文分享了应用缓存集群的知识点
包括集群下的高可用，以及哈希取模和一致性哈希的负载均衡策略
负载均衡在数据路由，API 网关，分布式服务调用中非常关键
在服务调用中常用的负载均衡策略包括 轮询，随机，根据响应时间判断等
网友评论