【专栏】基础篇04| Redis 该怎么保证数据不丢失（上）

前言

    前一小节我们讲了Redis中的数据组织形式与数据存储格式，大家都知道Redis是一个内存数据库，这也是是它快的重要原因，那么数据都在内存中的话，岂不是一宕机数据都没了？这和高可用背道而驰，因此Redis有自己的一套日志机制来保证数据的可靠性，其实除了Redis，主流的数据库都有日志，像老大哥Mysql5.5之后的默认引擎innodb使用redo log来保证宕机后的数据恢复，也叫Crash Safe能力，又或者像前段时间蚂蚁开源的OceanDB这种HTAP数据库，为了保证Crash Safe以及副本的数据复制，也要使用redo log，可见数据库发展了这么多年，从单机一体化到分布式，从OLTP到OLAP无论数据库怎么变化，日志系统都是重要一环，所以我们可以从Redis出发，触类旁通，当遇到新的数据库时特意留意它的日志系统设计，可能都是大相径庭。

AOF日志

    AOF（Append Only File），从名字可以看出是一种追加写的文件，利用了磁盘顺序写比随机写高效的特性。AOF是Redis保证数据不丢失的日志组件之一，如果你下载了Redis会发现它的conf配置文件中AOF模式是关闭的：

    日志系统还有一个特点，就是缓冲区，这个缓冲区不是操作系统层面的文件系统缓冲区，这个属于数据库层，由于日志最终要落盘，那么落盘的时机对于数据库使用者来说应该是一个可控点，Redis将AOF的落盘时机也以配置的方式提供给了用户：

提供了三种方式：

• 每次日志都落盘

• 每秒钟触发落盘

• 不主动触发，由操作系统决定落盘时机

    每次都落盘表示每次redis的写入操作都要同步写磁盘，可靠性最高，性能最差；每秒钟落盘表示写入操作可以写入到缓冲区，每秒钟由redis异步落盘；由系统决定则是随机性更强，影响系统的因素很多比如是否繁忙等。

    我们将配置中的AOF模式打开（即设置成yes），然后我们尝试写入一条数据：

set name lixinjihua

我们直接看右边可以看到我们的操作'set'以及键和值的字符出现，除此之外还有*和$符号，这边稍微解释下，*后面的数字表示这个命令有几个部分，$后的数字表示每个部分有几个字节，这样再回头看是不是就清楚了，比如name有四个字节，所以就是$4。

AOF重写

    上面我们可以看到AOF中记录的是具体命令，这表示对数据的修改命令都会被记录下下来，在宕机恢复时重放AOF中的命令来保证Crash-Safe，我们拿下面的命令举例： 

127.0.0.1:6379> lpush list one127.0.0.1:6379> lpush list two127.0.0.1:6379> lpush list three127.0.0.1:6379> lpush list four127.0.0.1:6379> lpop list127.0.0.1:6379> lpop list127.0.0.1:6379> lpush list five

 执行完后AOF日志内容如下：

而其实执行完这些后list中的元素只有one、two、five三个，可是我们用了七条命令去记录，长此以往AOF的日志就会变得很大，所以Redis提供了AOF重写机制，我们手动触发bgrewriteaof，然后看一下执行完后的AOF内容：

变成了只有三个元素的操作，格式也有了些变化，总体来说体积变小了很多，这就是AOF重写的作用，面向结果型的数据压缩，不记录中间过程。

AOF重写工作模式

继续阅读，原文链接：【专栏】基础篇04| Redis 该怎么保证数据不丢失（上）

专栏系列：https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzkzOTM4MzYwNQ==&action=getalbum&album_id=2642660048770744323#wechat_redirecthttps://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzkzOTM4MzYwNQ==&action=getalbum&album_id=2642660048770744323#wechat_redirect