Redis的压缩列表中删除节点和扩容的操作

建议先关注、点赞、收藏后再阅读。

删除操作

在Redis的压缩列表中，当节点被删除后，并不会立即释放该节点所占用的内存空间。
这是因为压缩列表的设计目的是在保持高效的内存使用的同时，尽可能地减少内存的分配和回收频率，从而提高性能。

当节点被删除后，Redis会将该节点标记为’被删除’，而不是立即释放内存。
通过延迟释放内存，Redis可以在后续的操作中重复使用这些被删除节点的内存空间，减少内存分配的开销。
只有当压缩列表的内存空间使用超过一定阈值时，Redis才会进行内存释放的操作。

延迟释放内存可以提供一定的性能优势，但也会导致一些副作用。
例如，被删除节点所占用的内存空间不能被操作系统重新利用，可能导致Redis的内存占用变得更高。
因此，在涉及大量删除操作的场景中，可能需要定期执行Redis的内存回收策略，如通过执行MEMORY PURGE命令来强制释放被删除节点的内存空间。

扩容操作

Redis在处理压缩列表的扩容操作时，会首先判断压缩列表的节点数是否超过了设定的最大节点数（默认为8个节点）。
如果节点数超过了最大节点数，Redis会将压缩列表转换为普通列表（正常的双向链表）。

在进行转换时，Redis会为每个节点分配一个新的列表节点，然后将压缩列表的节点数据迁移至新的列表节点中。
这个过程中，如果压缩列表的元素过多，可能会导致大量的内存分配和数据迁移，从而对Redis的性能造成影响。

另外，需要注意的是，压缩列表的转换过程是单线程进行的，即Redis会暂停所有操作，直到转换完成。
因此，在进行压缩列表扩容操作时，可能会导致Redis的阻塞现象，对系统的响应性能造成影响。

由于压缩列表的扩容操作可能导致数据迁移，可以考虑在业务低峰期进行操作，以减少对系统性能的影响。
此外，对于需要频繁扩容操作的场景，可以考虑使用Redis的普通列表结构，以避免压缩列表的转换过程带来的性能问题。