一、redis重要内容

1.主从复制流程

• slave向master发送sync_command申请同步
• master主进程派生RDB子进程进行持久化 生成RDB文件
• 将RDB文件推送给slaves（完成全量复制）
• 增量同步：使用到了AOF持久化（机制：将缓存数据保存在缓存区中），所以主从节点均需要开启AOF
• 增量同步时通过AOF功能 将缓存中的数据append（追加）到缓冲中来进行master缓冲——slave缓冲的同步
• 持续性的运行中，还是增量同步的过程

mini版：

• 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群集的功能

1.数据分区：数据分区(或称数据分片)是集群最核心的功能。

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

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

3.数据分片

• 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 ：淘汰策略
  1)缓存中的数据进行随机淘汰
  2)缓存中被设置了过期时间的数据进行随机淘汰
  3）缓存中被设置了过期时间的数据，进行惰性删除（仅当访问到的数据过期了，才会删除)
  4)当数据持续存储过程中，内存将满，会在设置了过期时间的数据中，进行近期淘汰
• ②令牌桶＋漏桶算法:限流
• ③Raft：
  选举机制，用于选举新的主节点的算法

6.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. 架构优化