为什么分布式一定要有Redis? _分布式

考虑到绝大部分写业务的程序员，在实际开发中使用 redis 的时候，只会 Set Value 和 Get Value 两个操作，对 Redis 整体缺乏一个认知。所以我斗胆以 Redis 为题材，对Redis 常见问题做一个总结，希望能够弥补大家的知识盲点。
本文围绕以下几点进行阐述：

为什么使用 Redis
使用 Redis 有什么缺点
单线程的 Redis 为什么这么快
Redis 的数据类型，以及每种数据类型的使用场景
Redis 的过期策略以及内存淘汰机制
Redis 和数据库双写一致性问题
如何应对缓存穿透和缓存雪崩问题
如何解决 Redis 的并发竞争 Key 问题

为什么使用 Redis

我觉得在项目中使用 Redis ，主要是从两个角度去考虑：性能和并发。
当然， Redis 还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件，如 ZooKpeer 等代替，并不是非要使用 Redis 。因此，这个问题主要从性能和并发两个角度去答。
性能

如下图所示，我们在碰到需要执行耗时特别久，且结果不频繁变动的 SQL ，就特别适合将运行结果放入缓存。这样，后面的请求就去缓存中读取，使得请求能够迅速响应。

文章插图

题外话：忽然想聊一下这个迅速响应的标准。根据交互效果的不同，这个响应时间没有固定标准。
不过曾经有人这么告诉我："在理想状态下，我们的页面跳转需要在瞬间解决，对于页内操作则需要在刹那间解决。
另外，超过一弹指的耗时操作要有进度提示，并且可以随时中止或取消，这样才能给用户最好的体验。"
那么瞬间、刹那、一弹指具体是多少时间呢？
根据《摩诃僧祗律》记载：
一刹那者为一念，二十念为一瞬，二十瞬为一弹指，二十弹指为一罗预，二十罗预为一须臾，一日一夜有三十须臾。

那么，经过周密的计算，一瞬间为 0.36 秒、一刹那有 0.018 秒、一弹指长达 7.2 秒。
并发

如下图所示，在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。
这个时候，就需要使用 Redis 做一个缓冲操作，让请求先访问到 Redis ，而不是直接访问数据库。

文章插图

使用 Redis 有什么缺点

大家用 Redis 这么久，这个问题是必须要了解的，基本上使用 Redis 都会碰到一些问题，常见的也就几个。
回答主要是四个问题：

缓存和数据库双写一致性问题
缓存雪崩问题
缓存击穿问题
缓存的并发竞争问题

这四个问题，我个人觉得在项目中是常遇见的，具体解决方案，后文给出。
单线程的 Redis 为什么这么快

这个问题是对 Redis 内部机制的一个考察。根据我的面试经验，很多人都不知道 Redis 是单线程工作模型。所以，这个问题还是应该要复习一下的。
回答主要是以下三点：

纯内存操作
单线程操作，避免了频繁的上下文切换
采用了非阻塞 I/O 多路复用机制

题外话：我们现在要仔细的说一说 I/O 多路复用机制，因为这个说法实在是太通俗了，通俗到一般人都不懂是什么意思。
打一个比方：小曲在 S 城开了一家快递店，负责同城快送服务。小曲因为资金限制，雇佣了一批快递员，然后小曲发现资金不够了，只够买一辆车送快递。
经营方式一

客户每送来一份快递，小曲就让一个快递员盯着，然后快递员开车去送快递。
慢慢的小曲就发现了这种经营方式存在下述问题：