Redis拾遗（四）
持久化：
- RDB：把当前进程数据生成快照保存到硬盘，出发RDB持久化过程分为手动和自动；
- 手动触发：
- save命令，会阻塞当前Redis服务器，知道RDB过程完成为止（基本废弃）
- bgsave命令，Redis进程执行fork操作创建子进程，RDB持久化由子进程负责。阻塞只发生在fork阶段，时间很短。
- 自动触发：
- 使用save相关配置，会按配置自动触发bgsave
- 如果从节点执行全量复制，主节点自动执行bgsave并发送给从节点。
- 执行debug reload重新加载redis时，也会自动触发save操作。
- 默认情况执行shutdown时，如果没有开启AOF持久化，则自动执行bgsave。
- 优点：
- 压缩紧凑
- 加速恢复数据远快于AOF
- 缺点：
- 没法实时持久化，bgsave属于重量级操作，成本高
- 新旧版本兼容问题
- 手动触发：
- AOF：以独立日志方式记录每次写命令，重启时重新执行AOF中的命令达到数据恢复，属于持久化的主流方式
- 过程：
- 所有写入命令都会追加到aof_buf缓冲区内。
- AOF缓冲区根据对应的策略向硬盘做同步操作。
- 随着AOF文件越来越大，需要定期对AOF文件重写，达到压缩的目的
- 当Redis服务器重启时，可以加载AOF文件进行数据恢复。
- 同步文件策略：everysec（建议的配置）每秒同步一次数据，即使宕机，也会只损失1s的数据。
- 重写机制：将超时的命令剔除；无效命令剔除；多条命令合并。降低空间，加速加载。也分自动触发和手动触发。不在此赘述。
- 过程：
- Redis重启时优先加载AOF如果没有的话加载RDB
- 问题优化：
- fork操作：fork创建子进程会复制父进程的空间内存页表，fork操作的耗时与Redis进程内存息息相关。
- 子进程开销优化：CPU密集操作，不要和其他CPU密集服务部署爱一起，造成竞争。避免在大量写入时做子进程重写操作，将导致父进程维护大量页副本，造成内存消耗。
- 多实例部署：保证机器内每个Redis实例AOF重写串行化执行。
复制：
- 目的：解决单点问题，满足故障恢复和负载均衡的要求
- 配置：
- 在配置文件中加入slaveof{masterHost} {masterPort}随Redis启动生效；
- 在redis-server启动命令后加入--slaveof {masterHost} {masterPort}生效；
- 直接使用命令：slaveof{masterHost} {masterPort}生效；
- 查看复制状态信息：info replication
- 断开复制：
- 在从节点上执行slaveof no one断开与主节点复制关系，从节点晋升为主节点。
- 从节点断开复制后并不会抛弃原有数据，只是无法再获取主节点上的数据变化。
- slaveof 还可以切换从节点的主节点，流程如下：1、断开与旧主节点复制关系；2、与新主节点简历复制关系；3、删除从节点当前所有数据；4、对新主节点进行复制操作；
- 安全性：数据比较重要的节点，主节点可以通过设置requirepass参数进行密码验证，这时所有客户端访问必须使用auth命令实行校验。
- 只读：默认情况下从节点使用slave-read-only=yes配置为只读模式，由于复制是从主到从，对从节点任何修改主节点无法感知到，修改从节点会造成主从数据不一致。
- 传输延迟：可以通过配置repl-disable-tcp-nodelay参数来控制是否关闭TCP_NODELAY，默认关闭。
- 拓扑结构：
- 一主一从：当应用写命令并发量较高且需要持久化，可以只在从节点开启AOF功能。要注意主节点脱机避免自动重启操作，因为主节点没有开启持久化功能，自动重启后数据集为空，这时从节点如果继续复制主节点会导致从节点数据也被情况，从而丧失了持久化的意义。安全的做法是在从节点执行slaveof no one 断开与主节点的复制关系型，再重启主节点。
- 一主多从：可以利用多个从节点实现读写分离，对于读占比较大场景，可以把读命令发到从节点分担主节点压力。一些耗时操作也可以分到其中一台从节点执行。对于写并发量较高的场景，多个从节点会导致主节点写命令多次发送消耗网络带宽，家中主节点负载影响服务稳定性。
- 树形结构：当主节点需要挂多个从节点时为了避免对主节点的性能干扰，可以采用树形结构。
- 原理：
- 保存主节点信息；
- 主从建立socket连接
- 发送ping命令；
- 权限验证；
- 同步数据集；
- 命令持续复制；
- Redis主从节点都会维护自己的复制偏移量文件，主节点也存在复制缓冲区，为部分复制提供支持。缓冲区也保证了主从数据的一致性。
