一、持久化
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结构降低小对象链规模。
6459
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
