营销型网站建设主要需要注意什么,免备案云服务器租用,wordpress怎样设置导航栏,wordpress在线计算程序本文讲解4.6版jxTMS中数据采集系统的高可用性#xff0c;整个系列的文章请查看#xff1a;4.6版升级内容
docker版本的使用#xff0c;请查看#xff1a;docker版jxTMS使用指南
4.0版jxTMS的说明#xff0c;请查看#xff1a;4.0版升级内容
4.2版jxTMS的说明#xff…本文讲解4.6版jxTMS中数据采集系统的高可用性整个系列的文章请查看4.6版升级内容
docker版本的使用请查看docker版jxTMS使用指南
4.0版jxTMS的说明请查看4.0版升级内容
4.2版jxTMS的说明请查看4.2版升级内容
4.4版jxTMS的说明请查看4.4版升级内容
standalone构型转为了分布式构型就自然而然的会出现一个高可用性的问题。传统上高可用性有三种即所谓的负载均衡、双机热备、双机冷备。
但这三者的概念以今天的技术水平来看都很过时了所以笔者作了自己的修正分布式系统、在线热备、在线冷备。
三者的共性都是通过增加冗余的备份机以在某台正在提供服务的服务器失效后能自动的由备份机接管服务最大化的减少服务中断时间、尽可能的提高服务的可用性。
三者的区别是
1、分布式系统所有机器同时工作无分主次
优点是所有服务器同时提供服务浪费率低抗冲击性好服务宕机时影响面小理论上的故障间隔最小。
缺点是系统需要专门的调度管理将服务请求较平均的分散到所有服务器上这就需要复杂的服务跟踪、管理与调度建设成本会高很多。此外提供的最好是无状态服务这样就不需要考虑服务交接时的复杂性来。
但这样的要求对业务的限制太多、效率太低而如果提供有状态的服务那就需要采取多种技术手段来确保状态的维持如基于状态/连接的服务分发、采用高速缓存、服务事务化等等。
总的来说分布式的优缺点都比较鲜明需要针对应用的特点进行细致的调教一般都是高投入的专用系统不太适合jxTMS所期望的低成本、通用性与开箱即用的要求。
2、在线热备分为主机与备份机主机工作备份机不工作在主机故障时备份机可直接接管服务
3、在线冷备分为主机与备份机主机工作备份机不工作在主机故障时备份机丢弃现有服务请求后接管服务
可以看出热备与冷备的区别在于对待正在处理服务请求的响应机制热备需要从机保持切换前的主机服务状态冷备则直接丢弃主机的服务状态从零开始提供服务。
热备可以用高速缓存甚至数据库来实现但其缺点和分布式是一样的阶段性的中间数据全部要放入缓存以实现服务的事务化性能影响较大而且服务编写较为复杂【自然成本就高】。
冷备则非常简单明确所提供的服务存在失效的可能这样在请求方请求服务超时或返回无效请求后再次请求即可即用会话的复杂性来对冲服务的可靠性承诺。
想实现完美的带状态接管必须使用持久化的高速缓存完整记录服务请求、服务状态并将服务事务化以及服务的请求异步化这都会导致成本高、性能低且应用编写繁琐。
综上我们可以用两个公式来概括这三者的关系
在线热备 在线冷备 服务事务化基础上的状态同步
分布式 在线热备 服务管控与调度相比来说在线冷备实现起来简便、可靠、坚固适用面广、技术门槛低、系统开销也小的多。缺点就是服务存在失效的可能所以需要将服务请求会话化即保留服务请求的现场检查服务请求的执行结果当请求失败后重新发起服务请求或进行容错处理。但相对复杂的服务状态同步来说会话管理的技术难度与实现成本都非常低。
考虑到这一点所以jxTMS依托catalogService实现的就是在线冷备方案。
但docker版jxTMS所展示的数据采集与处理系统却自然而然的成了在线热备。这是基于如下两点
1、数据采集是天然的无状态。即本次所接收到的数据和之前接收到的历史数据无关
2、前面强调过多次的通过数据总线将数据采集与数据应用切分开来。所以哪怕数据应用的部分是有状态的但因为是和采集部分隔离的所以不会影响到数据采集与处理的无状态性
注数据采集系统的热备并不意味着主机故障到从机接管之间的数据不会丢失。但由于目前jxTMS的数据采集主要通过mqtt推送而mqtt也是具备数据保持能力甚至数据持久能力的如果调整这方面的配合以及优化服务保活间隔的设置是可以实现最小化的数据丢失率的。甚至理论上是可以以部分性能的损失为代价实现0数据丢失的服务接管能力
在线热备的关键性支撑
1、服务的状态检测
catalogService提供了保活机制即各服务必须先注册注册成功后必须以可自定义的间隔向catalogService发送keeplive消息。
当超过三次未收到当前已注册的服务的keeplive消息catalogService即认为该服务已经失联就会将其从目录中删除掉其它服务就可以再次注册了。
2、一致性保证
主机宕机从机接管中间出现数据丢失是可以接受的【取决于业务需要与零丢失所需成本之间的平衡】但系统必须保证主从的一致性。即从机的行为不能与主机行为不一样。
而影响主从一致性的是三个方面 代码的一致性这是通过代码管理、版本管理来实现的不在本文讨论范围之内 配置的一致性以前的docker版jxTMS主要采用本地文件的配置方式这时想要保持配置的一致性只要保证两服务器上的配置文件一致即可。但目前已经将配置逐步迁移到基于数据总线所以配置一致性的保持就较为复杂了【需要考虑前文所提到的水平切片、单服务器上运行多种服务等等】但由于笔者目前也没有太复杂的应用场景所以目前这一部分比较简单并没有对请求方以及请求参数做任何的识别与处理 管理命令执行结果的一致性以前的docker版jxTMS主要通过服务来进行管理但我们正在讨论的在线备份方案中从机根本就没有注册到系统中来所以管理命令或者迁移到基于数据总线来做或者还是通过服务发送给主机来执行但在主机执行完毕后需要通过数据总线广播给从机进行同步。笔者更倾向于后者
注1目前的数据总线中已经实现了缓存功能所以管理命令执行结果的一致性可通过主机执行完管理命令后刷新相应的缓存即可实现。即管理命令的执行结果需要存放到数据库中或基于数据总线上的缓存中这就自动实现了主从在一致性方面的实时同步
注2这里只讲了系统层面的一致性还有应用层面各功能模块的一致性【本质上其实就是工作数据的同步】。而各功能模块的一致性保证本质上就是热备与冷备的区别所以其基本原则是如果应用层面的一致性难以保证那就应以冷备模式工作
3、检测到主机失联后从机立即接管服务
当主机所注册的服务因为超时没有keeplive而被catalogService从目录中被删除掉后以同样间隔持续向catalogService进行注册的从机再次注册时catalogService就会批准本次注册然后从机会接收到注册通过的响应就可以执行接管服务的准备动作了。
服务接管
从机的服务接管主要包括两部分内容
1、主机失联后会取消对服务地址的监听而从机在接管服务后会向消息系统注册对服务地址的监听
每个服务都有一个服务监听地址{服务类型}.{服务名}。已经完成注册的主机会监听该地址一方面通过消息系统为客户提供服务另一方面则是通过该地址接受jxTMS主系统发出的管理命令。
2、执行所有受主从切换影响的模块注册的模块相关的服务开关命令
有的功能模块不受主从切换的影响始终处于就绪待命状态如用户授权、设备等模块有的模块则受主从切换的影响如mqtt模块只有主机才能从mqtt服务器订阅主题接收数据从机则不能订阅【包括主机失去和MQ的连接但没有失去到mqtt的连接这种极端情况当出现这种情况时会切换到从机应取消订阅】又如site站点模块从机是不会接收数据的所以必须停止通过钉钉发送站点失联告警。
这些会受到主从切换影响的模块在启动时需要注册两个事件通知注册到catalogService、和catalogService失联。我们以mqtt模块来举例说明其相应的代码是
#__init__函数中
#允许订阅有两种情况没有启动服务以及启动服务并注册到了服务中
self._permit False
mainService.registerConnectDual(self._name, self.permit, self.refuse, informDualself._checkServiceState)#下面是三个事件响应函数与状态通知函数#服务是否启动
def _checkServiceState(self, state):if not state:#服务没有启动需要允许连接self.permit()#注册到catalogService
def permit(self):self._permit Trueif self._connectted:for topic in self._mqttServerTopic:self._subscribe(topic)#和catalogService失联
def refuse(self):self._permit Falseif self._connectted:for topic in self._mqttServerTopic:jxGo.log(info, fmqttClient[{self._name}] unsubscribe topic[{topic}])self._client.unsubscribe(topic)上述代码已经非常直白了所以我们介绍一下mainService模块中的registerConnectDual函数、
registerConnectDual(cls, connectDual, disconnectDual, delaySeconds5, informDualNone)
注册主服务的连接与失联事件响应函数
参数connectDual注册到catalogService的事件响应函数无参disconnectDual和catalogService失联的事件响应函数无参delaySeconds延时多少秒后通知是否启动了服务informDual服务状态通知函数delaySeconds秒被调用
返回值无
说明informDual的签名是informDual(state)state--服务是否启动True启动False未启动设置informDual函数的原因在于所有的功能模块如mqtt都必须在服务启动前完成初始化工作。这是由于jxTMS的服务会启动一个无限循环来实现注册与保活。
所以呢所有的功能模块在初始化时都是不知道是否启动了服务的。启动了服务自然会通过connectDual来切换到工作状态但如果没有启动服务又需要切换到工作状态才是而这就需要informDual通过延时进行检测并发出通知了。
注意
本文所讲述的在线备份属于系统部分失效后的抢救性措施。而在线备份能否抢救成功关键是主从的一致性保证。而热备所要求的严格一致需要的成本太高只适合特定应用场景下的、高投入的自用系统。
jxTMS首先考虑的是低成本下的通用性是以低的建设成本、低的开发成本、低的维护成本来快速构建自己的应用系统所以提供的是简单、可靠、坚固的在线冷备模式只有天然无状态的如数据采集与处理系统可工作于在线热备模式。
参考资料
jxTMS设计思想
jxTMS编程手册
下面的系列文章讲述了如何用jxTMS开发一个实用的业务功能
如何用jxTMS开发一个功能
下面的系列文章讲述了jxTMS的一些基本开发能力
jxTMS的HelloWorld
