背景图

分布式一致性解决瞬时态

分布式一致性在微服务中已经不是什么新概念了。分布式一致性问题也是协同问题,我们在软件开发中经常会遇到协同的问题。

协同

我在维基百科上找到协同学的说明,我们来看一下:

协同学理论(英语:Synergetics)源于现代物理学和非平衡统计物理学,是一门研究完全不同的学科中存在的共同本质特征的横断科学。它通过分类、类比,来描述各种系统和运动现象中从无序到有序转变的共同规律。协同学理论是1974年德国物理学家赫尔曼·哈肯创立,受激光理论的启发。协同学理论也可称为非平衡系统的自组织理论。

这里最重要的一句话就是非平衡系统的自组织;这种思想也是区块链里面所倡导的理论基础。也是分布式一致性理论的本质。

天下大势,分久必合,合久必分。其实我们做业务系统也是一样,当我们发起一笔业务时,多系统的数据平衡态被打乱;这时候我们需要多系统之间的自适应自组织而重新达到平衡状态。

而我们需要做得就是使我们的系统能够具有自适应自组织的能力;

瞬时态

在分布式一致性中,从平衡态->混乱态->平衡态,因为混乱态出现的时间比较短,所以我把他成为瞬时态。

对于瞬时态,我们只要做到以下几点即可:

  1. 瞬时态出现的时间应该控制,将时间缩短。
  2. 可见性的说明,这里的可见性还有另外一层意义,我们待会再说明,也就是CAP里面的分区容错性。
  3. 兼容,数据变更前后都不会有问题即可

可见性

一般来说我们在处理分布式一致性问题的时候必须考虑数据出现一致性问题时候的可见性问题,

  1. 加业务锁,客户端及时返回错误或者等待,这种不适合业务处理
  2. 状态机,临时状态展示给用户

补偿

不管是两阶段提交还是Base理论,数据最终一致性的保障都是通过补偿的方式进行的。

协同场景

其实我把分布式一致性的场景进行扩充的原因是我遇到了一个推送配置的场景,因为要同时推送多个服务,这个配置需要即时生效而且是多个服务一起生效,否则就会报错;我觉得这个也是分布式一致性的问题;因为我解决这个问题的理论思想都是来自分布式一致性的问题。而如果将其归纳到分布式一致性中也不是很合适;

对于你觉得很相似的东西,你要明白他们之间一定有共性,而我觉得这里的共性就是协同。这个问题和分布式一致性的不同是,这个地方没有数据同步问题,它只是将不同的配置推送到不同的系统,最终是配置数据的完整性而已。

对于配置的一致性,一般我们知道Paxos、raft协议等,这里配置协议与我们的配置推送的不同是,配置推送每次是新数据覆盖老数据;但是Paxos这类协议是竞争,不一定遵循新的替换旧的,而是通过版本号叠加处理而已,因为每个节点都在进行相应的处理,所以它们会不停地增加版本号将自己的值存放到存储中。

这种拆分的配置,我们的处理手段是瞬时态兼容处理;就是推送配置的时候将旧的配置和新的配置合集处理;因为多一些配置对系统的处理不产生影响。下面就是我们的决策架构图。

由于运行态一分钟拉取最新的决策,所以配置话无法通过管理态做一个协同的操作。这时候就需要推送调度系统做合集兼容;管理态发布后,定义一个定时器,至少1分钟后将最新配置重新推送一下决策调度系统即可。所以存在一分钟左右的瞬时态,这里就是合集配置兼容即可。

还有第二种方法就是使用版本号,当决策系统进行发布时,上层通过版本号调用旧的决策;当决策系统发布完成后,切换新的版本号来进行调用,这样就能实现数据的分割了。

0%