Redis 优化

---

一、Redis 总结

1. 主从复制流程

• ① 当启动一个 slave 进程时，会向 Master 发送一个 “sync_command” 命令，请求同步连接
• ② Master 会启动一个后台进程，触发 RDB 持久化操作，生成 RDB 快照文件，记录修改数据的所有命令并缓存在数据文件中
• ③ 当后台进程完成缓存操作后，Master 会向 Slave 发送数据文件，Slave 先将数据保存到硬盘中然后再加载到内存中，接着 Master 就会将修改数据的所有操作一起发送给 Slave 端，如果Slave出现了故障导致宕机，则恢复正常后会自动重新连接
• ④ Master 收到 Slave 端机器的连接后，将完整的数据文件发送给 Slave 端的机器，如果 Master 同时收到多个 Slave 发来的同步请求，则会在后台启动一个进程来保存数据文件，然后将其发送给所有的 Slave 端机器，确保所有的 Slave 端机器都保持正常

简略来说：
① slave向master发送sync请求同步
② master使用RDB 生成RDB文件（全量同步）发送给slaves
③ master使用AOF 将缓冲区数据同步给slaver缓存区数据（增量）

2. 哨兵的监控模式

3个哨兵 3个redis

• 三个哨兵之间建立命令链接，周期检测“队友”状态
• 哨兵会向master节点（已在配置文件中指定）发送两条连接，分别是命令连接和订阅连接（为了周期性获取master节点的数据）
• 哨兵向master周期性发送info命令，master（活着的情况下）会返回redis—cli info replication master节点的信息+从节点位置
• 哨兵通过master返回的信息。再会向slaves节点发送info命令，slave返回数据，从而哨兵集群就可以获取到redis所有集群信息
• 哨兵会向服务器发送命令连接，建立自己的hello频道，哨兵会向这个hello频道建立订阅，用于哨兵之间的消息共享

简短的说：
① 3个哨兵互相监听，使用ping互相检测存活
② 3个哨兵分别向数据节点（master)发送命令连接和订阅连接（info命令）获取数据节点信息（包含主从节点）
③ 3个哨兵再想从其他节点发送info，用于获取从节点详细信息 3个哨兵之间通过hello频道进行消息共享

3. Cluster 群集作用

• 数据分区：数据分区(或称数据分片)是集群最核心的功能。
  ① 集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加；另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力
  ② Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及；例如，如果单机内存太大，bgsave和bgrewriteaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出

• 高可用：集群支持主从复制和主节点的自动故障转移（与哨兵类似）；当任一节点发生故障时，集群仍然可以对外提供服务

• 数据分片
  Redis 集群引入了哈希槽的概念，有 16384 个哈希槽（编号 0~16383）
  集群的每个节点负责一部分哈希槽，每个 Key 通过 CRC16 校验后对 16384 取余来决定放置哪个哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作
  以 3 个节点组成的集群为例：
  节点 A 包含 0~5469 号的哈希槽
  节点 B 包含 5461~10922 号的哈希槽
  节点 C 包含 10923~16383 号的哈希槽

4. redis 功能

• redis 可以做为 mysql 的前置缓存数据库，redis 与mysql对接的方式，需要配置线程池，需要定义后端mysgl的位置(IP) + port 端口+对接的方式sock文件的位置,其他策略用于内存/缓存型快速存储(读取)

• 实现的方式
  ①是默认将数据存储在内存/缓存中
  ②具有丰富的数据类型，string list hash set && order set等，
  ③重要数据持久化的功能，持久化的方式:AOF RDB

• 单线程模式，速度快的原因之一
  Epoll + I/o复用(cluster中的slots哈希槽可以充当数据读、取的索引)

5. redis 中的算法

• LRU ：淘汰策略
  ① 缓存中的数据进行随机淘汰
  ② 缓存中被设置了过期时间的数据进行随机淘汰
  ③ 缓存中被设置了过期时间的数据，进行惰性删除（仅当访问到的数据过期了，才会删除)
  ④ 当数据持续存储过程中，内存将满，会在设置了过期时间的数据中，进行近期淘汰

• 令牌桶＋漏桶算法——限流

• Raft——选举机制，用于选举新的主节点的算法

6. redis 缓存高热数据的机制

• 指定提高缓存内数据的命中数，最直接的可以刷脚本，访问这些数据

二、Redis 优化

1. 单例服务器，服务器本身优化

硬件资源选择（系统五大资源）

• 磁盘 固态盘 SCSI（硬件磁盘阵列）
• 服务器内存条选择（本地服务器和云服务器）
• CPU 核数选择
• 网络网卡（本地服务器和云服务器），需要考虑负载压力下的网络流量 QPS

以上需要计算费用成本，还需要考虑到该服务器上的服务在运行时消耗的性能比例（需要预留给系统一部分资源）

服务本身环境的选择

• 操作系统选择 Linux 发行版：centos ubantu redhat server debian alphon mac SUSE（PS：虚拟化 KVM XEN FUFE）

• 基于操作系统，依赖环境。选择最小化安装还是指定操作系统版本的安装 + 指定内核版本。软件是否有依赖（例如：tomcat 需要 JDK，编译需要 gcc gcc-c++ pcre …）

• 软件资源优化 五大负载＋内核优化（TCP协议相关、队列相关、路由转发、重定向、端口、文件打开数、系统的软硬限制等）

2. 单例服务器应用服务本身优化

以 redis 为例

首先从启动读取的恢复文件来看，基于AOF需要开启 AOF功能（RDB 默认）

• RDB 中 save M N 触发周期的选择判定，这会影响到磁盘资源的使用
• AOF 中选择合适的 syncwrite 同步写入磁盘的策略 everysecond

使用过程中，需要考虑到的是内存的使用量（ OOM ）

• 内存淘汰策略：惰性淘汰＋定期删除，禁止淘汰＋定期删除。根据情况选择合适的淘汰策略（配置文件中定义）。

持久化方向
持久化的功能在保证数据完整性的同时，依然会持续性的对磁盘产生存储压力（压力来源于 AOF 和 RDB 生成的数据文件，AOF 和 RDB 的日志文件）。

• 数据/日志文件的定期归档
• 日志文件的分割（保存在日志中心）
• 共享存储 NFS GFS fastDFS

redis主进程

• 可以使用两个 redis 主进程配合实现备份冗余，提高抗高并发的能力

3. 集群优化

4. 架构优化

5. 根据数据流向进行优化