「这是我参与11月更文挑战的第23天，活动详情查看：2021最后一次更文挑战」。 面对越来越多的高并发场景，限流显示的尤为重要。当然，限流有许多种实现的方式，Redis具有很强大的功能，我用Redis

Redis通过结合纯内存操作、单线程模型、IO多路复用技术和一系列精心设计的高效数据结构，实现了在高并发、低延迟场景下的优秀性能表现。

背景 Redis 热 key 问题是指单位时间内，某个特定 key 的访问量特别高，导致某个 Redis 节点承载了绝大部分流量，而其他 Redis 节点却处于”空闲“状态。极短的流量倾斜问题就可能会

采用Cache-Aside模式，采取更新数据库后删除缓存是正确的吗？更新数据库后更新缓存的方式，真的容易造成数据不一致吗？在系统设计与实际场景下，两种实现方式究竟要如何选择？本文尝试一一解答上述疑问。

Cache-aside下数据变更推荐使用删除缓存的策略，为降低数据不一致通常会配合延迟双删策略。但大厂却很少使用这种方式。背后原因是什么呢？延迟双删策略有致命缺陷么？大厂采用什么策略。

目录 一、背景 用户在一次请求路径中，其实会经过很多缓存节点，如浏览器缓存，CDN节点缓存，网关代理缓存，以及在各业务系统内常用的本地缓存，分布式缓存等。而缓存也作为高并发系统三大保护利器之一(缓存，

本文通过一封618前的R2M(公司内部缓存组件，可以认为等同于Redis)告警，由浅入深的分析了该告警的直接原因与根本原因，并根据原因提出相应的解决方法，希望能够给大家在排查类似问题时提供相应的思路。

在分布式系统盛行的今天，缓存充当着扛压屏障的作用，一旦缓存出现问题，对系统影响也是致命的。本文我们一起聊聊如何安全且可靠的使用缓存，聊聊缓存击穿、缓存雪崩、缓存穿透以及数据一致性、热点数据淘汰机制等。

在服务端开发中，缓存常常被当做系统性能扛压的不二之选。在实施方案上，缓存使用策略虽有一定普适性，却也并非完全绝对，需要结合实际的项目诉求与场景进行综合权衡与考量，进而得出符合自己项目的最佳实践。