吃透Java

本专栏详细介绍分布式系统架构，分为理论篇+实践篇！理论篇主要包括：分布式架构一致性，分布式事物，高可用，高性能，高扩展等展开。实践主要包括：Spring Cloud方案，Dubbo服务治理，Redis集群，分布式锁，Kafka，Zookeeper，mq等方案。预计文章将会达到六七十篇！一，理论篇分布式一致性分布式系统架构系列讲解（分布式一致性 1）：CAP理论分布式系统架构系列讲解（分布式一致性 2）：BASE理论分布式事物分布式系统架构系列讲解（分布式事物 1）：2PC分布式系统架构系

ZAB协议，全称 Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。它是专门为分布式协调服务——Zookeeper，设计的一种支持崩溃恢复和原子广播的协议。从设计上看，ZAB协议和 Raft 很类似。ZooKeeper集群中，只有一个Leader节点，其余均为Follower节点。整个ZAB协议一共定义了三个阶段：发现（Discovery）、同步（Synchronization）、广播（Broadcast）。三个阶段执行完为一个周期，在Zookeeper集群的整个

谈起比特币，大家至少都应该有所耳闻吧？比特币是基于区块链实现的，而区块链运行在Internet上，这就存在有人试图作恶的情况。前面几章，我提到的口信消息解决方案和PBFT算法，虽然能防止坏人作恶，但只能防止少数，也就是 (n-1)/3 个坏人 (其中 n 为节点数)。可由于很多区块链是在公网环境，可能有坏人不断增加节点数，轻松突破 (n - 1) / 3 的限制。解决上述问题的方法就是PoW算法。PoW算法通过工作量证明（Proof of Work）增加了坏人作恶的成本，以此防止坏人作恶。本章，我就来讲

Leslie Lamport在论文中提出的口信消息解决方案就属于BFT，需要考虑恶意节点的篡改、攻击等问题。但是，口信消息解决方案在现实场景中很难落地。比如，它并不关心这个共识的结果是什么，这会出现一种情况：现在适合进攻，但将军们达成的共识却是撤退。另外，实际场景中，我们往往需要就提议的一系列值（而不是单值）在拜占庭错误发生的时候，也能被达成共识。那应该怎么做呢？一种方案就是本文要讲解的PBFT算法。PBFT算法，是一种能在实际场景中落地的BFT算法，它在区块链中应用广泛。一、oral message的

CAP理论中的一致性一般指的是强一致性，也就是说写操作完成后，任何后续访问都能读到更新后的值。而BASE理论中的一致性指的是最终一致性，也就是说写操作完成后， 任何后续访问可能会读到旧数据，但是整个分布式系统的数据最终会达到一致。那么，如果我们的系统现在是最终一致性模型，也就是AP模型，突然有一天因为业务需要，要临时保证节点间的数据强一致性，有没有办法临时做这样的改造呢？一种办法是重新开发一套系统，但显然成本太高了。另一种办法就是本章要介绍的Quorum NWR算法。通过 Quorum NWR，我们可以

Gossip 协议，顾名思义，就像流言蜚语一样，利用一种随机、带有传染性的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。根据 Base 理论，如果你需要实现最终一致性，那么就可以通过 Gossip 协议实现这个目标。Gossip协议的核心一共是三块内容：直接邮寄（Direct Mail）、反熵（Anti-entropy）和谣言传播（Rumor mongering）。一、直接邮寄（Direct Mail）所谓直接邮寄，就是直接发送更新数据，当数据发送失败时，将数据缓存下来

Raft算法在理解和实现上都要比Paxos容易得多，也是现在分布式系统开发首选的共识算法，掌握Raft算法，可以得心应手地处理绝大部分场景的容错和一致性需求，比如分布式配置系统、分布式 NoSQL 存储等等。一、角色Raft 算法是通过”一切以领导者为准“的方式，实现一系列值的共识和各节点日志的一致。Raft算法的核心就是通过 选举 来达成一致性，该算法一共涉及三种角色（状态）、两大过程（Leader Election、Log Replication）。我们先来看下Raft算法涉及的角色，在Raft算

Paxos算法是一种基于消息传递的，解决分布式系统共识问题的经典算法， 当前最常用的一批共识算法都是基于它改进的。比如，Fast Paxos 算法、Cheap Paxos 算法、Raft 算法等等。Paxos算法最初由Leslie Lamport提出，但是他在论文《Paxos Made Simple》(https://www.microsoft.com/en-us/research/uploads/prod/2016/12/paxos-simple-Copy.pdf)中并没有用任何数学语言对Paxos算法

共识问题是分布式领域最复杂的一个容错模型，只有搞懂它，你才能掌握常用的各种共识算法，才能在设计分布式系统时，根据业务场景的特点选择适合的算法。那么，什么是共识问题呢？简单的讲，共识问题就是分布式系统需要解决的一个核心问题：在一个可能发生机器宕机、网络异常、数据篡改的环境下，如何让分布式系统中的所有节点快速准确的对某个数据值达成一致，且不会破坏整个系统的一致性。Leslie Lamport曾在论文《 The Byzantine Generals Problem》（https://www.microsof

一，为什么要使用分布式ID1，什么是分布式ID在我们业务数据量不大的时候，单库单表完全可以支撑现有业务，数据再大一点搞个MySQL主从同步读写分离也能对付。但随着数据日渐增长，主从同步也扛不住了，就需要对数据库进行分库分表，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求；特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。2，分布式ID需要满足的条件全局唯一：必须保证ID是全局性唯一

一，Zookeeper实现分布式锁原理利用Zookeeper的临时有序节点可以实现分布锁，简要复习一下Zookeeper的临时有序节点：Ephemeral节点，在创建它的客户端与服务器间的 Session 结束时自动被删除。服务器重启会导致 Session 结束，因此 Ephemeral 类型的 znode 此时也会自动删除。Sequence节点，创建出的节点名在指定的名称之后带有10位10进制数的序号。多个客户端创建同一名称的节点时，都能创建成功，只是序号不同。实现原理加锁首先，在Zoo

一，redlock算法Redis 官网对 redLock 算法的介绍大致如下：在分布式版本的算法里我们假设我们有N个Redis master节点，这些节点都是完全独立的，我们不用任何复制或者其他隐含的分布式协调机制。之前我们已经描述了在Redis单实例下怎么安全地获取和释放锁。我们确保将在每（N)个实例上使用此方法获取和释放锁。在我们的例子里面我们把N设成5，这是一个比较合理的设置，所以我们需要在5台机器上面或者5台虚拟机上面运行这些实例，这样保证他们不会同时都宕掉。为了取到锁，客户端应该执行以下操作:

一，Lua脚本Redisson这个框架重度依赖了Lua脚本和Netty，用Lua脚本来保证加锁和解锁的原子操作，用Netty来保证高性能。1，加锁Lua脚本脚本入参参数示例值含义KEY个数1KEY个数KEYS[1]my_first_lock_name锁名ARGV[1]60000持有锁的有效时间：毫秒ARGV[2]58c62432-bb74-4d14-8a00-9908cc8b828f:1唯一标识：获取锁时set的唯一值，实现上为redisson

Redisson是java的redis客户端之一，提供了一些api方便操作redis。Redisson为我们提供了单台Redis加锁，Redis哨兵加锁，红锁等方案。本节我们只介绍使用，至于原理和源码我们后面会详细分析，下面我们通过示例来展示一下用Redisson加锁的几种方式：一，单台Redis单点模式，也就是使用一台Redis服务来实现分布式锁。缺点也是显而易见的，无法实现高可用，万一这台设备挂了，那么将无法加锁。pom依赖 <dependency>

一，可靠性首先，为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：互斥性：在任意时刻，只有一个客户端能持有锁。不会发生死锁：即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。具有容错性：只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。解铃还须系铃人：加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。二，代码实现1，组件依赖 <dependency> <groupId>

基于数据库的实现由两种实现方式：基于数据库表和基于数据库排他锁的方式。一，基于数据库表要实现分布式锁，最简单的方式就是直接创建一张锁表，然后通过操作该表中的数据来实现了。当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。场景模式：在网约车系统中，乘客下一条订单，然后需要司机去抢单，一个订单唯一一个ID，且唯一对应一个司机，所以我们可以这样设计数据库表。create table tbl_order_lock( order_id int unique,

一，什么是分布式锁在分布式系统中，为了防止分布式系统中的多个进程之间相互干扰，保证一个方法或属性在高并发情况下的同一时刻只能被同一个线程执行和使用，就需要一种分布式协调技术来对这些进程进行控制和调度。而分布式锁就是能够实现分布式协调调度的技术。二，为什么使用分布式锁在单机环境中Java提供了很多并发处理相关的API。比如在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLock或Synchronized)进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系

一、引言分布式系统通常由大量异构的节点和网络组成，节点随时可能crash，网络也随时可能出现延迟、丢包、分区。相比集中式应用，分布式系统放大了出故障的概率，因此分布式系统的其中一个实现目标就是高可用，高可用意味着系统必须具有较强的容错性，即在部分节点故障的情况下仍然能正常对外提供服务。分布式系统实现高可用的方式有很多，常见的主要有以下几种：Master-Slave（包括主备、主从、主主）集群熔断降级限流Master-Slave、集群的本质都是冗余。熔断、降级、限流则从另一个维度——系统内

一，项目背景事物消息最终一致性方案，其实它也是可靠消息最终一致性方案。在事物消息方案中，RocketMQ（kafka）包含了可靠消息方案中的可靠消息服务+MQ，所以，如果用此方案，那么我们就不用再写一个可靠消息服务了，消息的状态，回查机制等等RocketMQ都已经帮我们做了。事物消息最终一致性方案和可靠消息最终一致性方案只能应用在异步场景中，比如：下单成功之后，增加积分服务，物流服务等。不要求时时性。如果要求时时性的场景中，比如A向B转账，A减少100，B就必须要时时增加100，这种情况就不能用可靠消

一，业务背景用户购买商品的业务逻辑。整个业务逻辑由3个微服务提供支持：仓储服务：对给定的商品扣除仓储数量。订单服务：根据采购需求创建订单。帐户服务：从用户帐户中扣除余额。业务流程：订单服务创建订单，插入数据库，调用账户服务扣除余额，调用仓储服务扣减库存。二，seata-server配置1，seata-server下载http://seata.io/zh-cn/blog/download.html我们这里下载的1.4.0版本2，registry.conf配置registry {

一，Seata介绍Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。Seata的分布式事务解决方案是业务层面的解决方案，只依赖于单台数据库的事务能力。Seata框架中一个分布式事务包含3中角色：Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。Transaction Mana

一，使用场景在商城系统中，非常重要的一块是支付模块，当app调用第三方支付接口完成之后，第三方平台会回调到我们后台模块，我们后台模块分为支付模块（service-pay），订单模块(service-order)，物流模块(service-ship)：支付模块（service-pay）：负责记录支付流水，并回复第三方模块ACK，记录本地数据库，然后调用订单模块和物流模块。订单模块(service-order)：修改订单已支付。物流模块(service-ship)：发货。假设以上三个模块的业务逻辑

文章目录一，TX-LCN的核心控制流程二，TCC模式原理特点：三，TXC模式原理TXC逆向SQL特点：四，LCN模式原理特点：五，负载问题六，保障机制与补偿超时机制TM清理机制补偿出现的处理机制一，TX-LCN的核心控制流程事物发起方在发起事物之前，先去调用TM，去创建事物组数据，事物组数据在TM中存储（TM是存储在Redis下面来管理事物的数据）然后，事物发起方执行自己本地业务，然后调用参与方A，参与方A执行完自己的业务之后，加入到TM的事物组中，返回业务数据给事物发起方。事物发起方再去调用参

一，项目背景在系统模块中，非常重要得一块是支付模块，当app调用第三方支付接口支付成功后，第三方平台会回调到我们后台模块，我们后台模块如果把支付模块和订单模块分开得话，那么此时就应该考虑分布式事物！下面我们以 ActiveMQ+定时任务+本地事物表，来实现此场景下得分布式事物！注意：此场景可以应用在中小型系统中，不适用数据量特别大得系统中，大型系统场景中得实战我们后面会讲到二，架构原理第三方系统回调到支付模块中，更新支付系统中的流水记录表，并插入本地事件表，设置event_type状态为new

集中式应用的分布式改造必然伴随着拆分，拆分的方式有很多种，从最早的N层架构到SOA，再到现在流行的微服务。拆分的重要目的之一就是增强系统的可扩展性，本文将段对最常见的三种应用拆分方式进行介绍。一、分层架构应用为了实现“高内聚、低耦合”的设计目标，往往会进行拆分，一种最常见的拆分方式就是“分层”。“分层架构”也叫做“N层架构”，通常情况下，N至少是2层。基于划分维度的不同，“分层架构”又可以区分为：B/S和C/S架构、MVC和MVP架构、逻辑分层架构等。比较典型的是逻辑分层架构，如下图是J2EE应用的常见

一、简介在数据分片中，不管是普通hash、一致性hash还是range based，都要基于某个key进行hash运算，然后根据计算值进行分片。Key一般采用基于记录的特征值，这个特征值在不同的框架中有不同的叫法，比如MongoDB中的sharding key (https://docs.mongodb.com/manual/core/sharding-shard-key/)，Oracle中的Partition Key(https://docs.oracle.com/cd/B28359_01/serve

一、简介Range Based 这种数据分片方式是指将整个Hash值空间，分成不相交的几个分段，每个物理节点负责其中的一段或几段值空间。比如Redis在集群模式下，Hash值空间为[0,16383]，每个节点会负责一定数量的分段（槽），所有的键根据哈希函数映射到0~16383整数槽内。二、优缺点Range Based其实和一致性hash非常类似：如果一个节点只负责一段值空间，range based与没有虚拟节点概念的一致性hash很类似；如果一个节点负责多段值区间，range based与有虚

一、数据分片可扩展性是指当系统的任务（work）增加时，通过增加资源来应对任务增长的能力。分布式系统出现的目的之一就是解决单个计算机无法完成的计算、存储任务。那么当任务规模增加的时候，首先要考虑的问题就是：如何对任务进行拆分，将任务的子集分配到每一个节点，每个节点只负责原问题（即整个系统需要完成的任务）的一个子集？比如，在分布式存储系统中，任务的拆分就是数据分片，每个节点存储完整数据的一部分。常见的数据分片算法包括：普通哈希（hash），一致性哈希（consistency hash），基于数据范围

一、简介2007年，Pat Helland发表了一篇名为《Life beyond Distributed Transactions: an Apostate’s Opinion》（http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf）的论文，提出了TCC（Try-Confirm-Cancel） 的概念。两阶段提交（2PC）和 三阶段提交（3PC）并不适用于并发量大的业务场景。TCC事务机制相比于2PC、3PC，不会锁定整个资源，而是通

一、简介本章，我们将要介绍一种生产上最常用的分布式事务解决方案——可靠消息最终一致性方案。所谓可靠消息最终一致性方案，其实就是在分布式系统当中，把一个业务操作转换成一个消息，然后利用消息来实现事务的最终一致性。比如从A账户向B账户转账的操作，当服务A从A账户扣除完金额后，通过消息中间件向服务B发一个消息，服务B收到这条消息后，进行B账户的金额增加操作。可靠消息最终一致性方案一般有两种实现方式，原理其实是一样的：基于本地消息表基于支持分布式事务的消息中间件，如RocketMQ等二、本地消息

一、简介在二阶段协议中，事务参与者在投票阶段，如果同意提交事务，则会锁定资源，此时任何其他访问该资源的请求将处于阻塞状态。正因为这个原因，三阶段协议（Three-phase commit protocol, 3PC）对二阶段协议进行了改进：一方面引入超时机制，解决资源阻塞问题；另一方面新增一个询问阶段（CanCommit），提前确认下各个参与者的状态是否正常。二、协议详解我们先来看下三阶段提交协议的成功场景：2.1 询问阶段（CanCommit）询问阶段，事务协调者向事务参与

一、何谓分布式事务1.1 单体应用首先，来看下传统的单体应用（Monolithic App）。下图是一个单体应用的 3 个 模块，在同一个数据源上更新数据来完成一项业务，整个过程的数据一致性可以由数据库的本地事务来保证，如下图：1.2 分布式应用随着业务需求和架构的变化，单体应用进行了服务化拆分：原来的 3 个 模块被拆分为 3 个独立的服务，每个服务使用独立的数据源（Pattern: Database per service）。整个业务过程将由 3 个服务的调用来完成，如下图：此时，每个服务

在上一篇 CAP理论 中，我提到分布式系统理论上只能取CP或AP，如果要实现强一致性必然会影响可用性。但是，大多数系统实际上不需要那么强的一致性，而是更关注可用性。比如一个3节点的集群，假设每个节点的可用性为 99.9％，那么整个集群的可用性为 99.7％，也就是说，每个月约宕机 129.6 分钟，这对于很多系统是非常严重的问题，所以生产环境，大多数系统都会采用可用性优先的 AP 模型。在对大规模分布式系统的实践过程中，eBay 的架构师 Dan Pritchett 提出了BASE理论，其核心思想就是：

集中式应用进行服务化拆分后，必然会出现一个问题：如何保证各个节点（Node）之间的数据一致性？比如以下场景：用户首先发起一次更新操作，映射到节点A；然后，用户又做了一次查询操作，操作映射到了节点B，此时A和B的数据如果不一致，对用户来说就会造成困扰。分布式系统为了提高可用性，必然会引入冗余机制（副本），而冗余便带来了上面描述的一致性问题。为了解决这类问题，加州大学伯克利分校的Eric Brewer [https://en.wikipedia.org/wiki/Eric_Brewer_(scientist