一、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 的日志文件）
3. 集群优化
4. 架构优化