Redis开发与运维总结（一）
一、持久化
二、复制
三、阻塞情况
四、内存管理
五、Redis Cluster
5.1、数据分布理论
5.2、Redis数据分区
5.3、通信流程
5.3.1、Gossip消息
5.3.2、节点选择
5.4、请求路由
5.4.1、计算槽
5.4.2、槽节点查找
5.5、Smart客户端
5.5.1、smart客户端原理
5.5.2、Smart客户端—JedisCluster
5.6、ASK重定向
5.6.1、客户端ASK重定向流程
5.7、故障发现
5.7.1、主观下线
5.7.2、客观下线
5.8、总结
一、持久化
1） Redis提供了两种持久化方式： RDB和AOF。
2） RDB使用一次性生成内存快照的方式， 产生的文件紧凑压缩比更高， 因此读取RDB恢复速度更快。 由于每次生成RDB开销较大， 无法做到实时持久化， 一般用于数据冷备和复制传输。
3） save命令会阻塞主线程不建议使用， bgsave命令通过fork操作创建子进程生成RDB避免阻塞。
4） AOF通过追加写命令到文件实现持久化， 通过appendfsync参数可以控制实时/秒级持久化。 因为需要不断追加写命令， 所以AOF文件体积逐渐变大， 需要定期执行重写操作来降低文件体积。
5） AOF重写可以通过auto-aof-rewrite-min-size和auto-aof-rewritepercentage参数控制自动触发， 也可以使用bgrewriteaof命令手动触发。
6） 子进程执行期间使用copy-on-write机制与父进程共享内存， 避免内存消耗翻倍。 AOF重写期间还需要维护重写缓冲区， 保存新的写入命令避免数据丢失。
7） 持久化阻塞主线程场景有： fork阻塞和AOF追加阻塞。 fork阻塞时间跟内存量和系统有关， AOF追加阻塞说明硬盘资源紧张。
8） 单机下部署多个实例时， 为了防止出现多个子进程执行重写操作，建议做隔离控制， 避免CPU和IO资源竞争。
二、复制
1） Redis通过复制功能实现主节点的多个副本。 从节点可灵活地通过slaveof命令建立或断开复制流程。
2） 复制支持树状结构， 从节点可以复制另一个从节点， 实现一层层向下的复制流。 Redis2.8之后复制的流程分为： 全量复制和部分复制。 全量复制需要同步全部主节点的数据集， 大量消耗机器和网络资源。 而部分复制有效减少因网络异常等原因造成的不必要全量复制情况。 通过配置合理的复制积压缓冲区尽量避免全量复制。
3） 主从节点之间维护心跳和偏移量检查机制， 保证主从节点通信正常和数据一致。
4） Redis为了保证高性能复制过程是异步的， 写命令处理完后直接返回给客户端， 不等待从节点复制完成。 因此从节点数据集会有延迟情况。
5） 当使用从节点用于读写分离时会存在数据延迟、 过期数据、 从节点可用性等问题， 需要根据自身业务提前作出规避。
6） 在运维过程中， 主节点存在多个从节点或者一台机器上部署大量主节点的情况下， 会有复制风暴的风险。
三、阻塞情况
1） 客户端最先感知阻塞等Redis超时行为， 加入日志监控报警工具可快速定位阻塞问题， 同时需要对Redis进程和机器做全面监控。
2） 阻塞的内在原因： 确认主线程是否存在阻塞， 检查慢查询等信息，发现不合理使用API或数据结构的情况， 如keys、 sort、 hgetall等。 关注CPU使用率防止单核跑满。 当硬盘IO资源紧张时， AOF追加也会阻塞主线程。
3） 阻塞的外在原因： 从CPU竞争、 内存交换、 网络问题等方面入手排查是否因为系统层面问题引起阻塞。
四、内存管理
1） Redis实际内存消耗主要包括： 键值对象、 缓冲区内存、 内存碎片。
2） 通过调整maxmemory控制Redis最大可用内存。 当内存使用超出时，根据maxmemory-policy控制内存回收策略。
3） 内存是相对宝贵的资源， 通过合理的优化可以有效地降低内存的使用量， 内存优化的思路包括：
- 精简键值对大小， 键值字面量精简， 使用高效二进制序列化工具。
- 使用对象共享池优化小整数对象。
- 数据优先使用整数， 比字符串类型更节省空间。
- 优化字符串使用， 避免预分配造成的内存浪费。
- 使用ziplist压缩编码优化hash、 list等结构， 注重效率和空间的平衡。
- 使用intset编码优化整数集合。
- 使用ziplist编码的hash结构降低小对象链规模。