Redis学习笔记（二）

尽管redis提供的五种数据结构以及足够强大，但是除此之外，redis还提供了许多其他的功能以及优化。本篇博客前期就是通过介绍这些功能来体现redis的强大。

附加功能

redis除了提供五个基础的数据结构外，我们接下来介绍redis中的慢查询，pipeline，发布订阅等优化功能。
慢查询
在许多存储系统中提供满查询日志帮助开发运维人员定位系统存在的慢操作，所谓慢查询日志就是说系统在命令执行前后计算每一条的执行时间，当超过预设的阈值，就把这条命令的相关信息（发生时间，耗时，命令的详细信息）记录下来，redis也提供了类似的命令。
redis通过参数slowlog-max-len来表示慢查询日志最多存储多少条，同时用一个列表来保存慢查询日志，需要注意的是，当达到最大的上限的时候，最远的一条就要被移出列表。
Pipeline
redis客户端执行一条命令分为下面四个过程，发送命令，命令排队，命令执行以及返回结果，其中第一个步骤和第四个步骤成为RTT，当我们一条一条发送命令的时候，每一条命令都要有一个RTT，有的时候这会很占用时间，redis的pipeline可以改善这种情况，它将一组redis命令进行组装，通过一次RTT传输给redis再将命令结果返回给客户端，原本需要n次RTT的时间最终通过pipeline就只需要一个RTT时间就可以完成，节省效率。
发布订阅
redis提供了发布订阅模式的消息机制，此模式下， 消息的发布者和订阅者不直接通信，发布者通过向指定的频道发布消息，订阅该频道的每个客户端都可以接收到消息。

持久化

redis支持RDB和AOF两种持久化，持久化能有效避免因为进程推出造成的数据丢失问题，当下次重启的时候利用之前的持久化文件就可以恢复数据，首先我们来看RDB持久化方式
RDB
RDB持久化是把当前数据生成快照保存到硬盘的过程，分为手动触发和自动触发，在手动触发的情况下，有save与bgsave两种命令，save命令阻塞当前redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成比较久的阻塞，但是后来redis有了bgsave方式，在bgsave方式下redis会fork一个子进程让子进程来执行RDB的过程，所以基本不会造成阻塞。
RDB的优点在于他是一个紧凑的二进制文件，代表在某个时间节点上的redis数据块找，非常适合用于备份，全景恢复等场景，加载RDB的过程远远快于AOF。可是RDB没有办法做到实时持久化，因为他要fork或者阻塞，属于重量级操作，所以执行成本过高，正是因为RDB不能用于秒级持久化，所以redis提供了AOF持久化方式。
AOF
AOF持久化用独立日志的方式来记录每一次的写命令，重启的时候再重新执行AOF文件中的命令达到恢复数据的目的，AOF主要是解决了数据持久化的实时性，目前已经是redis持久化的主流方式。
在使用AOF持久化的时候，（1）首先所有的写命令会追加到aof_buf（缓冲区）中，（2）AOF缓冲区根据对应的策略向硬盘做同步操作（3）当redis服务器重启的时候，可以加载AOF文件进行数据恢复（4）当reids服务器重启后，可以加载AOF文件进行数据恢复。