【redis】redis常见数据结构及其底层，redis单线程读写效率高于多线程的理解，-EW帮帮网

struct sdshdr {
    int len;     // 已用长度（字符串实际长度）
    int free;    // 剩余可用空间
    char buf[];  // 数组，存储实际字符数据
};

是一个有序可重复链表结构，会根据数据量和长度，自动选择不同数据结构，提升性能
底层实现主要三种：
- ziplist压缩列表：redis3.2之前，元素数量<512，元素大小<64用压缩列表
- linkedlist双链表：redis3.2之前，大数据量使用。
- quicklist快速列表：redis3.2之后的默认存储，所有情况都用quicklist，他是由多个ziplist组成的双向链表

无序，元素唯一的集合类型，会根据数据量和内容，自动选择不同数据结构，提升性能
底层两种实现：
- intset整数集合：适用于，都是整数，数量<=512。内存连续，升序排列，插入删除慢
- hashtable哈希表：适用于，多数据类型，数量多。标准hash，内存开销较大（存储指针、哈希表结构）操作效率高

redis会根据数据自动切换，添加非整数/数量超512自动转hashtable，但是不会重新转回来

为什么用跳表而不是红黑树？
实现简单，插入删除性能好（时间复杂度平均 O(log n)），更容易实现范围操作

第3层：1 --------------------------> 9
第2层：1 ------> 5 ------> 7 ------> 9
第1层：1 -> 3 -> 5 -> 6 -> 7 -> 8 -> 9

一个键值对集合，常用于存对象（用户配置）等，会根据字段数量和内容自动选择不同的实现方式
底层两种实现：
- ziplist压缩列表：小对象用压缩列表，(字段数<512，长度<64)连续内存，占用少，节省空间，查询速度稍慢，字段超过阈值时，会自动转换为hashtable
- hashtable哈希表：大对象用hash表，读写效率更高

为什么小数据用 ziplist？
内存利用率高（无指针开销）

Redis 的哈希表如何扩容？
采用 渐进式扩容：扩容时同时保留新旧两个哈希表，分批次迁移数据

数据类型	底层结构	说明
String	int / embstr / raw（SDS）	根据长度和内容选择优化方式：int 表示整数，embstr 表示小字符串，raw 是通用 SDS
List	ziplist（旧） / quicklist	Redis 3.2+ 默认用 quicklist（多个 ziplist + 双向链表）
Set	intset / hashtable	小量整数用 intset，其他情况用 hashtable
ZSet	skiplist + hashtable	哈希表查找，跳表排序；两个结构同时维护
Hash	ziplist / hashtable	字段少且短用 ziplist，否则用 hashtable

在mysql中我们对于耗时较长的磁盘io操作往往采用多线程并发执行，因为多线程产生的线程切换开销往往小于磁盘读写开销，所以并发等待可以提高效率；
而redis是内存存储，本身单线程速度就很快，如果用多线程，
涉及cpu上下文切换，锁竞争，这些耗时可能会超过从内存中取数据的时间，从而降低性能。

redis的性能瓶颈往往是网络或者内存，而非cpu，内存访问的速度高于切换线程的开销
Redis 6.0 起引入了I/O 多线程模型，用于并行处理高并发下，客户端的网络读写数据（网络 I/O），但命令执行仍是单线程，以保证数据一致性

网络用多线程并发提速，核心逻辑用单线程保证安全。

例如 Hash 的 ziplist + hashtable 组合，在数据量小时用 ziplist（节省内存），大时转 HashTable（O(1) 查询）。

【redis】redis常见数据结构及其底层，redis单线程读写效率高于多线程的理解，