手机可以做网站服务器吗,游戏是怎么制作的,乐清做手机网站,北京建网站公司哪家便宜文章目录 一、redis高可用性概述二、主从复制2.1 主从复制2.2 数据同步的方式2.2.1 全量数据同步2.2.2 增量数据同步 2.3 实现原理2.3.1 服务器 RUN ID2.3.2 复制偏移量 offset2.3.3 环形缓冲区 三、哨兵模式3.1 原理3.2 配置3.3 流程3.4 使用3.5 缺点 四、cluster集群4.1 原理… 文章目录 一、redis高可用性概述二、主从复制2.1 主从复制2.2 数据同步的方式2.2.1 全量数据同步2.2.2 增量数据同步 2.3 实现原理2.3.1 服务器 RUN ID2.3.2 复制偏移量 offset2.3.3 环形缓冲区 三、哨兵模式3.1 原理3.2 配置3.3 流程3.4 使用3.5 缺点 四、cluster集群4.1 原理4.2 特征4.3 流程4.4 缺点4.5 故障转移4.5.1 故障检测4.5.2 故障转移 4.6 集群配置和管理4.6.1 主要命令4.6.2 创建集群4.6.3 查看集群配置信息4.6.4 测试集群4.6.5 扩容4.6.6 缩容 一、redis高可用性概述
1、高可用是分布式的概念。 Redis的高可用性是指在Redis集群中当主节点宕机了通过切换备用节点顶替它继续运行保持系统正常运行且数据可靠性不受影响。
2、通过实现Redis的高可用性可以提供以下几个主要优势 1避免单点故障通过配置和设置多个Redis节点如果其中一个节点发生故障其他节点可以接替工作避免了单点故障对整个系统的影响。
2数据冗余和复制通过数据的复制和持久化备份Redis能够在主节点出现故障时自动切换到备用节点并恢复数据确保数据的持久性和可用性。
3故障自动检测和故障转移Redis的高可用方案通常具备故障检测和自动故障转移的功能能够监控节点的健康状态并在节点故障时自动将从节点升级为主节点。
3、因此redis的高可用主要完成以下工作 1数据同步。主节点和从节点备用节点之间的数据需要进行同步。
2主从切换。若主节点宕机需要有一种机制可以切换从节点变成主节点。
二、主从复制
2.1 主从复制
主从复制是数据同步方式解决了单点故障的问题但不能保证高可用是高可用的基础。主要用来实现 redis 数据的可靠性防止主 redis 所在磁盘损坏造成数据永久丢失。
主从之间采用异步复制的方式以及采用读写分离的方式主节点master可以进行读写操作从节点replica一般是只读。也就是说所有的数据修改只在主节点上进行然后将最新的数据同步给节点这样就使得主从服务器的数据是一致的。 需要注意的是 1主从复制无法提供高可用和数据保护能力因为主节点发生故障时需要手动进行故障转移。
2从节点主动向主节点建立连接从节点主动同步主节点的数据。
2.2 数据同步的方式
2.2.1 全量数据同步
1全量数据同步是在从节点刚加入复制集群或者需要进行完整数据更新时执行的同步过程。
2它的目标是将主节点上的所有数据完整地同步到从节点。全量数据同步的过程是将主节点上的所有内存数据通过快照RDB文件方式发送给从节点从节点接收到快照后将其加载到自己的数据库中。
3全量数据同步会消耗较大的网络带宽和时间特别是在数据集较大的情况下。并且在全量数据同步过程中从节点无法处理外部的读取请求因为它正在重新加载大量的数据。
2.2.2 增量数据同步
1增量数据同步是在全量数据同步完成后用于保持主从节点之间数据的一致性。
2它通过记录主节点上的增量写命令例如AOF日志文件并将其发送给从节点来实现。增量数据同步的过程是在主节点上记录所有的写操作并将这些操作记录传输给从节点从节点接收到后执行这些操作以保持与主节点的数据一致。
3增量数据同步具有实时性可以减少数据同步的延迟
从数据库会记录一个偏移量offset即记录同步到哪里了。当从数据库断开重连主数据库补发丢失数据到从数据库。此时如果offset在环形缓冲区当中从数据库就会将offset后面的那部分数据同步过来增量同步如果offset不在环形缓存区中说明数据过期太久就会全量同步把主数据库内部所有数据都同步过来。
2.3 实现原理
主从复制主要由环形缓冲区、复制偏移量、RUN ID三个部分组成。
2.3.1 服务器 RUN ID
RUNID用于构建主从的关系。无论主库还是从库都有自己的 RUN ID RUN ID 启动时自动产生 RUN ID 由 40 个随机的十六进制字符组成。
当从库对主库初次复制时主库将自身的 RUN ID 传送给从库从库会将 RUN ID 保存。 当从库断线重连主库时从库将向主库发送之前保存的 RUN ID ∙ \bullet ∙ 从库 RUN ID 和主库 RUN ID 一致说明从库断线前复制的就是当前的主库主库尝试执行增量同步操作 ∙ \bullet ∙ 若不一致说明从库断线前复制的主库并不时当前的主库则主库将对从库执行全量同步操作。
2.3.2 复制偏移量 offset
主从都会维护一个复制偏移量 ∙ \bullet ∙ 主库向从库发送 N 个字节的数据时将自己的复制偏移量上加 N ∙ \bullet ∙ 从库接收到主库发送的 N 个字节数据时将自己的复制偏移量加上 N。
通过比较主从偏移量得知主从之间数据是否一致偏移量相同则数据一致偏移量不同则数据不一致。
2.3.3 环形缓冲区
本质固定长度先进先出队列。
当因某些原因网络抖动或从库宕机从库与主库断开连接避免重新连接后开始全量同步在主库设置了一个环形缓冲区该缓冲区会在从库失联期间累计主库的写操作当从库重连会发送自身的复制偏移量到主库主库会比较主从的复制偏移量“ ∙ \bullet ∙ 若从库 offset 还在复制积压缓冲区中则进行增量同步 ∙ \bullet ∙ 否则主库将对从库执行全量同步。 三、哨兵模式
3.1 原理
哨兵模式是 Redis 可用性的解决方案它由一个或多个 sentinel实例构成 sentinel 系统。该系统通过 ping-pong 心跳检测的方法监视任意多个主库以及这些主库所属的从库。当主库处于下线状态自动将该主库所属的某个从库升级为新的主库从而实现高可用。
客户端来连接集群时会首先连接 sentinel通过 sentinel 来查询主节点的地址然后再连接主节点进行数据交互。当主节点发生故障时客户端会重新向 sentinel 索要主库地址sentinel会将最新的主库地址告诉客户端。通过这样客户端无须重启即可自动完成节点切换。
Sentinel 节点个数是奇数不存储数据用来监控节点的状态和选举主节点只提供一个数据节点服务。Sentinel 节点不仅监控 Redis 主从节点同时还互相监控形成多哨兵模式。
Sentinel 模式当中涉及的多个选举流程采用的是 raft 一致性算法。 3.2 配置
# sentinel.cnf
# sentinel 只需指定检测主节点就行了通过主节点自动发现从节点
sentinel monitor mymaster 127.0.0.1 6379 2
# 判断主观下线时长
sentinel down-after-milliseconds mymaster 30000
# 指定可以有多少个Redis服务同步新的主机一般而言这个数字越小同步时间越长而越大则对网络资源要求越高
sentinel parallel-syncs mymaster 1
# 指定故障切换允许的毫秒数超过这个时间就认为故障切换失败默认为3分钟
sentinel failover-timeout mymaster 180000
3.3 流程
1主观下线 sentinel 会以每秒一次的频率向所有节点其他sentinel、主节点、以及从节点发送 ping 消息然后通过接收返回判断该节点是否下线。如果在配置指定 down-after-milliseconds 时间内则被判断为主观下线。
2客观下线 当一个 sentinel 节点将一个主节点判断为主观下线之后为了确认这个主节点是否真的下线它会向其他 sentinel 节点进行询问如果收到一定数量半数以上的已下线回复sentinel 会将主节点判定为客观下线并通过领头 sentinel 节点对主节点执行故障转移。
3故障转移 主节点被判定为客观下线后开始领头 sentinel 选举。按照谁发现谁处理的原则选举领头 sentinel需要半数以上的 sentinel 支持。选举领头 sentinel 后开始执行对主节点故障转移 ∙ \bullet ∙ 从从节点中选举一个从节点作为新的主节点 ∙ \bullet ∙ 通知其他从节点复制连接新的主节点 ∙ \bullet ∙ 若故障主节点重新连接将作为新的主节点的从节点
3.4 使用
1连接哨兵节点 —— 连接一个哨兵节点并且获取主节点信息SENTINEL GET-MASTER-ADDR-BY-NAME 。
2获取主节点地址并连接 —— 验证当前获取的主节点ROLE 或者 INFO REPLICATION。
3发起发布订阅连接监听主节点迁移信息 —— 为当前连接的哨兵节点添加发布订阅PUB/SUB连接并且订阅 switch-master 频道以此互相感知互相连接组成哨兵集群。
3.5 缺点
redis 采用异步复制的方式意味着当主节点挂掉时从节点可能没有收到全部的同步消息这部分未同步的消息将丢失。如果主从延迟特别大那么丢失可能会特别多。sentinel 无法保证消息完全不丢失但是可以通过配置来尽量保证少丢失。
# 主库必须有一个从节点在进行正常复制否则主库就停止对外
写服务此时丧失了可用性
min-slaves-to-write 1
# 这个参数用来定义什么是正常复制该参数表示如果在10s内
没有收到从库反馈就意味着从库同步不正常
min-slaves-max-lag 10总结来说 1部署麻烦哨兵模式的配置相对复杂需要管理和维护多个哨兵节点以及与它们关联的 Redis 服务器。调试和故障排除也可能变得更加困难。
2数据一致性哨兵模式下的故障转移是异步进行的这意味着在发生主服务器故障时可能会有一段时间内的数据丢失。因此在一些对数据一致性要求非常高的场景下哨兵模式可能无法满足需求。
3难以在线扩容的缺点Redis的容量受限于单机配置
4延迟增加当主服务器故障时哨兵节点需要通过选举机制选择新的主服务器并通知其他从服务器切换到新的主服务器。这个过程需要时间至少十几秒会导致系统的延迟增加。
5单点故障哨兵节点是集群的核心它们负责监控主服务器和从服务器的状态并执行故障转移操作。然而如果哨兵节点本身发生故障整个系统的可用性将会受到影响。
四、cluster集群
4.1 原理
Redis cluster 通过将数据库分散存储到多个节点上来平衡各个节点的负载压力实现了 Redis 的分布式存储。
通过分布式一致性hash算法crc(key)%16384将所有数据划分为 16384 2 14 2^{14} 214个槽位每个redis 节点负责其中一部分槽位。cluster 集群是一种去中心化的集群方式
如图该集群由三个 redis 节点组成每个节点负责整个集群的一部分数据每个节点负责的数据多少可能不一样。这三个节点相互连接组成一个对等的集群它们之间通过一种特殊的二进制协议交互集群信息。
当 redis cluster 的客户端来连接集群时会得到一份集群的槽位配置信息。这样当客户端要查找某个 key 时可以直接定位到目标节点。 客户端为了可以直接定位对 key 通过 crc16 进行 hash 再对 2 14 2^{14} 214取余 crc16(key)% 16384某个具体的 key 所在节点需要缓存槽位相关信息这样才可以准确快速地定位到相应的节点。同时因为可能会存在客户端与服务器存储槽位的信息不一致的情况还需要纠正机制比如通过返回 -MOVED 3999 127.0.0.1:6479 客户端收到后需要立即纠正本地的槽位映射表来实现槽位信息的校验调整。
另外redis cluster 的每个节点会将集群的配置信息持久化到配置文件中这就要求确保配置文件是可写的而且尽量不要依靠人工修改配置文件。
4.2 特征
1去中心化主节点关系对等
2解决了数据扩容
3客户端与服务端缓存槽位信息以服务端为准客户节点缓存主要为了避免连接切换
4可人为迁移数据
5主节点处理读写命令
4.3 流程
1连接集群中任意一个节点
2若数据不在该节点将收到连接切换的命令继而连接到目标节点
3故障转移主节点下移 ∙ \bullet ∙ 集群结点间互相监控交换节点的状态信息 ∙ \bullet ∙ 若某主节点下线将会被其他主节点标记下线 ∙ \bullet ∙ 接着从下线主节点的从节点中选择一个数据最新的从节点作为主节点 ∙ \bullet ∙ 从节点继承下线主节点的槽位信息并广播该消息给集群中的其他节点
4.4 缺点
主从异步复制在故障转移时仍存在数据丢失的问题
4.5 故障转移
cluster 集群中节点分为主节点和从节点其中主节点用于处理槽而从节点则用于复制该主节点并在主节点下线时代替主节点继续处理命令请求。
4.5.1 故障检测
集群中每个节点都会定期地向集群中的其他节点发送 ping 消息如果接收 ping 消息的节点没有在规定时间内回复 pong消息那么这个没有回复 pong消息的节点会被标记为 PFAILprobable fail。
集群中各个节点会通过互相发送消息的方式来交换集群中各个节点的状态信息如果在一个集群中半数以上负责处理槽的主节点都将某个主节点 A 报告为疑似下线那么这个主节点 A将被标记为下线 FAIL )标记主节点 A 为下线状态的主节点会广播这条消息其他节点包括A节点的从节点也会将A节点标识为 FAIL
4.5.2 故障转移
当从节点发现自己的主节点进入 FAIL 状态从节点将开始对下线主节点进行故障转移 ∙ \bullet ∙ 从数据最新的从节点中选举为主节点 ∙ \bullet ∙ 该从节点会执行 replica no one 命令称为新的主节点 ∙ \bullet ∙ 新的主节点会撤销所有对已下线主节点的槽指派并将这些槽全部指派给自己 ∙ \bullet ∙ 新的主节点向集群广播一条 pong 消息这条 pong 消息可以让集群中的其他节点立即知道这个节点已经由从节点变成主节点并且这个主节点已经接管了之前下线的主节点 ∙ \bullet ∙ 新的主节点开始接收和自己负责处理的槽有关的命令请求故障转移结束
4.6 集群配置和管理
4.6.1 主要命令
redis-cli --cluster help# 创建集群
create ip:port
--cluster-replicas num # 创建集群的同时为每个主节点配备的从节点个数# 查看集群的信息群中任意节点地址作为参数后面同理
info ip:port
# 检查集群的配置
check ip:port # 重分片将指定数量的槽从源节点迁移至目标节点由目标节点负责迁移的槽和槽中数据
reshared ip:port
--cluster-from # 源节点的ID
--cluster-to # 目标节点的ID
--cluster-slots num # 需要迁移的槽数量# 添加节点添加新节点 new 集群 existing默认添加主节点
add-node new_host:port existing_host:port
# 添加从节点需要以下两个子命令
--cluster-slave
--cluster-master-id id # 设置从节点要复制的主节点# 移除节点
del-node ip:port id4.6.2 创建集群
zxmubuntu:~/cluster-example$ redis-cli --cluster create 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 --cluster-replicas 14.6.3 查看集群配置信息
zxmubuntu:~/cluster-example$ redis-cli --cluster check 127.0.0.1:7001
127.0.0.1:7001 (0456481a...) - 1 keys | 6461 slots | 1 slaves.
127.0.0.1:7002 (2b83d979...) - 1 keys | 4961 slots | 1 slaves.
127.0.0.1:7003 (da48c6b4...) - 0 keys | 4962 slots | 1 slaves.
[OK] 2 keys in 3 masters.
0.00 keys per slot on average.Performing Cluster Check (using node 127.0.0.1:7001)
M: 0456481a2e18b0ec97ad8173dd0352f890d39659 127.0.0.1:7001slots:[0-5961],[10923-11421] (6461 slots) master1 additional replica(s)
S: 78d4179ab020052fbc4197d4d7867607c3787d27 127.0.0.1:7006slots: (0 slots) slavereplicates da48c6b4d48ae37d6e8ac6b1e12e9e2831f484e2
S: 96d453c5607eef91ce068f0c09193877a1cf3346 127.0.0.1:7004slots: (0 slots) slavereplicates 0456481a2e18b0ec97ad8173dd0352f890d39659
S: 1e8d9da3b8649c3b52ef407d031efbb11bcc56c1 127.0.0.1:7005slots: (0 slots) slavereplicates 2b83d9798821b0e2b1353c8b83da17e018b2b754
M: 2b83d9798821b0e2b1353c8b83da17e018b2b754 127.0.0.1:7002slots:[5962-10922] (4961 slots) master1 additional replica(s)
M: da48c6b4d48ae37d6e8ac6b1e12e9e2831f484e2 127.0.0.1:7003slots:[11422-16383] (4962 slots) master1 additional replica(s)
[OK] All nodes agree about slots configuration.Check for open slots...Check slots coverage...
[OK] All 16384 slots covered.4.6.4 测试集群
#集群模式主从节点对等可从任意节点进入。
# 虽然从7005进入但是crc16计算后应分配在7002节点切换
zxmubuntu:~/cluster-example$ redis-cli -c -h 127.0.0.1 -p 7005
127.0.0.1:7005 set zxm 1
- Redirected to slot [9010] located at 127.0.0.1:7002
OK# 虽然从7005进入但是zxm的值在7002节点切换
zxmubuntu:~/cluster-example$ redis-cli -c -h 127.0.0.1 -p 7005
127.0.0.1:7005 get zxm
- Redirected to slot [9010] located at 127.0.0.1:7002
14.6.5 扩容
先添加节点再分配槽位。
# 1创建节点文件
cp -R 7001 7007
cd 7007
mv 7001.conf 7007.conf
rm 7001.log dump.rdb nodes-7001.conf
sed -i s/7001/7007/g 7007.confcd ..
cp -R 7007 7008
cd 7008
mv 7007.conf 7008.conf
sed -i s/7007/7008/g 7008.confcd ..
redis-server 7007/7007.conf
redis-server 7008/7008.conf# 2, 添加节点
# 添加主节点新添加的节点默认作为主节点
redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7001
# 添加从节点
redis-cli --cluster add-node 127.0.0.1:7008 127.0.0.1:7001 --cluster-slave --cluster-master-id 0456481a2e18b0ec97ad8173dd0352f890d39659 # 3分配槽位
# 重分片将主节点 7001 的 1000 个槽迁移至新的主节点 7007
redis-cli --cluster reshard 127.0.0.1:7001 --cluster-from 0456481a2e18b0ec97ad8173dd0352f890d39659 --cluster-to 9f3d34828e1eb41214c158a142c350ca3f604487 --cluster-slots 10004.6.6 缩容
先移动槽位再删除节点.
# 1移动槽位
# 将主节点 7007 的所有槽迁移至主节点 7001
redis-cli --cluster reshard 127.0.0.1:7001 --cluster-from 9f3d34828e1eb41214c158a142c350ca3f604487 --cluster-to 0456481a2e18b0ec97ad8173dd0352f890d39659 --cluster-slots 1000# 2、删除节点
# 删除节点 7007
redis-cli --cluster del-node 127.0.0.1:7001 9f3d34828e1eb41214c158a142c350ca3f604487 # 此时 7008 成为其他节点的 副本节点
# S: d7316f5d4f0fdef182d7a27c56c911b9fe644b97 127.0.0.1:7008
# slots: (0 slots) slave
# replicates 0456481a2e18b0ec97ad8173dd0352f890d39659
# 删除从节点7008
redis-cli --cluster del-node 127.0.0.1:7001 d7316f5d4f0fdef182d7a27c56c911b9fe644b97
