Redis到底是怎么跑的？带你慢慢理清它背后的那些运行细节

主要参考自 Redis 官方文档、黄健宏《Redis设计与实现》以及网络技术博客“酷壳-CoolShell”上关于Redis的文章）

想象一下Redis就像一个超级高效、记忆力超强的单线程营业员，它在一个巨大的大厅（服务器内存）里工作，所有的商品数据（键值对）都整整齐齐地摆放在手边的货架上，所以它取东西的速度极快，这个营业员的核心工作模式就是：坐在一个接待台后面，盯着一个叫“事件循环”的呼叫铃系统。

核心发动机：单线程的事件循环

你可能会问,现在都是多核CPU的时代了，为什么Redis还坚持用单线程？这不是浪费资源吗？恰恰相反，这正是Redis高性能的秘诀之一。

这个单线程营业员的工作方式是这样的：

1. 它不需要频繁地在多个窗口（CPU核心）之间跑来跑去，避免了上下文切换带来的巨大开销。
2. 它有一个绝活,就是它的“事件循环”呼叫铃系统，这个系统可以同时监听成千上万个客户的连接请求（网络I/O事件）和客户发来的命令请求，当没有事情发生时，营业员就安静地等待，几乎不消耗CPU。
3. 一旦某个客户的连接有数据传来（比如发来了一个SET name Redis的命令），呼叫铃就响了，营业员立刻被唤醒，然后以极快的速度处理这个命令：找到内存中对应的位置，写入数据，然后再监听这个连接，准备把结果“OK”发回去。

整个过程,所有的命令都是在这个单线程里排着队、一个接一个执行的，这就带来了一个巨大的好处：原子性，因为命令是顺序执行的，所以绝对不会出现两个客户同时修改同一个数据而导致的混乱问题，营业员一次只服务一个命令，做完再做下一个，井然有序。

内存的魔法：速度快的原因

Redis把所有数据都放在内存里,这是它速度快的根本原因，磁盘的读写速度相比内存慢了几个数量级，就像从书桌上拿一张纸和从图书馆书架上找一本书的差别。

只把数据放在内存里有个致命问题：如果服务器断电或者重启，所有数据不就都没了吗？Redis当然考虑到了这一点，它提供了两种主要的“记账本”机制来保证数据持久化：

1. RDB（快照）：想象一下营业员在每天下班前，给整个货架拍一张高清照片（快照），然后把照片存到保险柜（硬盘）里，这种方式生成的RDB文件非常紧凑，恢复起来也很快，但缺点是可能会丢失从上次拍照到现在的所有交易记录（数据变更）。
2. AOF（追加日志）：营业员准备了一个流水账本，每完成一笔交易（执行一个写命令），就立刻用不易褪色的墨水把这条命令记录在账本上，即使突然停电，重启后只要把账本上的命令重新执行一遍，就能恢复到停电前的状态，AOF的耐久性更好，但日志文件会越来越大，重启恢复的时间也更长。

在实际生产中,通常会将两者结合使用，取长补短。

数据的组织：不只是简单的键值对

很多人以为Redis就是个简单的key-value存储，value就是个字符串，其实不然，它的营业厅里有很多种不同形状的货架，用来存放不同类型的“商品”（数据结构）。

• String（字符串）：最普通的货架，放一些简单的商品，比如名字、数字。
• List（列表）：像一个排队通道，可以用来做消息队列，保证先来的消息先被处理。
• Hash（哈希）：像一个带有很多小格子的储物箱，适合存放一个对象的多个属性，比如一个用户的ID、姓名、年龄等信息。
• Set（集合）：是一个不允许重复的无序货架，可以用来存储好友列表，方便进行共同好友这样的集合运算。
• Sorted Set（有序集合）：是一个带排名的货架，每个商品都有一个分数，可以根据分数排序，排行榜功能就是用它实现的。

正是因为有了这些丰富的数据结构,Redis才能如此灵活地应对各种复杂的业务场景，而不仅仅是一个缓存工具。

应对高并发：当一个大营业员忙不过来

虽然营业员自己效率很高,但如果客流量（并发请求）实在太大，一个营业厅（单台服务器）处理不过来了怎么办？Redis提供了“分店”模式，也就是集群。

可以把数据分成若干份,每一份数据放到一个不同的Redis营业厅（节点）里去，根据key的名字计算一个哈希值，然后决定这个key应该由哪个节点来管理，这样，多个营业厅就可以同时工作，共同分担海量的数据和请求，实现了水平扩展。

总结一下

Redis就像一个技艺精湛的单线程魔术师,它通过单线程事件循环避免了多线程的复杂性和开销，通过全内存存储实现了闪电般的速度，通过RDB和AOF两种机制在速度和数据安全之间取得平衡，通过丰富的数据结构提供了强大的数据处理能力，最后还能通过集群模式横向扩展以应对海量数据和高并发场景，理解了这些核心的运行细节，你就能更好地驾驭这个高性能的工具。