线程模型

非阻塞IO

• Redis、Node.js、Nginx 均是单线程服务，但他们都是服务器高性能的典范。
• Redis 4.0 版本抛弃了单线程设计，转为多线程设计，但其主处理程序依然是单线程模型。
• Redis 使用单线程进行设计的原因：
  • 更好的可维护性，方便开发和调试：多线程模型存在竞争条件 (race condition)问题，多个进行的执行顺序会对共享内存的内容造成影响，需要额外设计锁逻辑。
  • 处理并发请求：将数据库的开、关、读、写都转换成了事件，使用 I/O 多路复用 机制轮询描述符处理并发连接，同时等待多个连接发送的请求。
  • Redis 服务中运行的绝大多数操作的性能瓶颈都不是 CPU：一个 Redis 服务在 1s 内可处理 100w 个用户请求，如无法满足，应使用分片将不同的请求交给不同的 Redis 服务器来处理，而不是在同一个 Redis 服务中引入大量的多线程操作。
• 每一个网络连接都会产生一个文件描述符，并由执行事件循环（死循环）的多路复用模块接收，然后关联指令队列，交给文件事件分配器按顺序处理。一旦期间有任何事件到来，就可以立即返回。时间过了之后还是没有任何事件到来，也会立即返回。
  
  (Source: Redis 和 I/O 多路复用)

• 关于异步和阻塞的概念，这篇文章有一个形象的举例：

  出场人物：老张，水壶两把（普通水壶，简称水壶；会响的水壶，简称响水壶）。
  
  同步阻塞：老张把水壶放到火上，立等水开。
  
  同步非阻塞：老张把水壶放到火上，去客厅看电视，时不时去厨房看看水开没有。
  
  异步阻塞：老张把响水壶放到火上，立等水开。
  
  异步非阻塞：老张把响水壶放到火上，去客厅看电视，水壶响之前不再去看它了，响了再去拿壶。
  

持久化

RDB 快照

• RDB 快照是一次全量备份，是内存数据的二进制序列化形式，在存储上非常紧凑。
• 持久化需要进行文件 IO，但该操作不能使用多路复用 API，在拖慢性能的同时，还存在数据一致性的问题（脏读、幻读等），为避免上述问题，Redis 使用多进程 COW（Copy On Write）策略进行持久化。
• 创建快照（持久化）时：
  • fork（多进程）函数使进程分离，产生父、子进程，双方共享内存数据，内存里的数据在进程产生的一瞬间就凝固。
  • 父进程持续处理数据，复制需要修改的数据端后进行操作，不改变原有数据端。
  • 子进程持续读取数据端内数据进行快照操作，读写数据到一个临时文件 RDB 中。
  • 子进程完成读写后替换原 RDB 文件。

AOF 日志（Append-Only File）

• AOF 日志是顺序指令序列，只记录对内存进行修改的指令记录。
• Redis 通常先执行命令，再记录 AOF 日志。

AOF 重写

• 长期运行会使 AOF 日志文件过大，重放日志耗时过长，AOF 重写操作可为文件瘦身。
• 运行机制：
  • fork（多进程）函数使进程分离，产生父、子进程
  • 子进程将日志写入到一个临时文件 AOF 中
  • 父进程将数据变更写入到临时内存缓冲区，同时持续写入日志到原 AOF 文件中（这样即使断电，也能保证有一个 AOF 文件是可用的）
  • 子进程完成读写后，父进程接收信号，将内存缓冲区日志追加到临时文件 AOF 中
  • 父进程完成写入后替换 AOF 文件，从而实现 AOF 重写。
• AOF 日志使用 Linux 提供的 fsync 函数进行文件写入操作，但由于文件 IO 速度慢，需要设置适当的写入周期。
• AOF 日志的 fsync 周期默认为 1s。（服务宕机最多丢失 1s 数据）。可关闭 fsync 牺牲安全性换取 Redis 性能。

Redis 4.0 混合持久化

• RDB 来恢复内存会丢失大量数据，通常使用 AOF 日志重放，为解决重放太耗时的问题，Redis 4.0 使用混合持久化。
• 将 RDB 文件和增量 AOF 日志文件存在一起，AOF 日志文件记录持久化过程中的增量变更。重放时，双管齐下甭提有多爽快了！

延伸阅读：