1热点key产生的原因1.1消耗的数据>>>电商秒杀活动、微博明星头条大量发布、浏览的热点新闻、热评等产生的数据阅读moreandwrite场景1.2分片请求超过单点性能极限。服务器在读取数据和访问数据时，数据往往是碎片化的。在这个过程中，相应的Key会在一个hostServer上被访问到。当访问超过服务器限制时，会导致热点Key问题。2热点key有害流量过于集中，请求过多突破物理网卡限制，缓存分片服务坏掉。缓存击穿热点key请求某台主机，当超过主机网卡上限时，服务器内其他服务无法正常进行。="热点过于集中，热点Key缓存过多，超过当前缓存容量，导致缓存分片服务崩溃="缓存服务崩溃。这时候如果再有请求，就会缓存到后台DB，导致缓存崩溃。会造成缓存雪崩。3解决方案3.1服务端缓存客户端将请求发送给服务端，服务端是一个多线程服务，基于CacheLRU策略拥有本地缓存??空间。当服务器自身拥塞时，服务器不会再向DB发送请求，而是直接返回。只有当服务器自身畅通时，客户端请求才会发送到DB，数据才会被重写到缓存中。至此，缓存的访问和重构就完成了。缺陷Cache失效，多线程构建缓存问题Cache丢失，缓存构建问题脏读3.2使用Memcache和Redis在客户端单独部署缓存。在使用过程中，Client首先访问服务层，然后访问同一主机上的缓存层。该方案具有就近接入、速度快、无带宽限制等优点。缺陷浪费内存资源脏读3.3本地缓存缺陷需要提前知道热点缓存容量有限不一致时间增加热点key遗漏3.4随机后缀使用Redis作为缓存，可以将一个热点key的缓存查询压力分散到多个Redis节点。一个很热的数据，数据更新不是很频繁，但是查询很频繁，要保证100%的缓存命中率，怎么处理呢？核心思想：空间换时间，即保留2份同一个热键：无后缀的有TTL，有后缀的没有TTL，无后缀的先查询。如果查询失败，则：后端查询DB更新缓存查询并带后缀返回给调用方，尽可能避免缓存崩溃。参考https://www.alibabacloud.com/help/zh/doc-detail/67252.htm本文转载自微信公众号「JavaEdge」，可通过以下二维码关注。转载本文请联系JavaEdge公众号。
