redis的两种持久化方案：从应用到底层 36张图带你进入Redis世界

redis的两种持久化方案：从应用到底层 36张图带你进入Redis世界使用布隆过滤器得到的判断结果：不存在的一定不存在，存在的不一定存在。PS : Redis 它的通讯协议是基于TCP的应用层协议 RESP(REdis Serialization Protocol)。在 Redis 中BitMap 底层是基于字符串类型实现的，可以把 Bitmaps 想象成一个以比特位为单位的数组，数组的每个单元只能存储0和1，数组的下标在 Bitmaps 中叫做偏移量，BitMap 的 offset 值上限 2^32 - 1。key = 年份：用户id offset = （今天是一年中的第几天） % （今年的天数）使用日期作为 key，然后用户 id 为 offset 设置不同offset为0 1 即可。

1.7、HyperLogLog

HyperLogLog ：是一种概率数据结构，它使用概率算法来统计集合的近似基数。而它算法的最本源则是伯努利过程 分桶 调和平均数。具体实现可看 HyperLogLog 讲解。

功能：误差允许范围内做基数统计 (基数就是指一个集合中不同值的个数) 的时候非常有用，每个HyperLogLog的键可以计算接近2^64不同元素的基数，而大小只需要12KB。错误率大概在0.81%。所以如果用作 UV 统计很合适。

HyperLogLog底层 一共分了 2^14 个桶，也就是 16384 个桶。每个(registers)桶中是一个 6 bit 的数组，这里有个骚操作就是一般人可能直接用一个字节当桶浪费2个bit空间，但是Redis底层只用6个然后通过前后拼接实现对内存用到了极致，最终就是 16384*6/8/1024 = 12KB。

1.8、bitmap

BitMap 原本的含义是用一个比特位来映射某个元素的状态。由于一个比特位只能表示 0 和 1 两种状态，所以 BitMap 能映射的状态有限，但是使用比特位的优势是能大量的节省内存空间。

在 Redis 中BitMap 底层是基于字符串类型实现的，可以把 Bitmaps 想象成一个以比特位为单位的数组，数组的每个单元只能存储0和1，数组的下标在 Bitmaps 中叫做偏移量，BitMap 的 offset 值上限 2^32 - 1。

1. 用户签到

key = 年份：用户id offset = （今天是一年中的第几天） % （今年的天数）

2. 统计活跃用户

使用日期作为 key，然后用户 id 为 offset 设置不同offset为0 1 即可。

PS : Redis 它的通讯协议是基于TCP的应用层协议 RESP(REdis Serialization Protocol)。

1.9、Bloom Filter

使用布隆过滤器得到的判断结果：不存在的一定不存在，存在的不一定存在。

布隆过滤器 原理：

当一个元素被加入集合时，通过K个散列函数将这个元素映射成一个位数组中的K个点(有效降低冲突概率)，把它们置为1。检索时，我们只要看看这些点是不是都是1就知道集合中有没有它了：如果这些点有任何一个为0，则被检元素一定不在；如果都是1，则被检元素很可能在。这就是布隆过滤器的基本思想。

想玩的话可以用Google的guava包玩耍一番。

1.10 发布订阅

redis提供了发布、订阅模式的消息机制，其中消息订阅者与发布者不直接通信，发布者向指定的频道（channel）发布消息，订阅该频道的每个客户端都可以接收到消息。不过比专业的MQ(RabbitMQ RocketMQ ActiveMQ Kafka)相比不值一提，这个功能就算球了。

2、持久化

因为Redis数据在内存，断电既丢，因此持久化到磁盘是必须得有的，Redis提供了RDB跟AOF两种模式。

2.1、RDB

RDB 持久化机制，是对 Redis 中的数据执行周期性的持久化。更适合做冷备。优点：

1、压缩后的二进制文，适用于备份、全量复制，用于灾难恢复加载RDB恢复数据远快于AOF方式，适合大规模的数据恢复。

2、如果业务对数据完整性和一致性要求不高，RDB是很好的选择。数据恢复比AOF快。

缺点：

1、RDB是周期间隔性的快照文件，数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。

2、备份时占用内存，因为Redis 在备份时会独立fork一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。所以要考虑到大概两倍的数据膨胀性。

注意手动触发及COW：

1、SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，导致无法提供服务。2、BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，在保存完成后向主进程发送信号告知完成。在BGSAVE 执行期间仍可以继续处理客户端的请求。

3、Copy On Write 机制，备份的是开始那个时刻内存中的数据，只复制被修改内存页数据，不是全部内存数据。

4、Copy On Write 时如果父子进程大量写操作会导致分页错误。

2.2、AOF

AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像 Mysql 中的binlog。AOF更适合做热备。

优点：

AOF是一秒一次去通过一个后台的线程fsync操作，数据丢失不用怕。

缺点：

1、对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2、根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的。

AOF整个流程分两步：第一步是命令的实时写入，不同级别可能有1秒数据损失。命令先追加到aof_buf然后再同步到AO磁盘，如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。

第二步是对aof文件的重写，目的是为了减少AOF文件的大小，可以自动触发或者手动触发(BGREWRITEAOF)，是Fork出子进程操作，期间Redis服务仍可用。