分片集群：

分片集群作用：

• 单机内存存在上限，通过横向扩展来突破存储的上限

主从集群作用：

• 提升可用性，避免单点故障

分片集群方案：

• 官方的redis cluster
• 更早更稳定的codis

redis cluster：

特性：

1. 采用无中心化的模式（无proxy，客户端与服务端直连）
2. cluster 使用哈希槽（Hash Slot）处理数据和实例之间的映射关系
3. 默认有16384个槽，需要把所有的槽分配给实例，否则 Redis 集群无法正常工作。（一个实例会对应多个槽位）
4. 每个redis实例都有所有哈希槽的映射关系
5. 如果集群中Redis实例的内存大小不一样，可以使用cluster addslots进行手动分配哈希槽
6. hash slot简化了节点扩缩容的难度，便于集群的维护和管理，但是增加了客户端映射表的维护成本，客户端需要支持重定向机制带来的新的协议。

哨兵（观察者）

哨兵特征：

• 哨兵是一个运行在特殊模式下的 Redis 进程
• 每个哨兵都需要和所有的主、从库建立连接
• 哨兵相当于"观察者节点"，观察的对象是主、从节点
• 哨兵之间互相发现：
  • 主库的发布/订阅 机制：通过主库的__sentinel__:hello
  • 哨兵在主库发布自己的信息、订阅其他哨兵信息
• 哨兵如何发现从库：
  • 哨兵会每10秒一次的频率向主库发送INFO命令，获取从库列表
• 哨兵如何通知客户端：
  • 每个哨兵对外提供发布/订阅机制
  • 客户端从哨兵订阅消息，关注主、从故障转移中的关键事件

为什么使用主、从架构：

1. 单机下如果宕机，通过AOF、RDB恢复需要时间。服务会出现中断，为了高可用性
2. 单机性能存在瓶颈上限，主、从可以提升读操作的瓶颈上限，为了高性能

主、从模式特点：

• 主、从之间的数据同步操作是异步进行的，属于弱一致性（最终一致）
• 通过冗余解决可用性问题：
  • 数据冗余（每个节点都存数据）
  • 服务冗余（每个节点都可以提供读服务，不支持写）
• 冗余带来的新问题：
  • 主、从数据的一致性问题：
    • Redis提供了主从复制模式，避免数据不一致
  • 多服务的通信问题：
    • 主、从心跳监测
    • 哨兵机制
• 读、写分离：
  • 读操作：主、从都可以接收命令
  • 写操作：仅主库接收命令，执行后同步给从库

RDB（Redis DataBase）：

• 含义：RDB 快照就是记录Redis某一个瞬间的全部内存数据，记录的是实际数据。这个文件就是RDB快照文件。

跟AOF对比：

• 文件内容：
  • RDB 文件的内容是二进制数据（状态数据）
  • AOF文件内容是命令数据（操作数据）
• 数据恢复效率：
  • RDB 文件直接读入内存完成恢复，效率更高
  • AOF 需要执行操作命令，通过逐个重放命令实现恢复，效率低
• 执行的进程：
  • RDB 是在bgsave子进程，因为RDB需要对全量数据做写入，不能在主进程做
  • AOF 是在主进程，因为AOF每次只有少量命令，并且是追加写（顺序写），在主进程影响不大

写日志的方式：

• WAL：写前日志（Write Ahead Log, WAL）在实际写数据前，先把修改的数据记到日志文件中，以便故障时进行恢复（mysql 先把数据写到redo log，再落盘）。

• AOF：写后日志， Redis 是先执行命令，把数据写入内存，然后才记录日志。（所以AOF不是crash-safe的）

AOF：

• AOF 里记录的是 Redis 收到的每一条写操作。以文本形式保存的。
• 优点：
  • AOF是顺序写，不需要检查和索引操作，避免了额外检查的开销
  • 不会阻塞当前的写入操作
• 缺点：
  • 未写入AOF的那部分数据可能会丢失
  • 因为些操作和写AOF都是在主进程中，所以写AOF时，可能会阻塞后一个写操作
• 刷盘时机：

  • 配置appendfsync：

    • Always：每次执行命令后，通过系统调用fsync刷盘
    • Everysec：创建异步，每隔1秒，调用一次fsync刷盘
    • No：由操作系统控制，不主动调用fsync

  • 

• AOF 缓冲区：
  • 将命令刷盘前，先放入 AOF 缓冲区，然后通过fsync刷盘。服务于AOF 文件刷盘，提高刷盘效率。

过期删除策略：

• 场景：针对业务使用，key如果设置了有效期，过期后会进行删除

• 过期时间的存储结构：

  typedef struct redisDb {
      dict *dict;    /* 数据库键空间，存放着所有的键值对 */
      dict *expires; /* 键的过期时间 */
      ....
  } redisDb;

• 删除过程：

  1. 查询key时，先从expires过期哈希表中查找
  2. 如果过期哈希表中存在该key，则比较存储的时间和系统时间确定是否过期。
  3. 如果不存在、或者key未过期，则返回key对应value
  4. 如果key存在，且已过期，则返回null

• 图解：

• 一般的过期删除策略：

  • 定时删除：
    • 定义：给key创建定时删除事件，时间达到则删除
    • 优点：删除更实时，内存释放更快
    • 缺点：内存不紧张时，也会耗费CPU资源
  • 惰性删除：
    • 定义：不主动删除过期键，仅当key被访问时，判断是否过期，从而决定是否（同步/异步）删除。
    • 优点：占用CPU相对更少
    • 缺点：读少、写多时，内存可能得不到释放
  • 定期删除：
    • 定义：每隔一段时间随机从expires哈希表取出一定数量的 key进行检查，删除其中的过期key
    • 优点：折中方案，通过检查频率，限制CPU的使用，并且能相对及时清理内存
    • 缺点：删除操作的时长和频率无法把控，频率太低或者太高都不好

• Redis过期删除策略：

  • 惰性删除 + 定期删除组合使用
  • 同步 or 异步删除，Redis>=4.0 通过lazyfree-lazy-expire配置
  • 频率：默认每秒进行10次过期检查
  • 随机数量：20个
  • 额外逻辑：
    • 一次检查中，如果超过25%的key过期，则再次获取20个key
    • 一次检查的最大时间限制：默认25ms。防止因为有大量key过期，一直陷在检查中，导致程序卡死。
  • 疑问？：频率*最大时间限制超过了1s

误解：redis只有一个线程

• Redis 的网络IO和键值对读写是由一个线程（主线程）来完成的（Redis6.0 网络IO改为多线程模型）
• Redis的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

为什么用单线程：

1. 多线程开销问题
2. 多线程并发竞争问题，需要引入同步原语或者锁机制（主要是一些写操作） （此处没有很好解释原因，而是用多线程缺点来阐述，不够严谨）

使用全局哈希表存储所有键值对

• 哈希表的优点：
  • 用 O(1) 的时间复杂度来快速查找到键值对
  • 只需要计算键的哈希值，就可以知道它所对应的哈希桶位置，然后就可以访问相应的 entry 元素

Redis 对象类型和编码：

Redis键和值都是由redisObject定义

typedef struct redisObiect{
	//类型
	unsigned type:4;
	//编码
	unsigned encoding:4;
	//指向底层数据结构的指针
	void *ptr;
}