程序员接外包网站,厦门市市场开发建设服务中心网站,网站需求表,徐州建设银行网站1. 缓存雪崩的常见原因
缓存“雪崩”是指#xff0c;因为部分缓存节点不可用#xff0c;而导致整个缓存系统#xff08;甚至是整个服务系统#xff09;不可用。缓存“雪崩”主要分为以下两种情况#xff1a;
因缓存不支持 rehash 而导致的缓存“雪崩”缓存支持 rehash 时…1. 缓存雪崩的常见原因
缓存“雪崩”是指因为部分缓存节点不可用而导致整个缓存系统甚至是整个服务系统不可用。缓存“雪崩”主要分为以下两种情况
因缓存不支持 rehash 而导致的缓存“雪崩”缓存支持 rehash 时的缓存“雪崩”
1.1. 因缓存不支持 rehash 而导致的缓存“雪崩”
通常是由于缓存体系中有较多的缓存节点不可用且不支持 rehash所以请求会“穿透”到 DB从而导致 DB 不可用最终导致整个缓存系统不可用。 如图 7-24 所示缓存节点不支持 rehash当大量缓存节点不可用时会出现请求读取缓存失败的情况。根据读写缓存策略这些读取缓存失败的请求会去访问 DB。但是DB 是很难承载这么多请求的很容易出现大量的慢查询最终整个系统不可用。
1.2. 缓存支持 rehash 时的缓存“雪崩”
缓存支持 rehash 时产生的“雪崩”一般跟瞬时流量洪峰有关。瞬时流量洪峰到达引发部分缓存节点过载然后流量洪峰会扩散到其他缓存节点最终整个缓存系统异常。 如 图7-25 所示在缓存分布设计时一般会选择一致性 Hash 分片这样在节点出现异常时将采用 rehash 策略即将对异常节点的请求平均分散到其他缓存节点上。
在一般情况下“一致性Hash分布 rehash 策略” 可以很好地应对瞬间流量洪峰。但在较大的瞬时流量洪峰到达时如果流量比较集中正好落在一两个缓存节点上则这个节点很容易因为内存、网卡过载而出现异常然后这些节点下线之后大流量 key 请求被 rehash 到其他的缓存节点上进而导致其他的缓存节点也过载异常持续扩散最终整个缓存系统无法对外提供服务。
2. 缓存雪崩的解决方案
合理有效地预防能减小发生缓存“雪崩”的概率。可以从以下 3 个关键点来预防。
2.1. 对 DB 访问增加读开关
当发现 DB 请求变慢、出现阻塞或者慢查询超过阈值时会关闭读开关部分或所有读 DB 的请求进行 failfast 立即返回待 DB 恢复后再打开读开关。如 图7-26 所示。 当 DB 负荷严重过载时会出现 DB 请求严重变慢、阻塞甚至是进程崩溃最终导致整个系统丢数据、不可用。此时可以通过控制 DB 降低 DB压力优先保证“写”然后保证一部分“读”从而再不丢数据的情况下尽可能服务更多的用户。部分用户请求的失败比“整个系统不可用、所有用户请求失败”要好。
2.2. 给缓存系统增加多个副本
当数据出现缓存异常或请求失败后客户端可以去读取缓存副本。多个缓存副本应尽量部署在不同的机架如 图7-27 所示这样可以确保在任何情况下缓存系统都可以正常对外提供服务。 采用多个副本将流量分散到不同的副本中或者没有足够资源就拒绝部分访问可以确保系统对大部分用户可用或核心功能可用。
2.3. 对缓存系统进行实时监控
开发人员需要对缓存体系进行实时监控。当访问越来越慢超过阈值时需要及时警报并通过替换机器或服务进行及时处理。
也可以通过容错降级机制通过自动关闭异常接口、停止边缘服务、停止部分非核心功能等措施确保在极端场景下核心功能可以正常运行。
这三种方案可根据自己业务特点进行选用。在一些大流量的项目如大型社交系统中这三种方案都会被用到。
