规则引擎设计与实现| 青训营笔记

82 阅读6分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 14 天。

分布式理论

分布式概述

分布式系统是计算机程序的集合,这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可分为分布式计算、分布式存储、分布式数据库等。

优势:去中心化、低成本、弹性、资源共享、可靠性高。

挑战:普遍的节点故障、不可靠的网络、异构的机器与硬件环境、安全。

Why-How-What

使用者:

  • Why:数据爆炸,对存储和计算有大规模运用的诉求;成本低,构建在廉价服务器之上。
  • How:分布式框架;成熟的分布式系统。
  • What:理清规模,负载,一致性要求等;明确稳定性要求,制定技术方案。

学习者:

  • Why:后端开发必备技能;帮助理解后台服务器之间协作的机理。
  • How:掌握分布式理论、了解一致性协议。
  • What:把要点深入展开,针对难点搜索互联网资料进行学习;把所学知识运用于实践。

常见的分布式系统

分布式存储:GFS、Ceph、Hadoop HDFS、Zookeeper。

分布式数据库:Google Spanner、TiDB、HBase、MongoDB。

分布式计算:Hadoop、Spark、YARN。

系统模型

故障模型

  • Byzantine failure:节点可以任意篡改发送给其他节点的数据。
  • Authentication detectable byzantine failure(ADB):Byzantine failure的特例;节点可以篡改数据,但不能伪造其他节点的数据。
  • Performance failure:节点未在特定时间段内收到数据,即时间太早或太晚。
  • Omission failure:节点收到数据的时间无限晚,即收不到数据。
  • Crash failure:在omission failure的基础上,增加了节点停止响应的假设,也即持续性地omission failure。
  • Failure-stop failure:在Crash failure的基础上增加了错误可检测的假设。

image.png

理论基础

CAP理论

CAP理论往往运用于数据库领域,同样可以用于分布式存储方向。

  • C(Consistence):一致性
  • A(Availability):可用性
  • P(Networking partitioning):分区容错性
  • CA:放弃分区容错性,加强一致性和可用性,就是传统的单机数据库的选择。
  • AP:放弃一致性(强一致性),追求分区容错性和可用性,例如一些注重用户体验的系统。
  • CP:放弃可用性,追求一致性和分区容错性,例如与钱财安全相关的系统。

image.png

在网络发生分区的情况下,我们要在可用性和一致性间做出选择,近似解决办法:把故障节点的负载转移给备用节点负责。

image.png

ACID理论

事务是数据库系统中非常重要的概念,他是数据库管理系统执行过程中的一个逻辑单元,他能保证一个事务中的所有操作要么全部执行,要么全都不执行。数据库事务拥有四个特性ACID,分别是原子性(Atomicity)、一致性(Isolation)、和持久性(Durability)。

BASE理论

Base理论是对CAP中一致性和可用性权衡的结果,其来源于对大型互联网分布式实践的总结,是基于CAP定理逐步演化而来的。其核心思想是:Basically Available(基本可用)、Soft State(软状态)、Eventually consistent(最终一致性)。

分布式事务

二阶段提交

为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。

三个假设:

  • 引入协调者和参与者,互相进行网络通信。
  • 所有节点都采用预写式日志,且日志被写入后即被保持在可靠的存储设备上。
  • 所有节点不会永久性损坏,即使损坏后仍可以恢复。

image.png

可能出现的情况:

  • Coordinator不宕机,Participant宕机。需进行回滚。
  • Coordinator宕机,Participant宕机。可以起新的协调者,待查询状态后,重复二阶段提交。
  • Coordinator宕机,Participant宕机。无法确认状态,需要数据库管理员的介入,防止数据库进入一个不一致的状态。

回滚:在Prepare阶段,如果某个事务参与者反馈失败消息,说明该节点的本地事务执行不成功,必须回滚。

image.png

需注意:

  • 性能问题:两阶段提交需要多次节点间的网络通信,耗时过大,资源需要进行锁定,徒增资源等待时间。
  • 协调者单点故障问题:如果事务协调者节点宕机,需要另起新的协调者。否则参与者处于中间状态无法完成事务。
  • 网络分区带来的数据不一致:一部分参与者收到了Commit消息,另一部分参与者没收到Commit消息,会导致了节点之间数据不一致。

三阶段提交

将两阶段提交中的prepare阶段,拆成两个部分:CanCommit和PreCommit机制。解决了单点故障和阻塞问题。另外引入超时机制,在等待超时之后,会继续进行事务的提交。但是仍未解决两阶段中性能问题和网络分区场景带来的数据一致性问题。

image.png

MVCC

MVCC是一种并发控制的方法,维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写,也不阻塞读。MVCC为每个修改保存一个版本,和事务的时间戳相关联。可以提高并发性能,解决脏读的问题。

悲观锁:操作数据时直接把数据锁住,直到操作完成后才会释放锁;上锁期间其他人不能修改数据。

乐观锁:不会上锁,只是在执行更新时判断别人是否修改数据,只有冲突时才放弃操作。

共识协议

Quorum NWR模型

N:在分布式存储系统中,有多少份备份数据

W:代表一次成功的更新操作要求至少有w份数据写入成功

R:代表一次成功的读数据操作要求至少有R份数据成功读取

为了保证强一致性,需要保证W+R>N。

RAFT协议

Raft协议是一种分布式一致性算法(共识算法),即使出现部分节点故障,网络延时等情况,也不影响各节点,进而提高系统的整体可用性。Raft是使用较为广泛的分布式协议。一定意义上讲,Raft也使用了Quorum机制。

Paxos协议

Paxos算法与RAFT的算法区别:

  • Multi-Paxos可以并发修改日志,而Raft写日志操作必须是连续的。
  • Multi-Paxos可以随机选主,不必最新最全的节点当选Leader。

优势:写入并发性能高,所有节点都能写入。

劣势:没有一个节点有完整的最新的数据,恢复流程复杂,需要同步历史记录。

分布式实践

MapReduce

Mapper:将输入分解为多个job来并行处理,彼此之间几乎没有依赖关系。

Shuffler:将mapper结果打乱,防止数据倾斜。

Reducer:将map阶段的结果进行全局汇总。

分布式KV

  • 架构:将海量结构化数据根据key分成不同的Region,每个Region构建一个单机KV数据库,Region之间形成Raft Groups,做到强一致。
  • 容错:当Node故障时,通过Raft Learner模式进行数据修复。
  • 弹性:当出现局部Key热点或数据膨胀时,Region可以进行Split操作分成两个子Region,反之收缩时进行Merge操作。

思维导图

image.png