常见问题

哈希冲突：

redis采用 哈希表的数据结构实现了 key-value 的存储，

• redis解决哈希冲突的方式是 链式哈希，依次用指针链接。当数据量大到一定程度，链表过长，则容易出现慢操作，这时 redis会执行 rehash(渐进式 rehash),操作步骤如下：

单线程：

redis并非所有的操作都是在同一个线程上Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程,采用单线程的原因是多线程会有共享资源的并发访问控制问题，而且采用单线程对于 Redis 的内部实现的复杂度大大降低。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

瓶颈：

来自即刻时间

Redis单线程处理IO请求性能瓶颈主要包括2个方面：

1、任意一个请求在server中一旦发生耗时，都会影响整个server的性能，也就是说后面的请求都要等前面这个耗时请求处理完成，自己才能被处理到。耗时的操作包括以下几种：

a、操作bigkey：写入一个bigkey在分配内存时需要消耗更多的时间，同样，删除bigkey释放内存同样会产生耗时；

b、使用复杂度过高的命令：例如SORT/SUNION/ZUNIONSTORE，或者O(N)命令，但是N很大，例如lrange key 0 -1一次查询全量数据；

c、大量key集中过期：Redis的过期机制也是在主线程中执行的，大量key集中过期会导致处理一个请求时，耗时都在删除过期key，耗时变长；

d、淘汰策略：淘汰策略也是在主线程执行的，当内存超过Redis内存上限后，每次写入都需要淘汰一些key，也会造成耗时变长；

e、AOF刷盘开启always机制：每次写入都需要把这个操作刷到磁盘，写磁盘的速度远比写内存慢，会拖慢Redis的性能；

f、主从全量同步生成RDB：虽然采用fork子进程生成数据快照，但fork这一瞬间也是会阻塞整个线程的，实例越大，阻塞时间越久；

2、并发量非常大时，单线程读写客户端IO数据存在性能瓶颈，虽然采用IO多路复用机制，但是读写客户端数据依旧是同步IO，只能单线程依次读取客户端的数据，无法利用到CPU多核。

针对问题1，一方面需要业务人员去规避，一方面Redis在4.0推出了lazy-free机制，把bigkey释放内存的耗时操作放在了异步线程中执行，降低对主线程的影响。

针对问题2，Redis在6.0推出了多线程，可以在高并发场景下利用CPU多核多线程读写客户端数据，进一步提升server性能，当然，只是针对客户端的读写是并行的，每个命令的真正操作依旧是单线程的。

持久化机制：

AOF：

AOF机制会在命令读写后将执行命令写入磁盘日志，潜在风险：

AOF 三种回写策略(可配置):

AOF 重写机制：

背景：

AOF重写不在主线程，而是在主线程 fork一个线程(bgrewriteaof)来避免阻塞主线程。AOF重写是将同一个 key的多个操作步骤融合成一个操作步骤，然后将此操作步骤存储在新的 日志中。