目录
一、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 主进程配合实现备份冗余,提高抗高并发的能力