Redis里那个链表到底是个啥玩意儿，怎么理解它的本质呢

要理解Redis里的链表是啥玩意儿,咱们得先把它从“Redis”这个名头里暂时摘出来，你就把它想象成一样我们生活中特别常见的东西：一根绳子穿起来的一串珠子，对，这个简单的画面，基本上就是Redis链表的本质了。

我们一颗珠子一颗珠子地,把这玩意儿掰扯清楚。

第一颗珠子：它不是“挤在一起”的，而是“手拉手”的

最关键的一点是,链表里的数据，不像我们排队买票那样，一个紧挨着一个站，想象一下，如果电影院门口排队的人，每个人都不知道前一个人和后一个人是谁，那队伍早就乱套了，链表里的每个“人”（在计算机里叫“节点”），都有很强的“团队意识”。

每个节点其实是一个小包裹,这个小包裹里装着两样东西：

1. 真正的“货”：就是你要存进去的数据，比如一个数字“123”，或者一句话“hello world”，这就是那颗“珠子”本身。
2. 两根“绳子”：这两根绳子是看不见的，但至关重要，一根绳子叫“前指针”，它牵着前一个节点；另一根绳子叫“后指针”，它牵着后一个节点。

整条链表就是由许许多多这样“手拉着手”的节点组成的，第一个节点（头节点）的前指针牵着“空”（表示它是老大，前面没人了），最后一个节点（尾节点）的后指针也牵着“空”（表示它是老幺，后面没人了），中间的节点则一手拉着前一个，一手拉着后一个。

第二颗珠子：为啥要这么麻烦？直接挤在一起不好吗？

问得好！这就要说到链表的看家本领了，你肯定用过Excel表格吧？如果你在第一行和第二行之间想插入一个新行，会发生什么？Excel会把第三行及以下的所有行都“往下推”一格，对吧？如果这个表有几万行，这个“推”的动作虽然电脑做得快，但也是要花一点点时间和力气的。

但链表就不一样了,因为它不是挤在一起的，是手拉手的，现在我想在第二个珠子和第三个珠子之间加一个新珠子（比如叫“珠子2.5”），怎么做？超级简单：

1. 把原来连接第二颗和第三颗珠子的“绳子”解开。
2. 让第二颗珠子的“后指针”这根绳子，拴住新来的“珠子2.5”。
3. 让“珠子2.5”的“前指针”拴住第二颗珠子，再用它的“后指针”拴住第三颗珠子。
4. 让第三颗珠子的“前指针”拴回“珠子2.5”。

瞧！插入完成了！在这个过程中，除了第二颗和第三颗珠子，其他所有珠子都原地没动！这个操作的速度是非常非常快的，跟你链表里本来有10个数据还是有1亿个数据，关系不大，删除操作也是同样的道理，只是把绳子解开放到一起而已。

链表的第一个核心优势就是：在任意位置插入和删除数据非常快，不需要挪动其他元素。

第三颗珠子：凡事有利必有弊

既然链表这么厉害,是不是所有地方都用它就好了？当然不是，这根“珠子串”也有它的麻烦处。

最大的麻烦就是：找起来慢，你想啊，我这串珠子有100颗，我想找到第95颗珠子看看是啥样，我能直接伸手就拿到第95颗吗？不能，因为我只知道头节点（第一颗珠子）在哪，我必须从第一颗开始，顺着它的“后指针”找到第二颗，再顺着第二颗的找到第三颗……一直数到第95颗，这个过程在计算机里叫“遍历”，如果数据量巨大，这个查找效率就比较低了。

相比之下,那种“挤在一起”的数组（比如Excel的列），虽然插入删除慢，但找起来快，因为我知道所有数据在内存里是连续存放的，我可以直接用数学公式算出第95个数据的位置，嗖”的一下直接跳过去。

链表适合那种需要频繁“增删改”数据，但不需要频繁“按位置查找”数据的场景。

第四颗珠子：Redis是怎么用这根“珠子串”的？

理解了链表的本质,再回头看Redis就清晰了，Redis是一个内存数据库，速度是它的命根子，在很多场景下，它需要高效地管理数据列表。

它用一个链表来实现它的“列表（List）”这种数据类型，当你用 LPUSH（从左边塞进去一个数据）或 RPUSH（从右边塞进去一个数据）命令时，Redis就是在操作这根“珠子串”的头和尾，因为操作两头是链表最快的地方之一，当你用 LPOP 或 RPOP 弹出数据时，也一样快。

再比如,Redis的发布/订阅功能、慢查询日志等功能背后，也用了链表来维护一串等待处理的消息或记录，因为这些场景都是数据来来去去非常频繁，链表“灵活插入删除”的特性正好派上用场。

总结一下

Redis里的链表,本质上就是一根看不见的绳子，把一个个装着数据的小包裹（节点）按顺序穿起来，每个小包裹都记得自己前后邻居是谁，它的绝活是灵活，增删数据效率高；它的短板是查找慢，不能直接定位。

你把它想象成那串“珠子”，或者一列手拉手的小朋友，这个感觉就对了，Redis只不过是把这个简单又经典的数据结构，用在了最适合它的地方，从而让自己跑得更快。