塑造未来车队管理的5个实施步骤

所谓的“瞬间”删除其实有些夸张，只是从返回的结果来看是删除成功了，但是这只是把删除工作交给了后台的小弟（子线程）异步来删除数据了。

小贴士：正常情况下使用 del 指令可以很快的删除数据，而当被删除的 key 是一个非常大的对象时，例如时包含了成千上万个元素的 hash 集合时，那么 del 指令就会造成 Redis 主线程卡顿，因此使用惰性删除可以有效的避免 Redis 卡顿的问题。

Redis 6 中的多线程

之前在 Redis 4.0 中你说删除比较慢，骗我开大（多线程）来处理也就罢了，为毛 Redis 6.0 还要多线程嘞？

其实是这样的在 Redis 4.0 版本中虽然引入了多线程，但此版本中的多线程只能用于大数据量的异步删除，然而对于非删除操作的意义并不是很大。

但如果我们使用我们在非删除的环境下使用多线程的话就可以分摊 Redis 同步读写 I/O 的压力，以及充分的利用多核 CPU 的资源了，这样就可以有效的提升 Redis 的 QPS（Query Per Second，每秒查询率）了。

在 Redis 中虽然使用了 I/O 多路复用，并且是基于非阻塞 I/O 进行操作的，但 I/O 的读和写本身是堵塞的，比如当 socket 中有数据时，Redis 会通过调用先将数据从内核态空间拷贝到用户态空间，再交给 Redis 调用，而这个拷贝的过程就是阻塞的，当数据量越大时拷贝所需要的时间就越多，而这些操作都是基于单线程完成的。
 

我们兄弟仨可谓单线程的杰出代表，不仅演示了我们的优雅更加展现了我们的高效。

有人可能会问：为什么单线程的我，竟然如此嚣张？

家中有矿呗，Redis 单线程但性能依旧很快的主要原因有以下几点：

  1.  基于内存操作：Redis 的所有数据都存在内存中，因此所有的运算都是内存级别的，所以他的性能比较高；

  2.  数据结构简单：Redis 的数据结构比较简单，是为 Redis 专门设计的，而这些简单的数据结构的查找和操作的时间复杂度都是 O(1)，因此性能比较高；

  3.  多路复用和非阻塞 I/O：Redis 使用 I/O 多路复用功能来监听多个 socket 连接客户端，这样就可以使用一个线程连接来处理多个请求，减少线程切换带来的开销，同时也避免了 I/O 阻塞操作，从而大大提高了 Redis 的性能；

  4.  避免上下文切换：因为是单线程模型，因此就避免了不必要的上下文切换和多线程竞争，这就省去了多线程切换带来的时间和性能上的消耗，而且单线程不会导致死锁问题的发生。

来看一下我的父亲大大是如何评价我的，Redis 的 FAQ（Frequently Asked Questions，常见问题）回答了单线程的这个问题，具体内容如下：
 

我是 Redis，今年 11 岁了~

曾几何时我是辣么的单纯，辣么的可爱，而如今我竟背叛了当初“誓言”，决心在多线程这条路上义无反顾的一路狂奔，没错我就是你们口中那个既可爱又迷人的 Redis，你可以叫我小 R...R 😊。

一波骚操作结束，我们开始今天的正文。

我们知道在 Redis 4.0 之后就陆陆续续添加了一些多线程的功能，难道单线程不香了吗？

单线程慢吗？

Redis 的单线程曾几何时还是我们炫耀的资本，优雅又不失高效的设计，让无数的追求者为之着迷。

你要问我排第几？Nginx 是我大哥，NodeJS 是我小弟，我在家中排名老二。

（编辑：鞍山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!