关于热点key的思考

背景

我们是做客服系统的，对于知识信息会缓存在redis当中，用以提升问答时的响应时延，同时提高并发量。之后，在面试时，面试时针对这个问题提出了一个疑问，每次问答都需要获取当前知识的版本号，那这个版本号是不是就成为了一个热点数据，会产生什么问题，如何避免？我当时给的答案是可能会造成流量的倾斜，可能会造成Redis单点故障。但是关于解决方案的话，当时提出的是将key打散到各个Redis实例上，以实现流量的均衡，当时面试官让具体描述一下做法。当时没有太好的思路。现在整理一下相关能想到的方案，未必合理，还望各位大佬批评指点。

方案一

针对于Redis主从部署方式。我认为可以采用如下方案。

• 主写从读，增加从节点以实现流量的均衡。
• 如果是主写主读方案，那就不涉及这个问题了。

方案二

针对于Redis Cluster部署方式，我认为需要引入ZK做key的发布与订阅。

• 通过多个key，用以实现每个master实例上均有对应的数据
• 当更新时，将更新后的key值写入zk，用zk来维护当前所有的key的内容。业务端监听节点信息，用以获取当前所有的key。
• 在访问时，随机选择一个key进行访问，用以流量的均衡。

存在的问题

• 在更新时，会存在key不一致的问题，如已经更新完了key1，key2和key3还未更新。所以该方案，只能保证最终的一致性。无法保证强一致性。

方案三

增加本地缓存，该方案是当前我们采用的方案，所以我理解面试官当时期望的是针对于Redis单实例问题的解决方案。
简单介绍一下该方案。由于当前热点key是读多写少，因此，除了Redis缓存外，我们是增加了本地缓存，各个实例上的数据处理，均直接本机处理就好。

• 该方案的优势，本地读取，速度更优于其他方案
• 不存在Redis流量倾斜问题

存在的问题

• 当存在变化时，本地缓存如何更新。当前我们的方案是通过MQ的广播模式直接推送到各个实例上。对于已经新增加的业务实例，直接从Redis上获取。
• 同样会存在短暂性的不一致问题。

以上是我对于该问题的一些思考，目前仍然无法解决强一致性问题。如果有哪位大佬或者当时的面试官看到该题目，还望不吝赐教。