网站后台视频教程,儿童网页设计素材,东莞网站建设策划,手机网站自助建站源码一、多形态的存储型集群
在上阶段#xff0c;我们简单聊了下集群的基本知识#xff0c;以及快速过了一下逻辑处理型集群的内容#xff0c;下面重点来看看存储型集群#xff0c;毕竟这块才是重头戏#xff0c;集群的形态在其中有着多种多样的变化。
逻辑处理型的应用我们简单聊了下集群的基本知识以及快速过了一下逻辑处理型集群的内容下面重点来看看存储型集群毕竟这块才是重头戏集群的形态在其中有着多种多样的变化。
逻辑处理型的应用部署集群架构是为了解决单点故障、获得更高的吞吐量集群内各节点之间没有依赖关系同时遵循着“去中心化思想”即多个节点里没有所谓的“老大”。
反观存储型的应用需要保存数据、记录会话数据、用户认证信息、事务状态等信息如果要搭建集群架构则需要考虑各节点之间的数据一致性和完整性来看个例子 假设现在数据库使用三个节点组成集群如果和业务系统集群一样多个节点之间地位平等此时客户端读写数据时究竟该去到哪个节点呢包含多个操作的事务如何保证落到同一节点用户在A节点登录后如何把登录态连接信息同步给B、C节点
正是因为上述一堆的问题存储型集群里的节点必须要划分等级一定要有一个等级更高的节点来承担客户端的写操作。因此在很长一段时间内涉及到数据存储的应用集群方案都是以主从模式为主。 趣事主从模式对应的英文是Master/Slave不过大家会发现后来许多技术的主从模式都叫Leader/Follower这是为啥因为Master/Slave代表的是“主人/奴隶”再加上集群存在选举机制所以在西方被痛斥为“此命名的政治思想不正确”于是许多技术栈都经历过“语言净化”如Redis…… 好了上面提到主从集群下面来展开聊聊存储型应用的集群方案粗分下来也是两大类 主从模式集群内的节点区分等级可以有一或多个主节点具备完整的读写能力也允许拥有多个从节点但能力方面有所阉割只具备处理读取请求的能力。 分片模式集群内节点地位平等各节点都具备数据读写能力但每个节点只负责一部分数据完整数据分散在各节点上。 1.2、主从架构
主从集群这个概念所有人都熟悉它的身影在各种技术栈随处可见如主从集群、镜像集群、复制集群、副本集群……尽管在不同技术栈的叫法不同可本质上都是同一个东西。 上图是经典的一主多从架构客户端的写请求都会落到主节点A上而后再给同步给B、C这两个从节点这就是大名鼎鼎的“主从复制技术”数据同步有三种方案
同步复制等数据写入集群所有节点后再给客户端返回写入成功半同步复制等集群内一半数量以上的节点写入数据成功后给客户端返回写入成功异步复制数据在主节点上写入成功后立即给客户端返回写入成功。
大多数支持主从复制的技术栈几乎都上面三种同步方案从数据一致性角度看同步复制半同步复制异步复制而从性能角度出发则完全相反异步复制半同步复制同步复制。
如今大多数技术栈默认的复制方案都是第三种虽然有数据丢失的风险可是它的性能最好何况“主节点写入完数据正好就发生故障”的这种几率很小。当然如果你的系统更在乎数据一致性和安全性那就可以选择半同步模式如果完全不在乎性能则可以切换成同步复制模式。 1.2.1、读写分离
在主从架构中因为从节点被阉割掉了处理写请求的能力所以在大部分时间里如果从节点只作为数据副本而存在显然会造成很大的资源浪费。为了充分利用从节点的资源一种名为“读写分离”的技术曾风靡一时。 虽然从节点没有处理写请求的能力可是它会把主节点写入的所有数据都同步过来为此它具备“一定程度”的读请求处理能力此时就可以将读取数据的请求分发给从机既能充分利用空闲资源又能减轻主节点的访问压力。 PS从节点只具备“一定程度”的读请求处理能力注意里面用引号标出的“一定程度”这啥意思 因为主从复制技术都依靠网络来同步数据而网络并不可靠也必然存在延迟性。在异步复制的模式下当一个数据写入到主节点立马出现读请求到从节点读取此时有可能读不到最新的数据。
1.2.2、故障转移
本文开篇提到的集群四大优势其中一条则是保证了高可用解决了单点故障问题可实际上部分技术栈虽然支持主从集群但却只提供了基本的主从复制功能如MySQL并不具备故障转移能力。
所谓的故障转移通常是针对主节点而言的即当主节点发生故障时集群能自动推选出新主节点并将流量自动转移到新主处理。大家熟知的MySQL它并不具备自动故障转移功能当原本设定的主节点故障后必须通过人工介入、或第三方工具如MHA又或者自己研发的组件实现故障转移。
当然也有很多技术栈官方就实现了故障转移机制比如Redis的Sentinel哨兵、MongoDB的Arbiter仲裁者、Kafka的Controller控制器……这些中间件的主从集群在主节点发生故障时都能实现无人力介入、自动转移效果。
这种自动故障转移机制它们内部是如何实现的其实原理大同小异故障转移的第一步是需要能检测出故障的节点有两种方案可选
①探测模式负责故障处理的节点每隔一段时间向集群所有节点发送探测包ping没有回复的节点说明已经故障②上报模式集群内所有节点主动向负责故障处理的节点发送存活信息心跳当一个节点没有心跳时说明陷入故障。
不过为了兼容网络分区问题通常会组合起来使用正常情况下集群节点主动发送心跳包当某个节点没有心跳后故障处理节点会主动发起探测请求如果还是没有回复则会认为该节点陷入故障。考虑到网络分区的影响故障处理节点也可能陷入了分区因此也会向其他故障处理节点发出二次确认的请求以此进一步确认对应节点是否故障。 PS上述概念类似于Redis哨兵里的主观下线、客观下线同时也不仅仅只有故障处理节点具备故障检测能力集群内的节点也拥有该能力如从节点去拉数据时也可以检测出主节点的健康状态。 如果本次检测出的故障节点是主节点则会进入新主选举流程选举一般是通过投票机制实现新主上任的前提是“节点数一半以上的票数”而投票机制的内在逻辑则是数据POS点即谁的数据更新则更有机会成为新主总体流程如下
①故障检测当感知到某个节点不可用时会先发起通信向其他可用节点进行二次确认②故障处理如果检测到主节点不可用从节点会将自己转换为候选人并向其他成员宣布③选举开始轮次号加一开启一轮新的选举每个候选人节点开始向其他成员发送拉票请求④投票开始在一个新的选举轮次中每个节点只能投一票可以投给自己或者其他节点⑤投票结束所有节点已投票或抵达本轮选举的时间限制后将获得大多数投票的节点立为新主⑥主从切换新主会向其他节点发送“上位”消息其他节点更新自己的配置接受新主上位⑦数据同步完成主从切换后从节点以新主为数据基准校验自身数据是否完整有缺失则同步。
上面只是大概流程但几乎所有技术栈实现的思路都是这样因为它们都遵循着Paxos、Raft等协议制定的标准本文对此不做展开后续会单开篇章来聊。
1.2.3、级联复制
级联复制是主从架构的变种其本质还是主从模型主要用于一主多从的结构中如 在主从架构中想要实现数据同步有两种方式
主节点推送当主节点出现数据变更时主动向自身注册的所有从节点推送新数据写入。从节点拉取从节点定期去询问一次主节点是否有数据更新有则拉取新数据写入。
但不管是哪种方式都会存在一个问题主节点同步数据的压力会随着从节点的数量呈线性增长啥意思因为不管是推还是拉数据都需要从主节点出站。
对主节点来说数据同步会对磁盘、内存、带宽、CPU带来不小压力此时多一个从节点自然多出一倍的压力数据量较大时特别容易把主节点的资源占满从而造成主节点无法处理客户端的请求级联复制的出现就是为了解决此问题。 级联复制模式中只有一个从节点B挂在主节点A下面其余的从节点都会成为B的从节点数据由B先同步到自身其余节点再从B去同步数据这样就解决前面的问题可此时又会带来新问题
数据延迟本身主从复制就存在延迟性而新加入一层后数据延迟性会更高级联节点故障负责同步主节点数据的B一旦故障会导致其余从节点无法同步数据。
凡事有利必有弊虽然级联复制能解决原本的问题可是也会带来新问题这时就需要处理新的问题或者把新问题的影响降到最低。 PS用来同步数据的Canal中间件就类似于级联复制的思想。当然除开小部分特殊的项目一般很少用到级联复制模式。 1.2.4、多主热备
虽然可以通过读写分离、级联复制减轻主节点的部分压力可对于写请求都必须得落到主节点上处理而主节点再强悍总有扛不住的时候这时又出现了变种集群双主/多主模式。
多主模式也是建立在主从复制的基础之上比如双主模式时两个节点互为主从各自都具备完整的读写能力客户端的写请求可以落入任意节点上处理。不管数据落到哪个节点另一个节点都会将数据同步过去此时客户端的读取请求在任意节点上都能读到数据。
通过这种方案可以将写入性能翻个倍并且可以继续拓展出更多的主节点组成多主集群。不过一般是双主因为大部分技术栈支持的主从集群仅允许为一个从节点配置一个主节点在这个限制下想要实现多主则只能组成环形多主集群 这种环形多主架构由于每个节点都支持写入数据所以能极大提升写入吞吐量但成也萧何败也萧何一个节点写入新数据后需要经过N次节点数量-1复制才能将数据同步给所有节点集群内的延迟性很高这也是为什么一般只搭建双主的根本原因。 PS多主集群除开能提升写入吞吐量外只要客户端略加适配就可以实现“客户端版故障转移”即客户端检测到一个节点不可用后自动切换到其他节点上读写数据。 1.3、分片架构
不管是开始提到的横向集群还是上面聊到的主从集群本质上都是“克隆”多个具备完整功能的单机节点组合部署尽管主从里的从节点功能有所阉割可整体上还是属于主节点的复制体。
对业务系统这类应用而言用多个克隆体组成集群没任何问题这也是集群概念的标准思想但对于存储型应用来说就会出现三个致命问题
木桶效应三个节点的磁盘容量为512G、1T、1T集群最大容量则为512G写入受限传统的主从集群写入的吞吐量受单个主节点限制写入的并发很难提升容量危机主从集群通过升配存储GB、TB级数据但上升到PB甚至更高量级时无力。
为了解决木桶效应必须保证集群所有节点的资源配置一致否则同步数据时存不下为了解决写入受限可以搭建另类的多主集群可这种模式数据延迟太大为了存储海量数据只能不断加硬件资源带来更大的存储空间……
主从集群有着天然的弊端虽然可以通过特殊手段环境但无法根治“先天性的劣势”这种传统型的集群方案不再适用于增长迅猛的系统无法处理高并发与海量数据存储。正因如此存储型应用在设计集群模式时做出了一个违背祖宗的决定将数据分区存储既然一台机子存不下那我就用多台机子存
1.3.1、分片式集群
分区存储就是目前大数据存储领域大名鼎鼎的分布式存储技术也叫分片式集群我们再来好好聊聊这块知识~
之前的单体模式也好主从集群也罢数据其实都是集中式存储即所有数据都存储在一起。分区存储就相当于把原本的一缸水分到不同的桶子里如下 每个分片节点都具备读写数据的能力这样就从根本上解决了写入瓶颈并且数据分散到多个节点独立存储这并不受木桶效应的影响解决了PB级数据存储造成的容量危机。
分片集群的好处很多但想要实现分片式存储首先要解决的就是数据路由问题写入时能自动根据规则落到某个分片节点存储读取时能精准找到存储的分片节点获取数据。这和前面聊的请求分发算法类似只不过数据分发时需要保证同一数据的写入/读取落入相同的节点。
数据路由到具体的分片节点有两个核心点一是分片路由算法二是分片路由键。数据分发和请求分发不同因为要保证同一数据读写都在相同节点操作光靠分发算法无法实现所以每条数据需要有个标识这个标识就是路由键以ID字段作为路由键来举例 集群有四个节点选用取模分发算法根据ID值取模节点数量计算出数据最终要落入的节点。来看实际过程假设要操作ID1这条数据
写入路由键ID取模四1%4结果为1数据落入分片节点2读取路由键ID取模四1%41从分片节点2中读取数据。
通过这种方式就保证了读写数据的节点一致避免“写入成功无法读取”的尴尬现象发生。不过除了取模分发外还有其他一些分发算法如范围分发、哈希取模、一致性哈希、哈希槽……像Redis-cluster集群中就采用CRC16算法计算KeyKey即路由键并结合哈希槽模式实现数据分发。
解决了数据分发问题后分片架构其实还存在一系列问题好比多节点的数据如何聚合等等。如果当前分片的存储组件属于关系型数据库如何兼容事务机制多表联查如何关联如何实现多字段维度查询当然其实还有一系列头疼的问题这里不做展开感兴趣可参考《分库分表副作用篇》。
经过上面的阐述后大家一定对分片式集群有了基本认知现在来聊聊分片集群的类型总体可分两种中心代理分片集群、去中心化分片集群。
1.3.2、中心化分片集群
中心化分片集群意味着集群中又存在不同的角色节点最少有两种
中心节点负责路由规则、数据节点的管理工作以及处理数据分发请求自身不存储分片数据数据节点具体存储数据的分片节点负责处理中心节点分发过来的写入/读取数据请求。
上面的中心节点就类似于之前的”负载均衡器“负责管理集群所有节点以及具体的分发工作这种模式也是早期最主流的分片集群方案即代理式分片集群。
代理式分片可以在官方不支持分片集群的情况下自己来搭建分片集群以传统关系型数据为例MySQL官方并不支持分片存储怎么办如果工作年限较长的小伙伴一定清楚之前有个大名鼎鼎的中间件叫MyCat示意图如下 尽管MySQL不支持分片架构但通过上述方案可以将一个个独立的MySQL节点组合成一个逻辑上的大整体每个独立的MySQL节点则代表着具体要存储数据的分片节点。MyCat则是负责节点管理与数据分发的中心节点所有要操作MySQL的客户端都会连接到MyCat读写请求交给MyCat做具体分发。 PS实际MyCat就是伪装成了一台MySQL业务系统依旧和往常一样连接即可屏蔽了客户端对分片集群的感知。 除开MyCat外如同类型的Sharding-Proxy又或者早期Redis的TwemProxy、Codis等等这都是代理式分片理念的产物。究其根本还是由于早期官方并不支持分片式架构因此部分业务庞大的企业迫于无奈只能在更高的维度上架设中心节点来分发数据到不同的节点中存储。
这种中心化分片集群的思想直到现在依旧在使用只不过如今很少有代理中间件基本都由官方自己实现如MongoDB分片集群依靠路由节点mongos进行数据分发。
为啥我称呼这类分片集群为“中心化分片集群”呢其实站在数据/分片节点的角度出发节点之间相互平等不存在之前主从架构里的Master概念。可是虽然没有了Master但在数据节点之上有了一种更高维度的节点所有数据节点都得“听”它安排这就是一种另类的中心化体现。
中心化分片集群有何劣势特别明显不管是第三方实现的代理中间件还是官方自身研发的“高等级节点”毕竟所有请求都需经过“中心节点”为此一旦这类节点故障必然会造成整个分片集群不可用。 中心化分片集群为了解决中心节点的单点故障问题一般都需要对中心节点做高可用建设如mongos集群式部署、MyCat做热备等等。 1.3.3、去中心化分片集群
与上阶段提到的中心化分片集群相反的则是去中心化分片集群典型的例子就是Redis3.x推出的Redis-Cluster集群这是一种完全意义上的去中心化集群所有负责读写数据的节点地位平等并且没有“中心化”的路由节点。
相反Redis-Cluster中采用了哈希槽的概念总计16384个槽位集群初始化时会平均分给每个节点负责管理支持手动设置比如现在有四个节点哈希槽的默认分配如下
A节点0~4095槽位B节点4096~8191槽位C节点8192~12287槽位D节点12288~16384槽位
类似于之前0~15这16个默认的库一样每个槽中都可以存放多个Key同时配备CRC16哈希算法最终实现数据的分发例如下述命令
set name zhuzi
则会使用CRC16算法对name这个键名进行哈希接着取模总槽数16384从而得出具体要落入的槽位。假设name对应的哈希值是185272最终落入槽位则是5047185272%16384-1即落入到B节点中存储。
既然没有中心化的路由节点那CRC16取模运算的工作谁来完成集群内的所有节点在Redis-Cluster中任意节点都具备CRC16取模的能力来看个场景 如果一个本该落入A节点的Key在set时去到了C节点那么C节点在经过CRC16计算后会不会把该Key转发到A节点去呢 答案是不会而是会向客户端会返回一个重定向错误的消息其中指示了正确的节点位置告诉客户端去连接对应节点写入数据即可。 PS实际项目中并不会把CRC16取模的工作交给Redis来做因为这样有可能会出现一次重定向通常都是客户端计算而后直连正确的节点写入数据如Java中主流的Redis客户端框架都有实现CRC16的逻辑。 好了上述便是去中心化的大体逻辑相信大家一定明白为啥叫去中心化分片集群因为不存在中心节点各个节点自身就具备数据分发计算的能力即使集群内部分节点宕机也只会影响部分数据保证了BASE理论中的基本可用思想并不会像中心化分片集群那样一旦中心节点故障就会造成分片集群不可用。 PS分库分表领域的Sharding-JDBC也是一种去中心化分片存储的体现即各个客户端具备数据分发的能力不需要依赖MyCat这类中间件实现数据路由。 相较于传统的主从集群分片式集群的维度显然更高当应对数据量级、并发规模非常大的系统时分片式集群能够利用多台机器的共同满足数据需求它能充分利用集群中每一台机器的资源实现数据读写的并行处理以及海量数据的分区存储。也正因如此早期想实现分片式存储需要自己研发中间件反观如今随着分布式各领域技术的发展分片式集群成为了新趋势官方基本都开始支持分片架构。
二、集群篇总结
OK看到这里我们一步步阐述了集群中的常用知识也对集群的形态有了全面认知但本文并没有涵盖集群的方方面面实际上不同类型的集群架构总会带来各种各样的问题而这些问题并未做展开也包括集群与云平台的结合本文也未曾说明这些就留给诸位自行去探索啦~
相信看到这里的小伙伴对集群方面的知识应该建立出了系统化、结构化的认知体系不过经常阅读我文章的小伙伴会发现本文中的很多概念在以往的文章里都有提及看起来会感觉异常熟悉为啥这就是我经常说的那句话技术学到最后都是共通的不同技术之间最后都能串起来。
不管是业务系统还是注册中心、定时任务、Redis、MQ、MySQL、ES……等各种组件在实现集群方案时底层逻辑都大差不差本文则是各种技术栈集群方面的共通知识当你在学不同技术栈的集群技术时就会发现这些技术之间的共通性。
最后也希望大家不管在学习什么技术不要只把目光集中在表层的应用闲暇之余记得看看内层的实现思想这样方能做到一通百通才能让大家真正成为技术领域的“高手”。
