Redis-- 哈希冲突

常见问题

哈希冲突：

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

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

1. 给哈希表 2 分配更大的空间，例如是当前哈希表 1 da

单线程：

redis 并非所有的操作都是在同一个线程上 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程,采用单线程的原因是多线程会有共享资源的并发访问控制问题，而且采用单线程对于 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 机制会在命令读写后将执行命令写入磁盘日志，潜在风险：

1. 当刚写入还未将执行命令记录在磁盘日志时出现宕机。

2. AOF 日志也是在主线程上运行，写入磁盘的 IO 操作必然会在紧凑的 redis 读写操作下造成堵塞后面的 redis 操作。

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

1. Always: 同步写回(每个写命令执行完，立马同步地将日志写回磁盘)

2. Everysec: 每秒写回(每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘)

3. No: 操作系统控制的写回(每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘)

AOF 重写机制：

背景：

1. 文件系统本身对文件大小有限，对于日志文件无法一直累加。

2. 日志文件越大，写入的操作时间越久，这在主线程上是非常糟糕的。

3. 发生宕机后，文件重新执行命令，若文件太大，影响 redis 的故障恢复速度。

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