Redis读写模型到底是咋回事，简单聊聊它的工作原理和那些细节

要理解Redis为啥这么快，核心就在于它处理读写请求的方式，你可以把Redis想象成一个超级高效的单人小吃摊,而不是一个大饭店。

核心模型：单线程处理命令

Redis在处理客户端发来的所有数据读写命令时，是单线程的，这是最关键的一点，很多人一听单线程就觉得慢,但Redis的设计恰恰利用了单线程的优势。

这个“主线程”就像一个手脚麻利的摊主，它有一个任务队列（也就是待办事项列表），所有客人（客户端）的点单（命令），来一份SET name zhangsan”（存数据）、“来一份GET name”（取数据），都按先后顺序排在这个队列里，摊主一次只专心处理一个点单,做完一个再做下一个。

为什么单线程反而快？

你可能会问，现在CPU都是多核的，用多线程不是能同时处理更多请求吗？为什么Redis反其道而行之？这主要有几个原因：

1. 避免了恐怖的锁： 多线程编程最头疼的就是“锁”，如果多个线程同时去修改内存里的同一份数据，比如同时给一个计数器加1，结果很可能就乱套了，为了避免混乱，就必须加锁，让线程们排队修改，加锁、释放锁本身有开销，而且线程之间争抢锁还会导致等待，反而降低了效率，Redis干脆就用一个线程，所有操作都是顺序执行，从根本上杜绝了锁的问题，实现了天然的原子性操作。（来源：Redis官方文档对单线程模型的解释）
2. 内存操作极快： Redis的所有数据都放在内存里，内存的读写速度是纳秒级别的，比磁盘快10万倍以上，对于内存来说，单线程CPU的处理速度已经足够快了,多线程带来的上下文切换开销可能比它节省的时间还多。
3. 非阻塞的I/O模型： 虽然处理命令是单线程的，但Redis并不是傻等着命令来，它使用了I/O多路复用技术，你可以把这个技术理解为摊主雇了一个超级高效的“叫号员”，这个叫号员可以同时监听成千上万个客人的到来（网络连接），当某个客人要点单（有数据可读）或者摊主做好了菜要端给客人（有数据可写）时，叫号员才会通知摊主，摊主（主线程）只需要在有“事”可做的时候才去处理，而不是把时间浪费在空等上，这使得一个线程就能高效处理大量网络连接。（来源：对Unix网络编程中select/poll/epoll等系统调用的抽象理解）

Redis的高性能秘诀是：基于内存的快速访问 + 单线程无锁设计 + I/O多路复用，这三者结合，保证了即使在海量并发连接下,每个命令都能得到极快的响应。

那读写过程中的一些细节呢？

1. 持久化时的写操作： Redis为了数据不丢，需要把内存数据写到硬盘上（持久化），这个过程（比如RDB快照或AOF日志追加）是由后台子进程或另一个后台线程来完成的，不会阻塞主线程处理客户端命令，这就好比摊主一边卖小吃，一边让后厨的帮手按照他记下的菜单去准备第二天的食材,两不耽误。
2. “慢”的原因： 既然单线程这么快，那什么时候会“慢”呢？就是当某个命令执行时间太长，比如一次性删除一个包含百万个元素的超大集合（key），或者执行一个复杂的Lua脚本，这个慢命令会阻塞任务队列，后面的所有命令都得等着，就像摊主突然遇到一个要求特别复杂的客人，花了10分钟点单，后面的队伍就全卡住了,要避免在Redis上执行耗时操作。
3. Redis 6.0的多线程I/O： 在Redis 6.0版本中，引入了一个新特性：多线程网络I/O，注意，这里多线程处理的不是命令的执行，而是网络数据的读取和发送，也就是说，原来“叫号员”的活儿现在由一个小组来分担了，他们负责把客人的点单请求从网络上读出来，解析好，然后依然按顺序交给单线程的“摊主”去烹饪；等摊主做好了，再由这个小组把菜（响应结果）端给客人，这进一步提升了在极高网络负载下的性能，但核心的命令处理逻辑仍然是单线程的，精髓没变。（来源：Redis 6.0 release notes及相关技术博客）

Redis的读写模型就像一个高效的单人摊位，一个主线程（摊主）依托于内存的极致速度，用“单线程无锁”的方式专心处理所有命令，避免了多线程的麻烦，它通过I/O多路复用（高效的叫号员）来应对海量客户，并通过后台进程处理耗时的持久化任务，新版本中，只是把端茶送水的工作交给了团队，但核心的“烹饪”工作依然由最能保证秩序和质量的单人来完成，这套简单而专注的设计,是Redis高性能的基石。