每当我们拥有一个拥有大量用户的数据库时,在数据库中遇到热点并不罕见。 对于Redis，频繁访问分区中的同一**被称为热点**。 在本文中,我们将讨论热点键的常见原因,评估该问题的影响,并提出处理热点键的有效解决方案。
原因1: 用户消费数据的规模比制作数据大得多,包括热门项目、热门新闻、热门评论和名人直播。
日常工作和生活中的一件意想不到的事情,比如：在棍子的日子里降价促销某些受欢迎的商品,当其中一件商品被浏览或购买成千上万次时,就会有更大的需求,在这种情况下,就会引发热点问题。
同样,它已经被大量的热点新闻、热点评论、明星直播等发表和观看,这些典型的无读写场景也制造了热点问题。
原因2: 请求片的数量超过了单个服务器的性能阈值。
当在服务器上访问一段数据时,通常会对数据进行拆分或切片。 在此过程中,在服务器上访问相应的**。 当访问流量超过服务器的性能阈值时,就会出现热键问题。
- 流量集中,达到物理网络适配器的上限。
- 太多的请求排队,导致缓存碎片服务崩溃。
- 数据库过载,导致服务雪崩。
如前所述,当服务器上热点**请求的数量超过服务器上网络适配器的上限时,由于流量过度集中,服务器将停止提供其他服务。
如果热点分布过于密集,则会缓存大量热点**,耗尽缓存容量,并使缓存的分片服务崩溃。
缓存服务崩溃后,新生成的请求被缓存在后台数据库中。 由于该数据库的性能不佳,它容易因大量请求而耗尽,导致服务雪崩和性能急剧下降。
提高性能的常见解决方案是通过在服务器或客户端上进行重建。
客户端向服务器发送请求。 假设服务器是多线程服务,基于缓存LRU策略的本地缓存空间是可用的。
当服务器变得拥塞时,它直接将请求返回,而不是将它们转发到数据库。 只有在拥塞被清除之后,服务器才会将客户端的请求发送到数据库,并将数据重新写入缓存。
缓存被访问和重建。
然而,该方案也存在以下问题：
- 缓存失败时多线程服务的缓存构建问题
- 缓存缺失时的缓存构建问题
- 肮脏的阅读问题
在此解决方案中,在客户端部署了单独的缓存来解决热点关键问题。
采用这种解决方案时,客户端首先访问服务层,然后访问同一台主机上的缓存层。
该解决方案具有以下优势：邻近接入、高速和零带宽限制。 然而,它也有以下缺点：
- 浪费的内存资源
- 肮脏的阅读问题
使用本地缓存会导致以下问题：
- 必须提前检测热点。
- 缓存容量有限。
- 不一致持续时间很长。
- 热点键不完整。
如果传统热点解决方案都有缺陷,如何解决热点问题？
此解决方案解决了热点阅读问题。 下面描述了体系结构中不同节点的功能：
- 负载平衡在SLB层实现。
- 读/写分离和自动路由在代理层实现。
- 写请求由主节点处理。
- 读取请求由只读节点处理。
- 高可用性在从节点和主节点上实现。
实际上,客户端向SLB发送请求,后者将这些请求分发给多个代理。 然后,代理识别和分类请求,并进一步分发它们。
例如,代理向主节点发送所有写请求,向只读节点发送所有读请求。
但模块中的只读节点可以进一步扩展,从而有效地解决了热点读取的问题。
读写分离还具有灵活扩展读取热点容量的能力,可以存储大量关键热点,客户端友好等优点。
在该解决方案中,热点被发现并存储以解决热点关键问题。
具体来说,客户端访问SLB，并通过SLB向代理分发请求。 然后,代理通过路由方式将请求转发到后台Redis .
此外,服务器上还添加了一个缓存。
具体来说,将本地缓存添加到代理中。 该缓存使用LRU算法来缓存热点数据。 此外,热点数据计算模块被添加到后台数据库节点以返回热点数据。
代理架构的主要优势是：
- 代理在本地缓存热点数据,其读取能力是可水平扩展的。
- 数据库节点定期计算热点数据集。
- 数据库将热点数据反馈给代理。
- 代理架构对客户端来说是完全透明的,这使得强加兼容性变得不必要。
热点**处理分为两个工作：写和读。 在数据写入期间，SLB接收数据K1，并通过代理将其写入Redis数据库。
如果K1在后台热点模块进行计算后成为热点**,则代理缓存该热点。 这样,客户端可以绕过Redis，直接在下次访问K1 .
最后,因为代理可以水平扩展,热点数据的可访问性也可以无限增强。
在发现过程中,数据库首先统计一个周期内发生的请求。 当请求的数量达到阈值时,数据库定位热点键并将它们存储在LRU列表中。 当客户端试图通过向代理发送请求来访问数据时Redis进入反馈阶段,如果发现目标接入点是热点,则标记数据。
数据库使用以下方法计算热点：
- 基于统计阈值的热点统计。
- 基于统计周期的热点统计。
- 基于版本号的统计数据收集方法,使用时不需要重置初始值。
- 计算数据库上的热点对性能的影响最小,占用的内存也很少。
从前面的分析中,您可以看到这两种解决方案在解决热点关键问题方面都是对传统解决方案的改进。 此外,读/写分离和热点数据解决方案都支持灵活的容量扩展,并且对客户端透明,尽管它们不能确保100%的数据一致性。
读/写分离解决方案支持存储大量热点数据,而基于代理的热点数据解决方案更具成本效益。