Raft 共识算法(高可用+强一致)
Raft算法主要应用于分布式集群系统中,如果保证高可用和数据一致性,它主要定义两方面的规范:选主(Leader Election)和复制日志(Log Replication)
1.选主机制
Raft定义了集群节点三个状态:Leader(主)、Follower (从)、Candidate(候选)
主:负责与对接外部输入 ,并保持与从的心跳
从:备份数据、主挂了的时候要挑起重担
候选:当从timeout时间内(150ms 到 300ms,每个节点不一样)没有收到主的心跳,转为此状态
从以下几种情形中分析选主是如何运作的
a.正常初始情况
开始所有节点都是Follower状态,当其中一个节点在timeout过后,就会转变成Candidate并向其它节点发送投票请求,并开始新的timeout。
超过半数Follower节点收到请求并回复确认后,Candidate节点就会转变成Leader节点,并向Follower节点发送心跳
b.Leader 出故障
当Leader出故障后,其它Follower节点按正常初始状态走,直到选出Leader
此时如果原Leader恢复了怎么办呢?在这里定义了Leader选举轮数,次数高的为准,原Leader就会降级为Follower
c.多个Follower同时转变成Candidate
当有多个Candidate时,会向其余节点发送选举请求,Candidate节点会拒绝其它节点的请求,Follower节点接收到其中一个Candidate节点请求后,会拒绝同一选举轮回的其它请求,如果此时其中一个节点获得半数节点同意,自动成为Leader,如果两个Candidate节点没有分出胜负后,当timeout节点会发起第二轮选举请求,此时就看谁先timeout结束并获得半数节点同意,就成为Leader
2.复制日志
数据复制主要是为了保证数据的可靠和一致性,当数据变更时,Leader将数据同步给Follower
从以下几种场景如何执行数据复制
a.正常情况
大致可以分为8个步骤
外部向Leader发布数据,
1.Leader将数据保存,状态为uncommit
2.Leader将数据通过appendEntries发送给Follower
3.Follower将数据保存,状态为uncommit
4.Follower返回确认给Leader
5.Leader收到半数以上Follower的确认后,将数据状态更改为commit
6.Leader返回确认
7.Leader再次通过appendEntries将数据发送给Follower
8.Follower将数据状态更改为commit
b.Network Partition 情况
也就是在部分节点网络问题没法通信情况下
没有Leader的一方,通过选举得到leader,此Leader的选举轮次+1
此时就出现了两个Leader可以对外提供服务
如果此时有外部数据进来,分别传给了L1和L2,未超过半数的一方因为得到确认的数量也未达到半数,所以数据都是uncommit状态,返回也是失败
而超过半数的一方数据为commit
此时如果网络恢复了,通过选举规则,轮次高的Leader一方为继续为Leader,另一方降级为Follower
此时uncommite的数据将被删除,未同步的数据将会被补充
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
web安全测试必须注意的五个方面
随着互联网的飞速发展,web应用在软件开发中所扮演的角色变得越来越重要,同时,web应用遭受着格外多的安全攻击,其原因在于,现在的网站以及在网站上运行的应用在某种意义上来说,它是所有公司或者组织的虚拟正门,所以比较容易遭受到攻击,存在安全隐患。 今天主要给大家分享下有关安全测试的一些知识点以及注意事项。 一、安全测试的验证点 一个系统的安全验证点包括上传功能、注册功能/登陆功能、验证码功能、密码、敏感信息泄露、越权测试、错误信息、session等。 1、上传功能 上传中断,程序是否有判断上传是否成功 上传与服务器端语言(jsp/asp/php)一样扩展名的文件或exe等可执行文件后,确认在服务器端是否可直接运行 2、注册功能/登陆功能 请求是否安全传输 重复注册/登陆 关键cookie是否httponly 会话固定:利用session的不变机制,获取他人认证和授权,然后冒充 3 、验证码功能 短信轰炸 验证码一次性 4、 忘记密码 通过手机号/邮箱找回 程序设计不合理,导致可以绕过短信验证码,从而进行修改(使用burpsuite抓包,修改响应值true) 5 、敏感信息泄漏 数据库/日...
- 下一篇
Kubernetes 弹性伸缩全场景解析 (一):概念延伸与组件布局
传统弹性伸缩的困境 弹性伸缩是 Kubernetes 中被大家关注的一大亮点,在讨论相关的组件和实现方案之前。首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划与实际负载的矛盾。 如上图所示,蓝色的水位线表示集群的容量随着负载的提高不断的增长,红色的曲线表示集群的实际的负载真实的变化。而弹性伸缩要解决的就是当实际负载出现激增,而容量规划没有来得及反应的场景。 常规的弹性伸缩是基于阈值的,通过设置一个资源缓冲水位来保障资源的充盈,通常15%-30%左右的资源预留是比较常见的选择。换言之就是通过一个具备缓冲能力的资源池用资源的冗余换取集群的可用。 这种方式表面上看是没有什么问题的,确实在很多的解决方案或者开源组件中也是按照这种方式进行实现的,但是当我们深入的思考这种实现方案的时候会发现,这种方式存在如下三个经典问题。 1. 百分比碎片难题 在一个 Kubernetes 集群中,通常不只包含一种规格的机器,针对不同的场景、不同的需求,机器的配置、容量可能会有非常大的差异,那么集群伸缩时的百分比就具备非常大的迷惑性。假设我们的集群中存在 4C8G 的机器...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS7,CentOS8安装Elasticsearch6.8.6
- 2048小游戏-低调大师作品
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS7设置SWAP分区,小内存服务器的救世主
- Red5直播服务器,属于Java语言的直播服务器