分布式 – try66

分布式一致性算法：Raft

分布式系统的一致性算法就是指一组机器协同工作，即便其中有某些机器宕机了，系统还能正常对外提供服务。以前通常都喜欢用Paxos来讲解一致性算法，但是Paxos本身很复杂，代码实现也很难，于是催生了Raft这个更加简单易懂的一致性算法，难得的是，它的效果跟Paxos差不多。为了易于理解，Raft采用了算法分解(分为leader选举，日志复制以及安全性)和减少状态的方式。与以往一致性算法不同的是，Raft有一些特别的地方：强Leader。Raft使用了一个强Leader特性，日志复制只能从Leader节点复制到其他节点。 Leader选举。Raft使用了一个随机超时来选举Leader，以确保选举不会失败。成员变化。Raft使用了联合一致性方法来实现成员配置变化时保证服务不受影响。 1. Raft 节点状态在分布式系统上，每台服务器相当于一个分布式网络节点，每个节点有三种状态：Follower，Candidate，Leader，状态之间是互相转换的，可以参考下图，具体的后面说。每个节点上都有一个倒计时器 (Election Timeout)，时间随机在 150ms 到 300ms 之间。有几种情况会重设 Timeout：收到选举的请求收到 Leader 的 Heartbeat (后面会讲到) 在 Raft 运行过程中，最主要进行两个活动：选主 Leader Election 复制日志 Log Replication 2. 选主 Leader Election 2.1 正常情况下选主假设现在有如图5个节点，5个节点一开始的状态都是 Follower。在一个节点倒计时结束 (Timeout) 后，这个节点的状态变成 Candidate 开始选举，它给其他几个节点发送选举请求 (RequestVote) 其他四个节点都返回成功，这个节点的状态由 Candidate 变成了 Leader，并在每个一小段时间后，就给所有的 Follower 发送一个 Heartbeat 以保持所有节点的状态，Follower 收到… Continue reading 分布式一致性算法：Raft

分布式事务，这一篇就够了

[作者简介] 李文华，小米信息技术部海外商城组随着互联网技术的不断发展，系统越来越复杂，几乎所有 IT 公司的系统都已经完成从单体架构到分布式架构的转变，分布式系统几乎无处不在。谈到分布式系统，特别是微服务架构，我们不得不谈分布式事务。今天就跟大家一起聊聊分布式事务以及常用解决方案。基础理论在讲解具体方案之前，我们有必要了解一些分布式事务所涉及到的基础理论知识。事务事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。事务应该具有 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 特性。分布式事务分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。例如在大型电商系统中，下单接口通常会扣减库存、减去优惠、生成订单 id, 而订单服务与库存、优惠、订单 id 都是不同的服务，下单接口的成功与否，不仅取决于本地的 db 操作，而且依赖第三方系统的结果，这时候分布式事务就保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。强一致性、弱一致性、最终一致性强一致性任何一次读都能读到某个数据的最近一次写的数据。系统中的所有进程，看到的操作顺序，都和全局时钟下的顺序一致。简言之，在任意时刻，所有节点中的数据是一样的。弱一致性数据更新后，如果能容忍后续的访问只能访问到部分或者全部访问不到，则是弱一致性。最终一致性不保证在任意时刻任意节点上的同一份数据都是相同的，但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。简单说，就是在一段时间后，节点间的数据会最终达到一致状态。 CAP 原则 CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择。 CAP 原则的精髓就是要么 AP，要么 CP，要么 AC，但是不存在 CAP。如果在某个分布式系统中数据无副本，那么系统必然满足强一致性条件，因为只有独一数据，不会出现数据不一致的情况，此时 C… Continue reading 分布式事务，这一篇就够了

分布式事务最经典的七种解决方案

随着业务的快速发展、业务复杂度越来越高，几乎每个公司的系统都会从单体走向分布式，特别是转向微服务架构。随之而来就必然遇到分布式事务这个难题，这篇文章总结了分布式事务最经典的解决方案，分享给大家。基础理论在讲解具体方案之前，我们先了解一下分布式事务所涉及到的基础理论知识。我们拿转账作为例子，A需要转100元给B，那么需要给A的余额-100元，给B的余额+100元，整个转账要保证，A-100和B+100同时成功，或者同时失败。看看在各种场景下，是如何解决这个问题的。事务把多条语句作为一个整体进行操作的功能，被称为数据库事务。数据库事务可以确保该事务范围内的所有操作都可以全部成功或者全部失败。事务具有 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 特性。 Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。 Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。完整性包括外键约束、应用定义的等约束不会被破坏。 Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。 Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。分布式事务银行跨行转账业务是一个典型分布式事务场景，假设A需要跨行转账给B，那么就涉及两个银行的数据，无法通过一个数据库的本地事务保证转账的ACID，只能够通过分布式事务来解决。分布式事务就是指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。在上述转账的业务中，用户A-100操作和用户B+100操作不是位于同一个节点上。本质上来说，分布式事务就是为了保证在分布式场景下，数据操作的正确执行。分布式事务在分布式环境下，为了满足可用性、性能与降级服务的需要，降低一致性与隔离性的要求，一方面遵循 BASE 理论（BASE相关理论，涉及内容非常多，感兴趣的同学，可以参考BASE理论）：基本业务可用性（Basic Availability）柔性状态（Soft state）最终一致性（Eventual consistency）同样的，分布式事务也部分遵循 ACID 规范：原子性：严格遵循一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽持久性：严格遵循分布式事务的解决方案两阶段提交/XA XA是由X/Open组织提出的分布式事务的规范，XA规范主要定义了(全局)事务管理器(TM)和(局部)资源管理器(RM)之间的接口。本地的数据库如mysql在XA中扮演的是RM角色 XA一共分为两阶段：第一阶段（prepare）：即所有的参与者RM准备执行事务并锁住需要的资源。参与者ready时，向TM报告已准备就绪。第二阶段 (commit/rollback)：当事务管理者(TM)确认所有参与者(RM)都ready后，向所有参与者发送commit命令。目前主流的数据库基本都支持XA事务，包括mysql、oracle、sqlserver、postgre XA 事务由一个或多个资源管理器（RM）、一个事务管理器（TM）和一个应用程序（ApplicationProgram）组成。把上面的转账作为例子，一个成功完成的XA事务时序图如下：如果有任何一个参与者prepare失败，那么TM会通知所有完成prepare的参与者进行回滚。 XA事务的特点是：简单易理解，开发较容易对资源进行了长时间的锁定，并发度低如果读者想要进一步研究XA，go语言可参考DTM，java语言可参考seata SAGA Saga是这一篇数据库论文saga提到的一个方案。其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。把上面的转账作为例子，一个成功完成的SAGA事务时序图如下： SAGA事务的特点：并发度高，不用像XA事务那样长期锁定资源… Continue reading 分布式事务最经典的七种解决方案

浅谈分布式系统一致性之3PC协议

一.写在前面分布式系统一致性专题本期该写 3PC 协议了，上周太忙没有时间更新，就拿了之前的旧文章做了一些调整重发了一下，还望各位读者海涵。后面大约还有3期：Paxos 协议、Raft 协议等，先预热一下。温馨提示：本篇文章并不会枯燥，换了个画图工具，对于我这种建筑专业出身的IT狗来说，画图简直是最开心的事情了，所以放心看吧！图(网络)|猎户座大星云二.3PC的出现之前文章中提到了 2PC 协议存在的协调者单点、参与者阻塞超时、网络分区、容错性等问题，这些在某些程度上是做优化和调整的，并不是致命问题。我们对 2PC 协议的异常情况做了拆解，但是那是个m*n的组合问题，我们尽量去分析主要矛盾，于是发现在协调者和唯一接收指令的参与者都出现不可恢复宕机时，即使后面选举了新的协调者，仍然可能出现数据的不一致性。 3PC 的出现可能是多种因素促成的。但是基本上可以确定 3PC 将对 2PC 存在的问题进行修正和优化，但是这样并不意味着 3PC 不会引入新的问题。本文将从 3PC 的协议过程来阐述这两大块内容: 三. 3PC协议的基本过程 3PC协议 Three-Phase-Commit 又称三阶段提交协议，相比 2PC 协议增加了一个阶段，因此我们普遍把 3PC 协议看作是 2PC 协议的改进版本。 3PC 协议将 2PC 协议的准备阶段一分为二，从而形成了三个阶段：协调者和参与者等待超时情况单独说，先看正常情况的基本过程，要不然容易混淆。 3.1 CanCommit阶段在2PC准备阶段中，协调者向参与者发送指令后，参与者如果具备执行条件，则获取锁并执行动作，只不过未真正提交，可以认为参与者就差临门一脚了，还得等协调者信号。如果是 commit 信号那还好，如果是 rollback 信号，那么对于一些本地执行了动作的参与者来说白白浪费了，所以从这个角度来说，2PC 有点激进了，但是这么做也是有原因的，在复杂的网络环境中多一轮交互意味着性能的损耗。 3PC来说更加合理，先由协调者向参与者发送询问信号，兄弟们有档期吗？？然后开始收集反馈，相比来说更加轻量。这个阶段参与者并不真实获取锁占用资源，只是对自身执行事务状态的检查，查看是否具备执行事务的条件，进而回复询问。… Continue reading 浅谈分布式系统一致性之3PC协议