【专栏】基础篇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模式是关闭的:

【专栏】基础篇04| Redis 该怎么保证数据不丢失(上)_第1张图片

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

【专栏】基础篇04| Redis 该怎么保证数据不丢失(上)_第2张图片

提供了三种方式:

  • 每次日志都落盘

  • 每秒钟触发落盘

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

    每次都落盘表示每次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日志内容如下:

【专栏】基础篇04| Redis 该怎么保证数据不丢失(上)_第3张图片

而其实执行完这些后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

你可能感兴趣的:(Redis专栏,数据库,redis,nosql)