redis相关文章
----redis原理概述
-----redis集群方案
----redis分区(分片)原理
----Redis实现分布式锁
----redis缓存穿透、雪崩和解决方案
1、哨兵模式
哨兵是 redis 集群机构中非常重要的一个组件
1.1 功能
- 集群监控:负责监控 redis master 和 slave 进程是否正常工作
- 消息通知:如果某个 redis 实例有故障,那么哨兵负责发送消息作为报警通知给管理员
- 故障转移:如果 master node 挂掉了,会自动转移到 slave node 上
- 配置中心:如果故障转移发生了,通知 client 客户端新的 master 地址
1.2 实现 redis 集群的高可用
- 故障转移时,判断一个 master node 是否宕机了,需要大部分的哨兵都同意才行,涉及到了分布式选举的问题
- 即使部分哨兵节点挂掉了,哨兵集群还是能正常工作的,高可用机制重要组成部分的故障转移系统本身是分布式的
1.3 核心知识
- 哨兵至少需要 3 个实例,来保证自己的健壮性
- 哨兵 + redis 主从的部署架构,是
不保证数据零丢失
的,只能保证 redis 集群的高可用性
2、 官方Redis Cluster 方案(服务端路由查询)
2.1 简介
Redis Cluster是一种服务端Sharding(分片)技术,3.0版本开始正式提供。Redis Cluster并没有使用一致性hash,而是采用slot(槽)的概念,一共分成16384个槽。将请求发送到任意节点,接收到请求的节点会将查询请求发送到正确的节点上执行
2.2 方案说明
1. 方案实现
- 通过哈希的方式,将数据分片,每个节点均分存储一定哈希槽(哈希值)区间的数据,默认分配了16384 个槽位
- 每份数据分片会存储在多个互为主从的多节点上(Node1、Node2、Node3都存储了其它节点的分片数据)
- 数据写入先写主节点,再同步到从节点(支持配置为阻塞同步)
- 同一分片多个节点间的数据不保持一致性
- 读取数据时,当客户端操作的key没有分配在该节点上时,redis会返回转向指令,指向正确的节点
- 扩容时需要把旧节点的数据迁移一部分到新节点
-
redis cluster节点分配
现在我们是三个主节点分别是:Node1, Node2, Node3 三个节点,它们可以是一台机器上的三个端口,也可以是三台不同的服务器。那么,采用哈希槽 (hash slot)的方式来分配16384个slot 的话,它们三个节点分别承担的slot 区间-
Node1覆盖0-5460
-
Node2覆盖5461-10922
-
Node3覆盖10923-16383
-
每个节点会生成各自的从节点slave1、slave2、slave3,保存各自节点的分片数据,同步到其它节点中
每个节点都保存这其它节点的从节点分片数据
- 获取数据
如果存入一个值,按照redis cluster哈希槽的算法: CRC16(‘key’)384 = 6782。 那么就会把这个key 的存储分配到 B 上了。同样,当我连接(A,B,C)任何一个节点想获取’key’这个key时,也会这样的算法,然后内部跳转到B节点上获取数据 - 新增一个主节点
新增一个节点D,redis cluster的这种做法是从各个节点的前面各拿取一部分slot到D上- 节点A覆盖1365-5460
- 节点B覆盖6827-10922
- 节点C覆盖12288-16383
- 节点D覆盖0-1364,5461-6826,10923-12287
删除一个节点也是类似,移动完成后就可以删除节点
2. 端口
在 redis cluster 架构下,每个 redis 要放开两个端口号,比如一个是 6379,另外一个就是 加1w的端口号,比如 16379
- 16379 端口号
是用来进行节点间通信的,也就是cluster bus 的通信,用来进行故障检测、配置更新、故障转移授权 - gossip 协议
cluster bus 用了另外一种二进制的协议,gossip 协议,用于节点间进行高效的数据交换,占用更少的网络带宽和处理时间
2.3 分布式寻址算法
- hash 算法(大量缓存重建)
- 一致性 hash 算法(自动缓存迁移)+ 虚拟节点(自动负载均衡)
- redis cluster 的 hash slot 算法
2.4 优点
- 无中心架构,支持动态扩容,对业务透明
- 具备Sentinel的监控和自动Failover(故障转移)能力
- 客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
- 高性能,客户端直连redis服务,免去了proxy代理的损耗
2.5 缺点
- 增加运维难度,数据迁移需要人工干预
- 不支持批量操作(pipeline管道操作)
- 分布式逻辑和存储模块耦合等
3、基于客户端分片
3.1 简介
Redis Sharding是Redis Cluster出来之前,业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列,通过hash函数,特定的key会映射到特定的Redis节点上。Java redis客户端驱动jedis,支持Redis Sharding功能,即ShardedJedis以及结合缓存池的ShardedJedisPool
- 优势
非常简单,服务端的Redis实例彼此独立,相互无关联,每个Redis实例像单个服务器一样运行,非常容易线性扩展,系统的灵活性很强 - 缺点
- 由于sharding处理放到客户端,规模进一步扩大时给运维带来挑战。
- 客户端sharding不支持动态增删节点。服务端Redis实例结构有变化时,每个客户端都需要更新调整。连接不能共享,当应用规模增大时,资源浪费制约优化
4、基于代理服务器分片
4.1 简介
客户端发送请求到一个代理组件,代理解析客户端的数据,并将请求转发至正确的节点,最后将结果回复给客户端
4.2 特征
- 透明接入,业务程序不用关心后端Redis实例,切换成本低
- Proxy 的逻辑和存储的逻辑是隔离的
- 代理层多了一次转发,性能有所损耗
5、 Redis 主从架构
5.1 简介
单机的 redis,能够承载的 QPS 大概就在上万到几万不等。对于缓存来说,一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构,一主多从,主负责写
,并且将数据复制到其它的slave 节点,从节点负责读。所有的读请求全部走从节点
。这样也可以很轻松实现水平扩容,支撑读高并发
- redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发
5.2 核心机制
- redis 采用
异步方式
复制数据到 slave 节点,不过 redis2.8 开始,slave node 会周期性地确认自己每次复制的数据量 - 一个 master node 是可以配置多个 slave node
- slave node 也可以连接其他的 slave node
- slave node 做复制的时候,不会 阻塞 master node 的正常工作
- slave node 在做复制的时候,也不会 阻塞对自己的查询操作,它会用旧的数据集来提供服务,复制完成的时候,需要删除旧数据集,加载新数据集,会暂停对外服务
- slave node 主要用来进行横向扩容,做读写分离,扩容的 slave node 可以
提高读的吞吐量
5.3 核心原理
- 当启动一个 slave node 的时候,它会发送一个 PSYNC 命令给 master node
- slave node 初次连接到 master node,那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程,开始生成一份 RDB 快照文件
- 同时还会将从客户端 client 新收到的所有写命令缓存在内存中。 RDB 文件生成完毕后, master会将这个 RDB 发送给 slave,slave 会
先写入本地磁盘,然后再从本地磁盘加载到内存中
- 接着 master 会将内存中缓存的写命令发送到 slave,slave 也会同步这些数据
- slave node 如果跟 master node 有网络故障,断开了连接,会自动重连,连接之后, master node仅会复制给 slave 部分缺少的数据
5.4 Redis哈希槽
Redis集群没有使用一致性hash,而是引入了哈希槽的概念,Redis集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽,集群的每个节点负责一部分hash槽
redis相关文章
----redis原理概述
-----redis集群方案
----redis分区(分片)原理
----Redis实现分布式锁
----redis缓存穿透、雪崩和解决方案