面试题答案
一键面试读写性能变化分析
- 读性能变化
- 底层数据结构角度：Redis哈希对象在数据量较小时，通常采用ziplist（压缩列表）作为底层数据结构。ziplist是一种紧凑的、节省内存的数据结构，它将多个键值对连续存储在一起。当查找一个键值对时，需要从ziplist头部开始遍历，直到找到目标键。在几百个键值对的情况下，遍历时间较短，读性能较好。
- 当数据量增长到几十万甚至更多时，Redis会将哈希对象的底层数据结构从ziplist转换为hashtable（哈希表）。哈希表通过哈希函数计算键的哈希值，直接定位到存储该键值对的位置，理论上平均查找时间复杂度为O(1)，相比于ziplist的线性查找，读性能在大数据量下会有显著提升，特别是在随机读取的场景下。
- Redis机制角度：Redis是单线程模型，采用I/O多路复用技术。在数据量较小时，单线程处理读请求相对轻松，能快速响应。随着数据量增大，虽然哈希表的查找效率高，但单线程处理大量读请求时，可能会因为CPU资源限制，在高并发读场景下出现性能瓶颈。不过如果是批量读取，哈希表的优势会进一步体现，减少多次I/O操作带来的开销，从而提高读性能。
- 写性能变化
- 底层数据结构角度：在ziplist结构下，插入新的键值对可能涉及内存的重新分配和数据的移动，因为ziplist是紧凑存储的。当数据量较小时，这种开销相对较小，写性能尚可。但随着数据量增长，每次插入操作导致的内存重分配和数据移动成本增加，写性能会逐渐下降。
- 转换为hashtable后，虽然哈希表的插入操作平均时间复杂度也是O(1)，但当哈希冲突较多时，会采用链地址法解决冲突，导致链表长度增加，插入操作需要遍历链表找到合适位置，这会增加写操作的时间。而且，当哈希表达到一定负载因子（load factor）时，会进行扩容操作，扩容过程涉及大量的数据重新计算哈希值和重新分配内存，这会严重影响写性能。
- Redis机制角度：由于Redis单线程处理写操作，大量写请求会导致队列堆积，写操作响应时间变长。同时，为了保证数据的持久化，写操作可能会触发AOF（Append - Only - File）或RDB（Redis Database）持久化机制，这也会增加写操作的实际耗时，进一步降低写性能。