基于组播实现多活架构的技术论证
基于组播实现多活架构的技术论证常见架构
架构分类
https://i-blog.csdnimg.cn/direct/cafa8f819acc48cfafb610d098ac41d0.jpeg#pic_center
从处理惩罚同一个任务列表的角度来归类系统架构，针对一下 10 个待处理惩罚的任务，不同架构处理惩罚的内容是不一样的：A1、A2、A3、A4、A5、B1、B2、B3、B4、B5
单体
一个进程 处理惩罚全部任务：A1、A2、A3、A4、A5、B1、B2、B3、B4、B5
主备
一个主节点进程 处理惩罚全部任务：A1、A2、A3、A4、A5、B1、B2、B3、B4、B5，同时将每一个的任务结果抄送备机，抄送完成才响应给调用方
负载
单进程处理惩罚太慢，根据负载策略路由到多个进程分别处理惩罚， 各进程分别选择一部分任务处理惩罚。这里的负载策略不通过数据路由。例如两个进程 A 进程处理惩罚 A1、A2、A3、B1、B2、B3；B 进程处理惩罚 A4、A5、B4、B5
分片
单进程处理惩罚太慢，根据负载策略路由到多个进程分别处理惩罚， 各进程分别选择一部分任务处理惩罚。这里的负载策略固定通过任务内容进行负载。例如两个进程 A 进程处理惩罚 A1、A2、A3、A4、A5；B 进程处理惩罚 B1、B2、B3、B4、B5
多活
多进程处理惩罚相同任务、有一个完成即可，AB 两进程分别处理惩罚：A1、A2、A3、A4、A5、B1、B2、B3、B4、B5
架构优劣
架构上风劣势单体开辟简单，摆设轻易 数据一致性和事务管理简单单点故障风险较高 整个系统宕机风险较大主备提供高可用性和容错本领、故障恢复快速仅有一台主节点处于活跃状态，资源利用率较低、主备之间需要进行数据同步，大概存在数据一致性问题、主备切换时大概会有一段时间的服务停止负载进步系统的性能和可伸缩性、平衡哀求分发，制止单个节点负载过高负载平衡器大概成为系统的单点故障、需要办理会话保持和一致性问题、需要额外的负载平衡器，增加了系统的复杂性和本钱分片进步系统的存储容量和吞吐量、分散处理惩罚，降低了单个节点的负载数据一致性和分片路由比较复、分片键的选择和数据迁移需要审慎、需要办理跨分片事务、一致性和数据查询的问题 杂多活进步系统的容错性和可用性、各节点之间实时同步数据，确保数据一致性数据同步和一致性管理复、需要办理分布式锁、并发控制和数据去重等问题杂 多活架构特征
特征一
https://i-blog.csdnimg.cn/direct/79a46466107b4b24912c7aca8cabf186.jpeg#pic_center
在传统确定性编程的条件下从多活的征象上看，只需要保证两个进程代码一致的情况下，收到相同的顺序的消息，内部处理惩罚顺序和规则一致的情况下必然输出同样的结果，唯一的差异是输出结果的先后循序不一致大概说是要保证最终一致性。（这里把本地加载缓存之类的动作也归结为收到相同顺序的消息）
“确定性编程”（Deterministic Programming）和"不确定性编程"（Non-deterministic Programming）是在软件工程和计算机科学领域中使用的术语，用于描述步调的行为特征
[*] 确定性编程
[*]确定性编程是指步调在相同的输入和环境条件下，每次执行都会产生相同的输出结果。
[*]步调的执行过程是可猜测的，不会因为随机变乱或并发操作而产生不同的结果
[*]典范的确定性编程范式包括函数式编程、下令式编程和逻辑编程等。在这些范式中，步调的行为由步调员明确界说，而且执行过程中不受外部环境影响
特征一要求
[*] 同类服务多进程之间代码一致
[*] 多进程加载缓存（上场数据）要一致
[*] 多进程收到的消息和收到消息的顺序要一致
[*] 多进程收到消息后处理惩罚顺序要一致
特征二
https://i-blog.csdnimg.cn/direct/f77ae31e4d924bd98ab335d45e8553d7.jpeg#pic_center
以交易多活集群调用风控多活集群的例子，假设风控 B 进程处于故障状态，则对风控 B 节点的功能是要有所限制的（好比只能继承消息但是不能处理惩罚消息）。大概说在风控 B 节点故障恢复是要根据某种状态管理的规则进行。
特征二要求
[*]某进程异常状态要保证业务处理惩罚不受影响
特征三
https://i-blog.csdnimg.cn/direct/5d39236a892646699f65528b64614e75.png#pic_center
[*]网关发下一单
[*]两个交易分别接收到一笔
[*]两个交易节点分别向风控集群发一个消息
[*]两个风控节点分别收到两条消息
[*]两个风控节点都处理惩罚第一条消息、忽略第二条消息
[*]两个风控节点向交易集群发送一条消息
[*]两个交易节点分别收到两个来自风控的消息
[*]两个交易节点都处理惩罚风控的第一条消息、忽略第二条消息
[*]两个交易节点向网关集群发送一条消息
[*]网关收到两条来自交易消息
[*]网关处理惩罚第一条消息、忽略第二条消息
特征三要求
[*]多活系统内部需要具备去重的本领
[*]对接边界系统需要思量去重
[*]上游指定消息重发需要具备幂等的本领
幂等与去重不是完全等价的概念请阅读《幂等与去重的区别》
多活技术难点
针对多活系统的特征和要求，我们分析出实现多活架构必须攻克以下技术难点：
[*] 有序可靠的通讯机制
[*] 状态管理机制
内存化有状态处理惩罚是提升多活系统的性能问题的有效手段。多活系统的不同进程间处理惩罚消息的顺序要保证一致
[*]消息顺序处理惩罚机制
有序可靠的通讯
在多活架构设计下，以交易发送给风控多个节点同样的消息来说，有序可靠通讯机制可以以为是一套有序可靠组播机制。关于有序可靠组播我们通过有序和可靠两个关键点进行论证。
有序的要求
按照这个场景为例讨论我们需要支持哪些情况下的有序
交易发送：A、B、C
指令发送：1、2、3
风控 1 和风控 2 进行消费消息
从全局视角
T1 时间 交易发送 A、B
T2 时间 指令发送 1、2、3
T3 时间 交易发送 C
时间交易指令T1A、BT21、2、3T3C 基于这个发送消息的顺序，起首看存在多个生产者多个消费者的情况下现实发送消息的时间业务上大概需要保证的有序征象
情况一：多消费者顺序一致
风控 1：收到的顺序是 1、2、A、B、C、3
风控 2：收到的顺序是 1、2、A、B、C、3
一旦无法保证这个多活架构设计就完全不成立
情况二：针对单一生产者生产顺序与消费者接收顺序一致
风控 1：收到交易消息 顺序是 A、B、C；收到交易消息 顺序是 1、2、3；
风控 2：收到交易消息 顺序是 A、B、C；收到交易消息 顺序是 1、2、3；
这个的业务征象好比先充值后再进行消费，要优先处理惩罚充值在处理惩罚消费
页:
[1]