这种使用多个缓存的情况，就组成了二级缓存、三级缓存等多级缓存了。总之，通过缓存的方式尽量减少用户的的访问链路的长度。
有了缓存之后，还会带来一个问题，那就是热点数据如果都被缓存在同一个缓存服务器上，那么这个服务器也可能被打挂。
所以，很多人在加了缓存之后， 还可能同时部署多个缓存服务器，如Redis同时部署多个服务器集群。并且实时的将热点数据同步分发到多个缓存服务器集群中，一旦有的集群扛不住了，立刻做切换。
单纯的对于Redis热key缓存来说，Redis是有分片机制的，同一个热key可能会都保存在同一个分片中，所以还可以在多个分片中都把热key同步一份，使得查询可以同时从多个分片进行，减少某一个分片的压力。
因为有分片，还有一种情况，就是有可能多个热key都会分到同一个分片中，为了减少这种情况的发生，可以增加更多的分片来分担流量。
京东的热key探测
前面简单介绍了热key的发现与解决，这种问题其实最明显的发生就是在电商系统或者像微博这种社交系统中。
所以很多公司内部也有很多成熟的方案。
今天想介绍一个京东内部的框架——JD-hotkey ，这是京东 APP 后台热数据探测框架。
这个框架在Gitee上面开源了（https://gitee.com/jd-platform-opensource/hotkey ），官方描述是这样的：
对任意突发性的无法预先感知的热点数据，包括并不限于热点数据（如突发大量请求同一个商品）、热用户（如恶意爬虫刷子）、热接口（突发海量请求同一个接口）等，进行毫秒
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/67658.html