分布式服务架构的设计方案上—分布式基础理论知识

1.什么是分布式架构

分布式系统（distributed system）是建立在网络之上的软件系统，它有两个特性：

• 1.内聚性
  数据库分布节点高度自治，有本地的数据库管理系统
• 2.透明性
  每一个数据库分布节点对用户的应用来说都是透明的，看不出是本地还是远程

在分布式数据库系统中，用户感觉不到数据是分布的，即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。
简单来讲：在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的

在上图中，提到了一个SOA架构，那么这个SOA是什么呢？
这是一个主流的架构模型，与其功能类似也是我们经常听到用到的是微服务架构

2.SOA架构和微服务架构

2.1 SOA架构

SOA全称（Service Oriented Architecture） 中文意思为 面相服务的架构，他是一种设计方法，包含多个服务，服务之间通过相互依赖最终提供一系列的功能， 一个服务通常以独立的形式存在与操作系统进程中，各个服务之间通过网络调用

跟SOA相提并论的还有ESB（企业服务总线），简单来说ESB就是管道，链接各个服务节点，为了集成不同系统和不同协议，ESB做消息的转化解释和路由的工作。让不同的服务连通。
在未使用SOA架构时，系统初期：

随着业务的增长，系统后来就变成这个样子：

看起来是不是很糟糕，此时SOA架构应运而生，有了SOA之后就变成这个样子：

是不是看起来好多啦
分布式架构的设计思路就是当业务发展到一定程度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯。
面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障时会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。

所以SOA解决了：

• 1.系统集成，站在系统的角度，解决企业系统间的通信问题，把原先散乱无规划的系统间的网状结构，梳理成规划，可治理的系统间星型结构。 这一步需要引入一些产品，例如 ESB，以及技术规范，服务管理规范，这一步解决的核心问题是 有序
• 系统的服务化 ，站在功能的角度，把业务逻辑抽象成可复用可组装的服务，通过服务的编排和实现业务的快速再生，目的：把原先固有的业务功能变为通用的业务服务，实现业务逻辑的快速复用，这步解决的核心问题是 复用
• 3.业务的服务化,站在企业的角度，把企业只能抽象成可复用 可组装的服务，把原先职能化的企业架构转为变为服务花的企业架构，进一步提升企业的对外服务能力，前两步都是技术层面来解决系统调用，系统功能复用的问题，第三步 则是以业务驱动把一个业务单元封装成一项服务，这一步解决的核心问题是 高效

2.2 MSA 微服务架构

微服务是真正意义上的独立服务，从服务入口到数据持久层，逻辑上都是独立隔离的，无需服务总线来接入，但同时也增加了整个分布式系统的搭建和管理难度，需要对服务进行编排和管理，所以伴随着微服务的兴起，微服务生态的整套技术栈也需要无缝接入，才能支撑起微服务的治理理念。
微服务架构和SOA架构类似，微服务架构是在SOA上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发设计运行的小应用。这些小应用之间通过服务完成交互和集成。
组件表示一个可以独立更换和升级的单元，像 PC机中的 CPU 内存，显卡 等 独立且可以更换升级而不影响其他单元，如果我们把PC机作为组件以服务的方式构建，那么这台PC只需要维护主板和一些必要的外部设备，CPU ，内存，硬盘 都是以组件方式提供服务，PC需要调用CPU做计算机处理，只需要知道CPU这个组件的地址即可。
如果一个分布式系统具备如下特点，则可以称之为“微服务架构”：

• 1、任何一个服务都由多个独立的进程提供服务，这些进程可以分布在多台物理机上，任何进程宕机都不会影响系统提供服务；
• 2、整个系统是由多个微服务有机组成的一个分布式系统，换而言之，不是一个巨大的单体应用。

微服务特征

• 1.通过服务实现组件化
• 2.按业务能力来划分服务和开发团队
• 3.去中心化
• 4, 基础设施自动化（devops ,自动化部署）

2.3 SOA 架构和微服务架构的区别

• 1，微服务不在强调传统的SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。
• 2，Docker 容器技术的出现，为微服务提供了便利的条件，比如更小的部署单元，每个服务都可以通过类似的Node或者Spring boot 等技术跑在自己的进程中，
• 3，SOA 注重的系统集成方面，而微服务关注的是完全分离

提到分布式，就不得不说一下节点的概念

3.节点与网络

3.1 节点

传统的节点也就是一台单体的物理机，所有的服务都揉进去包括服务和数据库；
随着虚拟化的发展，单台物理机往往可以分成多台虚拟机，实现资源利用的最大化，节点的概念也变成单台虚拟机上面服务；
近几年容器技术逐渐成熟后，服务已经彻底容器化，也就是节点只是轻量级的容器服务。
总体来说，节点就是能提供单位服务的逻辑计算资源的集合。

3.2 网络

分布式架构的根基就是网络，不管是局域网还是公网，没有网络就无法把计算机联合在一起工作，但是网络也带来了一系列的问题。
网络消息的传播有先后，消息丢失和延迟是经常发生的事情，我们定义了三种网络工作模式：

• 同步网络

  • 节点同步执行
  • 消息延迟有限
  • 高效全局锁

• 半同步网络

  • 锁范围放宽

• 异步网络

  • 节点独立执行
  • 消息延迟无上限
  • 无全局锁
  • 部分算法不可行

常用网络传输层有两大协议的特点简介：

• TCP 协议
  • 首先 tcp 协议传输可靠，尽管其他的协议可以更快传输
  • tcp 解决重复和乱序问题
• UDP 协议
  • 常量数据流
  • 丢包不致命

4.分布式架构的演进

4.1 初始阶段

初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP

4.2 应用服务和数据服务分离

应用程序、数据库、文件分别部署在独立的资源上
好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver

4.3 使用缓存改善性能

缓存是分布式系统中的重要组件，主要解决高并发，大数据场景下，热点数据访问的性能问题。
提供高性能的数据快速访问。你可以理解为从磁盘里取出来数据，暂时存放在内存，以待后面处理来读取。而能存放在缓存的数据，通常是频繁访问的，不会经常修改的数据。

系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。

数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力

对于不熟悉业务代码或算法的优化者，显然加一层缓存的复杂度和风险更低，而这一层看似简单的缓存，它给系统带来的性能优化有可能大大超过前者）
在WebServer和DB之间加一层cache，这层cache一般选取的介质是内存，因为我们都知道存入数据库的数据都具有持久化的特点，那么读写会有磁盘IO的操作，内存的读写速度远比磁盘快得多。（选用存储介质，提高访问速度：内存>>磁盘；减少磁盘IO的操作，减少重复查询，提高吞吐量）

缓存的业务场景

常见的缓存有：

• 1.浏览器缓存
  浏览器可以缓存一些静态资源，比如图片、js、css等，这些都是不常变化的内容，所以没有必要每次都去请求。（减少网络IO消耗，提高访问速度）
• 2.CPU缓存
  是位于CPU与内存之间的临时存储器，它的容量比内存小的多但是交换 速度却比内存要快得多。
• 3.数据库缓存
  • 将数据写入/读取速度更快的存储（设备）；
  • 将数据缓存到离应用最近的位置；
  • 将数据缓存到离用户最近的位置。

缓存系统常用的缓存淘汰策略：

• 1、Least Frequently Used（LFU）策略
  计算使用频率，优先淘汰最不常用的缓存条目，CPU的cache所采用的淘汰策略即为LFU策略；
• 2、Least Recently Used（LRU）策略–淘汰最近最少使用的条目；
• 3、Adaptive Replacement Cache（ARC）策略–该策略由两个LRU组成，第1个LRU包含的条目是最近只被使用过一次的条目，第2个LRU包含的是最近被使用过二次的条目；
• 4、其他还有一些基于缓存时间的淘汰策略，比如淘汰存活时间超过5分钟的缓存条目。

---

分布式缓存都采用Hash算法进行数据分片，将数量庞大的缓存项均匀分布到集群中的每个节点上，比如Redis3.0开始实现的分布式集群功能就采用了Hash算法，将缓存项均匀分布到16384个Slot上去。
以Redis2.x为基础改造的Codis是国内分布式缓存开源的一个典范，出自豆瓣网。
Memcache本身并没有提供集群功能，但很多客户端Driver实现了Hash算法分配逻辑，因此也可以看成是一种分布式缓存的解决方案。
内存计算产品：商业的SAP Hana、开源的VoltDB等。VoltDB是一种开源的高性能的内存关系型数据库，提供社区版和商业版，是一种NewSql，是一个借鉴并基于HSQL的分配内存数据库集群。
更多分布式缓存信息点击此处查看

4.4 应用服务集群

使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。

同时多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。

4.5 数据库读写分离

享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢，至此我们可以通过设计数据集群，以及数据库的主从库，主负责写入，从库负责读取

4.6 反向代理和CDN加锁

为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。
不知道CDN是啥的，可以参考博文秒杀系统面试-2.1小节

4.7 分布式文件系统和分布式数据库

任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。
分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。
常见的分布式缓存，数据库，文件系统如下：

4.8 通过DNS轮询实现机房间的负载均衡

在DNS服务器中可配置一个域名对应多个IP地址，每个IP地址对应到不同的机房里的虚拟IP。当用户访问www.taobao.com时，DNS服务器会使用轮询策略或其他策略，来选择某个IP供用户访问。此方式能实现机房间的负载均衡，至此，系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再是问题。

4.9 引入noSQL和搜索引擎

当数据库中的数据多到一定规模时，数据库就不适用于复杂的查询了，往往只能满足普通查询的场景。对于统计报表场景，在数据量大时不一定能跑出结果，而且在跑复杂查询时会导致其他查询变慢，对于全文检索、可变数据结构等场景，数据库天生不适用。因此需要针对特定的场景，引入合适的解决方案。
如对于海量文件存储，可通过分布式文件系统HDFS解决，对于key value类型的数据，可通过HBase和Redis等方案解决，对于全文检索场景，可通过搜索引擎如ElasticSearch解决，对于多维分析场景，可通过Kylin或Druid等方案解决。

下面我重点讲解一下nosql

nosql、sql

概念:

• SQL (Structured Query Language) 数据库，指关系型数据库。主要代表：SQL Server，Oracle，MySQL(开源),PostgreSQL(开源)。
• NoSQL（Not Only SQL）泛指非关系型数据库。主要代表：MongoDB，Redis，CouchDB。

两者的区别：

• 1.存储方式不同
  SQL数据存在特定结构的表中；
  NoSQL则更加灵活和可扩展，存储方式可以省是JSON文档、哈希表或者其他方式。
• 2.表/数据集合的数据的关系
  SQL：必须定义好表和字段结构后才能添加
  NoSQL:数据可以在任何时候任何地方添加，不需要先定义表
• 3.外部数据存储
  SQL：增加外部关联数据的话，规范化做法是在原表中增加一个外键，关联外部数据表。
  NoSQL中除了这种规范化的外部数据表做法以外，我们还能用如下的非规范化方式把外部数据直接放到原数据集中，以提高查询效率
• 4.SQL中的JOIN查询
  SQL中可以使用JOIN表链接方式将多个关系数据表中的数据用一条简单的查询语句查询出来。
  NoSQL暂未提供类似JOIN的查询方式对多个数据集中的数据做查询。所以大部分NoSQL使用非规范化的数据存储方式存储数据。
• 5.数据耦合性
  SQL中不允许删除已经被使用的外部数据
  NoSQL中则没有这种强耦合的概念，可以随时删除任何数据。
• 6.事务
  SQL中如果多张表数据需要同批次被更新，即如果其中一张表更新失败的话其他表也不能更新成功。这种场景可以通过事务来控制，可以在所有命令完成后再统一提交事务。
  NoSQL中没有事务这个概念，每一个数据集的操作都是原子级的。
• 7.增删改查语法不同
• 8.查询性能不同
  在相同水平的系统设计的前提下，因为NoSQL中省略了JOIN查询的消耗，故理论上性能上是优于SQL的。

搜索引擎

• Lucence Core：Java编写的核心类库，提供全文检索功能的底层API与SDK。
• Solr：基于Lucence Core开发的高性能搜索服务，提供了REST API的高层封装接口，还提供了一个Web管理界面。
• PyLucene：一个Python版的Lucene Core的高仿实现。
• ElasticSearch：也是基于Lucence的分布式全文检索中间件。

4.10 业务拆分

系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。

• 纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统
• 横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务

4.11 复用的功能抽离成微服务

如用户管理、订单、支付、鉴权等功能在多个应用中都存在，那么可以把这些功能的代码单独抽取出来形成一个单独的服务来管理，这样的服务就是所谓的微服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。
此外，可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。

4.12 引入企业服务总线ESB屏蔽服务接口的访问差异

通过ESB统一进行访问协议转换，应用统一通过ESB来访问后端服务，服务与服务之间也通过ESB来相互调用，以此降低系统的耦合程度。
这种单个应用拆分为多个应用，公共服务单独抽取出来来管理，并使用企业消息总线来解除服务之间耦合问题的架构，就是所谓的SOA（面向服务）架构，这种架构与微服务架构容易混淆，因为表现形式十分相似。
微服务架构更多是指把系统里的公共服务抽取出来单独运维管理的思想，而SOA架构则是指一种拆分服务并使服务接口访问变得统一的架构思想，SOA架构中包含了微服务的思想。

业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难

4.13 引入容器化技术实现运行环境隔离与动态服务管理

目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes(K8S)，应用/服务可以打包为Docker镜像，通过K8S来动态分发和部署镜像。
Docker镜像可理解为一个能运行你的应用/服务的最小的操作系统，里面放着应用/服务的运行代码，运行环境根据实际的需要设置好。
把整个“操作系统”打包为一个镜像后，就可以分发到需要部署相关服务的机器上，直接启动Docker镜像就可以把服务起起来，使服务的部署和运维变得简单。

在大促的之前，可以在现有的机器集群上划分出服务器来启动Docker镜像，增强服务的性能，大促过后就可以关闭镜像，对机器上的其他服务不造成影响。

4.14 以云平台承载系统

系统可部署到公有云上，利用公有云的海量机器资源，解决动态硬件资源的问题，在大促的时间段里，在云平台中临时申请更多的资源，结合Docker和K8S来快速部署服务，在大促结束后释放资源，真正做到按需付费，资源利用率大大提高，同时大大降低了运维成本。

所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象为一个资源整体，在之上可按需动态申请硬件资源（如CPU、内存、网络等），并且之上提供通用的操作系统，提供常用的技术组件（如Hadoop技术栈，MPP数据库等）供用户使用，甚至提供开发好的应用，用户不需要关系应用内部使用了什么技术，就能够解决需求（如音视频转码服务、邮件服务、个人博客等）。在云平台中会涉及如下几个概念：

• IaaS：基础设施即服务。对应于上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面；
• PaaS：平台即服务。对应于上面所说的提供常用的技术组件方便系统的开发和维护；
• SaaS：软件即服务。对应于上面所说的提供开发好的应用或服务，按功能或性能要求付费。

至此，以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案，但同时也应该意识到，在上面的介绍中，其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题。

5.分布式服务可能会面临的问题

• 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
• 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系.
• 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？
• 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？

6.分布式事务

在了解分布式事务之前，我先引入一个概念：时间与顺序

6.1 时间

对于串行的事务来说，很简单的就是跟着时间的脚步走就可以，先来后到的发生。而后我们发明了时钟来刻画以往发生的时间点，时钟让这个世界井然有序。但是对于分布式世界来说，跟时间打交道着实是一件痛苦的事情。
分布式世界里面，我们要协调不同节点之间的先来后到关系，不同节点本身承认的时间又各执己见，于是我们创造了**网络时间协议（NTP）**试图来解决不同节点之间的标准时间，但是 NTP 本身表现并不尽如人意，所以我们又构造出了逻辑时钟，最后改进为向量时钟：

• NTP 的一些缺点，无法完全满足分布式下并发任务的协调问题
  • 节点间时间不同步
  • 硬件时钟漂移
  • 线程可能休眠
  • 操作系统休眠
  • 硬件休眠

• 逻辑时钟
  • 定义事件先来后到
  • t’ = max(t, t_msg + 1)
    
• 原子钟

6.2 顺序

有了衡量时间的工具，解决顺序问题自然就是水到渠成了。
因为整个分布式的理论基础就是如何协商不同节点的一致性问题，而顺序则是一致性理论的基本概念。
有了上面信息的一些基础认知之后，我们开始正式描述分布式的事务理论

6.3 一致性理论

主要通过三个非常重要的理论来进行刻画

• 1.强一致性 ACID
• 2.分布式一致性 CAP
• 3.弱一致性 BASE

首先我们先看一下ACID理论

数据库本地事务：强一致性 ACID

单机环境下我们对传统关系型数据库有苛刻的要求，由于存在网络的延迟和消息丢失，ACID 便是保证事务的原则，这四大原则便是：

• Atomicity：原子性，一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节；保证了事务操作的整体性
  Consistency：一致性，在事务开始之前和事务结束以后，数据库的完整性没有被破坏；事务操作下数据的正确性
  Isolation：隔离性，数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时，由于交叉执行而导致数据的不一致；保证了事务并发操作下数据的正确性
  Durabilit：持久性，事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。保证了事务对数据修改的可靠性

请大家务必牢记
ACID是数据库的本地事务，而事务的ACID是通过InnoDB日志和锁来保证

• 事务的隔离性是通过数据库锁的机制实现的
• 持久性通过redo log（重做日志）来实现
• 原子性和一致性通过Undo log来实现

分布式事务理论–CAP

• Consistency：一致性,数据一致更新，所有数据变动都是同步的。
• Availability：可用性，好的响应性能，非故障的节点在合理的时间内返回合理的响应。
• Partition tolerance：分区容错性，可靠性当出现网络分区后，系统能够继续工作。

分布式系统理论上不可能选择 CA （一致性 + 可用性）架构，只能选择 CP（一致性 + 分区容忍性） 或者 AP （可用性 + 分区容忍性）架构，在一致性和可用性做折中选择。

另外，只能选择CP或者AP是指系统发生分区现象时无法同时保证C（一致性）和A（可用性），但不是意味着什么都不做，当分区故障解决后，系统还是要保持保证CA

弱一致性 BASE

多数情况下，其实我们也并非一定要求强一致性，部分业务可以容忍一定程度的延迟一致，所以为了兼顾效率，发展出来了最终一致性理论 BASE。BASE 是指

• BA：基本可用（Basically Available），分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用；
• S：软状态（ Soft State），允许系统存在中间状态，而该中间状态不会影响系统整体可用性。
• E：最终一致性（ Eventual Consistency），最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

CAP 理论是忽略延时的，而实际应用中延时是无法避免的，这一点就意味着完美的 CP 场景是不存在的，即使是几毫秒的数据复制延迟，在这几毫秒时间间隔内，系统是不符合 CP 要求的。因此 CAP 中的 CP 方案，实际上也是实现了最终一致性，只是“一定时间”是指几毫秒而已。
同时方案中牺牲一致性只是指发生分区故障期间，而不是永远放弃一致性，这一点其实就是 BASE 理论延伸的地方，分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性。
总结： BASE解决了CAP中理论没有网络延迟，在BASE中用软状态和最终一致，保证了延迟后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

强一致性、弱一致性、最终一致性

• 强一致性
  要求无论更新操作是在哪个数据副本上执行，之后所有的读操作都要能获得最新的数据。
  对于单副本数据来说，读写操作是在同一数据上执行的，容易保证强一致性。对多副本数据来说，则需要使用分布式事务协议。
• 弱一致性
  在这种一致性下，用户读到某一操作对系统特定数据的更新需要一段时间，我们将这段时间称为"不一致性窗口"。
• 最终一致性
  它是弱一致性的一种特例，在这种一致性下系统保证用户最终能够读取到某操作对系统特定数据的更新（读取操作之前没有该数据的其他更新操作）。"不一致性窗口"的大小依赖于交互延迟、系统的负载，以及数据的副本数等。

有了这些分布式事务的理论，我们再接着聊聊分布式事务解决方案

6.4 分布式事务解决方案

2PC方案

二阶段提交协议（Two-phase Commit，即2PC）是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。

• 准备阶段：
  协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
  各参与者执行事务操作，将undo和redo信息记入事务日志中（但不提交事务）。
  如参与者执行成功，给协调者反馈yes，即可以提交；如执行失败，给协调者反馈no，即不可提交。
• 提交阶段：
  如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息；参与者根据协调者的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。

核心思想就是对每一个事务都采用先尝试后提交的处理方式，处理后所有的读操作都要能获得最新的数据，因此也可以将二阶段提交看作是一个强一致性算法。
简单理解就是：

• 第一阶段：事务管理器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交
• 第二阶段：事务协调器要求每个数据库提交数据，或者回滚数据

但是2PC方案也会面临很多问题

• 单点问题:事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法使用。
• 同步阻塞:在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。
• 数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。

7.架构设计总结

• 架构的调整是否必须按照上述演变路径进行？

  不是的，以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。

• 对于将要实施的系统，架构应该设计到什么程度？

  对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。

• 服务端架构和大数据架构有什么区别？

  所谓的“大数据”其实是海量数据采集清洗转换、数据存储、数据分析、数据服务等场景解决方案的一个统称，在每一个场景都包含了多种可选的技术，如:

  • 数据采集有Flume、Sqoop、Kettle等
  • 数据存储有分布式文件系统HDFS、FastDFS
  • NoSQL数据库HBase、MongoDB等
  • 数据分析有Spark技术栈、机器学习算法等。

  总的来说大数据架构就是根据业务的需求，整合各种大数据组件组合而成的架构，一般会提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。而服务端架构更多指的是应用组织层面的架构，底层能力往往是由大数据架构来提供。

8.分布式架构设计原则

• N+1设计。系统中的每个组件都应做到没有单点故障；
• 回滚设计。确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
• 禁用设计。应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
• 监控设计。在设计阶段就要考虑监控的手段；
• 多活数据中心设计。若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
• 采用成熟的技术。刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
• 资源隔离设计。应避免单一业务占用全部资源；
• 架构应能水平扩展。系统只有做到能水平扩展，才能有效避免瓶颈问题；
• 非核心则购买。非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
• 使用商用硬件。商用硬件能有效降低硬件故障的机率；
• 快速迭代。系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
• 无状态设计。服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。

至此分布式的基础理论就到此结束啦，接下来我们谈一谈分布式在具体通过业务场景浅谈分布式设计思路