网站规划项目与设计实例,创意设计图案,网站制作平台公司,冻品网站的建设背景哨兵
吹哨人巡查监控后台master主机是否故障#xff0c;如果故障了根据投票数自动将某一个从库转换为主库#xff0c;继续对外服务
哨兵的作用#xff1a; 监控redis运行状态#xff0c;包括master和slave当master宕机了#xff0c;能自动将slave转换为master 哨兵的功能…哨兵
吹哨人巡查监控后台master主机是否故障如果故障了根据投票数自动将某一个从库转换为主库继续对外服务
哨兵的作用 监控redis运行状态包括master和slave当master宕机了能自动将slave转换为master 哨兵的功能 主从监控监控主从redis库运行是否正常消息通知哨兵可以将故障转移的结果发送给客户端故障转移如果master异常则会进行主从切换将其中一个slave作为新的master配置中心客户端通过连接哨兵来获得当前redis服务的主节点地址 哨兵的配置
在sentinel配置文件中除了bind、daemonize、protected-mode、port、logfile、pidfile、dir的配置之外以上配置同普通的redis.conf来就行还有这些配置项要配置
主要 sentinel monitor master-name ip redis-port quorum除了指定master的名字、IP地址、端口号还有一个quorum标识最少有几个哨兵认可认可客观下线同意故障迁移的法定票数。 补充网络有时候不可靠有时候sentinel会因为网络阻塞误以为一个master redis已经宕机了在sentinel集群环境下需要多个sentinel互相沟通来确认某个master时候真的宕机了quorum这个参数是进行客观下线的一个依据意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。增加了容错率、高可用性。 sentinel auth-pass master-name passwordmaster设置了密码指定连接master服务的密码 其他 sentinel down-after-milliseconds master-name milliseconds指定多少毫秒之后主节点没有应答哨兵此时哨兵主观上认为主节点下线sentinel parallel-syncs master-name nums表示允许并行同步的slave个数当Master挂了后哨兵会选出新的Master此时剩余的slave会向新的master发起同步数据sentinel failover-timeout master-name milliseconds故障转移的超时时间进行故障转移时如果超过设置的毫秒表示故障转移失败sentinel notification-script master-name script-path 配置当某一事件发生时所需要执行的脚本sentinel client-reconfig-script master-name script-path客户端重新配置主节点参数脚本 注
启动哨兵的命令是redis-sentinel sentinel.conf --sentinel
如果主机1挂了从机2上位成为主机那么原来的1重新启动后不会重新变成主机而是会变成2的从机。哨兵会动态修改哨兵、主机、从机的相关配置文件的内容。
所以主机也要设置masterauth这样当这台主机挂了之后重新启动成为从机时候能连接上新的主机
哨兵运行流程
当一个主从配置中的master失效之后sentinel可以选举出一个新的master用于自动接替原master的工作主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取
主观下线
主观下线SDOWNSubject Down是单个sentinel自己主观检测到的关于master从sentinel的角度来看如果发送了ping后在一段时间没有收到合法的回复就达到了SDOWN的条件。
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度啊单位是毫秒。默认是30秒。
客观下线
客观下线ODOWNObject Down是需要一定的sentinel多个哨兵达成一致的意见才能认为一个master客观上已经宕机了
选举领导者哨兵
当主节点被判断客观下线后各个节点会进行协商先选举出一个领导者哨兵节点并由该领导者节点进行failover故障迁移使用raft算法
raft算法的了解监视该主节点的所有哨兵都有可能被选为领导者基本思路是先到先得即在一轮选举中哨兵A向B发送成为新的领导者的申请如果B没有同意过其他哨兵则同意A成为领导者
选出新的master
由哨兵领导者开始推动故障切换流程并选出一个新的master。
关于master选举算法 选举出新的master先根据优先级配置文件中的slave-priority或者replica-priority越小优先级越高选优先级大的如果优先级一样的话看哪个slave复制的更完整就选哪个如果完整性也一样就根据run ID最小的选直接根据ascii码值。领导者哨兵会发送给执行slaveof no one命令让选出来的从节点变成主节点并通过slaveof命令让其他节点变成主节点。领导者哨兵会将之前已经下线的老master设置为新选出的master的从节点当老master重新上线后会成为新的master的从节点。老master降级为slave并恢复正常工作。 使用建议 哨兵节点的数量应该为多个哨兵本身应该集群保证高可用性哨兵节点的数量应该是奇数才好选举领导者哨兵各个哨兵节点的配置应该一致如果哨兵节点部署在Docker等容器中尤其要注意端口的正确映射哨兵集群加主从复制并不能保证数据零丢失 集群
由于数据量过大单个master难以承担因此需要对多个复制集进行集群形成水平拓展每个复制集只负责整个数据库的一部分这就是redis的集群其作用是提供在多个redis节点间共享数据的程序集。
redis集群是一个提供在多个redis节点间共享数据的程序集redis集群可以支持多个master。
集群的功能 redis集群支持多个master又支持多个slave。可以实现读写分离、支持数据的高可用、支持海量数据的读写存储操作。由于cluster自带的sentinel的故障转移机制内置了高可用的支持无需再去使用哨兵功能客户端与redis的节点连接不再需要连接集群中的所有节点只需要任意连接集群中的一个可用节点即可槽位slot负责分配到各个物理服务节点又对应的集群来负责维护节点插槽和数据之间的关系 槽位slot
集群的密钥空间被分为16384个槽位有效地设置了16384个主节点的集群大小上限但是建议的最大节点的大小约为1000个
集群中的每个主节点处理16384个哈希槽中的一个子集。当没有集群重新配置正在进行时即哈希槽从一个节点移动到另一个节点集群是稳定的。当集群稳定时单个哈希槽将又单个节点提供服务。
集群没有使用一致性hash而是引入了哈希槽的概念。redis集群有16384个哈希槽每个key通过CRC16校验之后对16384取模来决定放置哪个位置的槽。集群的每个节点负责一部分的hash槽。
分片
使用redis集群时我们会将存储的数据分散到多态redis机器上这成为分片。简言之集群中的每个redis都被认为是整个数据的一个分片。
如何找到指定的key的分片为了找到给定key的分片我们对key进行CRC16(key)算法处理并通过对总分片数量取模。然后使用确定性哈希函数这意味着给定的key将多次始终映射到同一个分片。
分片加槽位的优势方便扩容缩容和数据分派查找无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态
槽位映射算法
哈希取余分区
用户每次读写操作都是根据公式hash(key) % N个机器台数计算出哈希值用来决定数据映射到哪个节点上。 优点简单有效只需要预估好数据规划好节点例如三台、八台、十台就能保证一段时间的数据支撑。使用hash算法让固定的一部分请求落到同一台服务器上这样每台服务器固定处理一部分请求并维护这些请求的信息起到负载均衡分而治之的作用。 缺点原来规划好的节点进行扩容或缩容就更麻烦了。扩容缩容时每次数据变动导致节点有变动映射关系需要重新进行计算再服务器个数固定不变时没有问题如果需要弹性扩容或者故障停机的情况下原来的取模公式就会发生变化。此时地址经过取余运算后的结果将会发生很大变化根据公式获取服务器也会变得不可控。某个redis机器宕机了由于机器数量改变会导致hash区域全部数据重新洗牌。 一致性哈希算法分区
一致性哈希算法设计目标是为了解决分布式缓存数据变动和映射问题分母数量改变了 取余数不行了当服务器个数发生变动时尽量减少影响客户端到服务器的映射关系。
步骤 算法构建一致性哈希环最终哈希值变为 哈希函数求得的值变为对 2的32次方 取模并将0和2的32次方等同将整个全量看作一个环环内的范围就是(0,2^31-1)。redis服务器ip节点映射将集群中的各个ip节点映射到环上的某一个位置。key落到服务器的落键规则当我们需要存储一个kv键值对时首先计算key的hash值确定数据在环上的位置。从此位置沿环顺时针“行走”第一台遇到的服务器就是其应该定位到的服务器并将该键值对存储在该节点上。 优点 容错性如果一台服务器不可用则受影响的数据仅仅是此服务器到其环空间中的上一台服务器即沿着逆时针方向行走遇到的第一台服务器之前的数据且这些数据会转移到下一台服务器上沿着顺时针方向遇到的第一台服务器进行存储。拓展性数据量增加了需要重新增加一台节点受到影响的只是上一台服务器会重新把上一台服务器上应该录到新服务器的数据重新到新的服务器。 缺点
一致性hash算法在服务节点太少时容易因为节点分布不均匀而造成数据倾斜被缓存的对象大部分集中缓存在某一台服务器上问题。
哈希槽分区
哈希槽实质就是一个数组大小是[0,2^14-1]形成的hash slot空间。
它能解决均匀分配的问题在数据和节点之间又加入了一层把这层称为哈希槽slot用于管理数据和节点之间的关系就相当于节点上放的是槽槽里面放的是数据。
槽解决的是粒度问题相当于把粒度变大了如此便于数据移动。哈希解决的是映射问题使用key的哈希槽来计算所在的槽便于数据分配
一个集群只能有16384个哈希槽编号0-163830-2^14-1。这些槽会分配给集群中的所有主节点分配策略没有要求。
集群会记录节点和槽的对应关系解决了节点和槽的关系后接下来就需要对key求哈希值然后对16384取模余数是几key就落入对应的槽里。HASH_SLOT CRC16(key) mod 16384。以槽为单位移动数据因为槽的数目是固定的处理起来比较容易这样数据移动问题就解决了。
为何最大槽数是16384 如果槽位为65536发送的心跳信息的消息头达到了8k发送的心跳包过于庞大。redis的集群主节点数量基本不可能超过1000个。槽位越小节点少的情况下压缩比高容易传输。 注 redis集群不保证强一致性这意味着在特定的条件下redis集群可能会丢掉一些被系统收到的写入请求命令。redis集群也存在类似于哨兵的机制主机宕机后从机会上位成为主机主机再次归来的时候会变为从机。如果想要节点从属调整使用命令CLUSTER FAILOVER使用 redis-cli -a 密码 --cluster reshard IP地址:端口号 命令扩容后重新分配槽位后新的主机对应的槽位是原来的各个主机各自匀一点凑出来的。缩容的时候可以将空出来的槽位给指定的主机全部接收。不在同一个slot槽位下的键值无法使用mset、mget等多键操作。可以通过{}来定义同一个组的概念使key中{}内相同内容的键值对放到一个slot槽位去。比如mset k1{aaa} 111 k2{aaa} 222mget k1{aaa} k2{aaa}
