极客时间-Redis核心技术与实战笔记(4)

宕机，Redis如何避免数据丢失？

Redis是工作在内存中的键值数据库，服务器宕机后存在数据丢失的问题。
一种解决方法是从后端数据库恢复数据。

上述解决方法存在的问题：每次出现问题都需要访问数据库拷贝大量数据，给数据库带来巨大压力（这里有点疑惑，宕机很少出现，作者却说需要频繁访问数据库。访问数据不都是通过Redis吗？）。宕机后数据从慢速数据库读取，使用这些数据的应用相应变慢。

解决方法：数据持久化。

持久化两大机制：AOF(Append Only File)日志，RDB快照。

AOF日志实现：应用程序从Redis中存取数据后记录执行命令到日志文件。

AOF为何先执行命令后记入日志？不是先记入日志后执行命令？
保证记入日志的命令不出错，避免了记入时额外检查开销。
不会阻塞当前写操作。

AOF潜在风险？

先执行命令后突然宕机，则与这条命令有关的数据操作信息将未被记录到日志中。
下一条数据库指令阻塞风险，日志文件可能写盘慢。

调和上述潜在风险？
AOF配置项appendfsync可选值：

1. Always：每条命令执行完立即写回
2. Everysec：每秒写回，写回之前日志先存在内存缓冲区。
3. No：操作系统控制日志写回。

1不会导致宕机后Redis恢复数据出错，但影响主线程性能。
2宕机后会导致1秒内的操作数据出错，减少影响性能。
3宕机后大量数据操作记录丢失，数据无法回复。

日志文件太大了怎么办？

为什么日志文件不能太大？

1. 文件系统本身对文件大小有限制。
2. 文件太大追加命令效率变低。
3. 日志太大数据库恢复过程缓慢。

解决日志文件太大问题：AOF重写机制。
重写过程为一个拷贝，两处日志
根据数据库数据的最新状态插入命令，子线程完成。

宕机后，Redis如何实现数据快速恢复？

AOF方法故障恢复时需要逐一把操作日志执行一遍，日志多则恢复缓慢。
即保证可靠性，又可以在宕机时实现快速恢复的方法-内存快照。
RDB(Redis database)记录某一时刻的数据。

对哪些数据做快照？

内存中所有数据记录磁盘。

上述操作会阻塞主线程吗？
两个命令生成RDB文件：
save：主线程执行，会导致阻塞。
bgsave：创建子进程，避免阻塞。

快照时可以对数据增删查改吗？

写时复制技术：执行快照的同时，正常处理写操作。

可以每秒做一次快照吗？

1. 间隔太短频繁将全量数据写入磁盘，磁盘带来压力大。
2. fork本身阻塞主线程，频繁fork则频繁阻塞主线程。

以较小的性能开销尽量少丢数据：

混合使用AOF日志和内存快照。