串联分布式核心技术

---

前言

先以购买火车票的流程，串联分布式核心技术。

购买火车票的流程三大核心步骤：

1. 铁路局向购票系统发布火车票；
2. 用户通过系统查询火车票，找到需要的火车票后购买；
3. 购票系统给用户响应，完成购票。

这个流程看似简单，但涉及了很多知识。

铁路局发布火车票

铁路局发布火车票的过程，主要涉及分布式数据存储的知识，包括存储系统三要素、 数据分布和数据复制等技术。

铁路局向购票系统发布火车票的过程，主要是将火车票信息发送到服务器集群进行存储，需要用到存储系统三要素的相关技术。其中，铁路局就是存储系统三要素中的“顾客”， 火车票存储到具体哪个服务器需要构建数据索引，也就是三要素中的“导购”，而存储数据的服务器就是三要素中的“货架”。

由于涉及多个服务器存储火车票信息，不可避免地需要考虑服务器之间数据存储的均衡，以及快速确定火车票信息存储位置以方便后续查询和购买火车票。因此，这里需要用到分布式存储中的数据分布技术。

铁路局按照火车线路将火车票发布到不同的服务器上，即在数据分片技术中提到的按照数据范围进行分片。比如，京广线的车票信息存储在京广线服务器集群、京沪线的车票信息存储在京沪线服务器集群等。

为了保证可靠性，当一台服务器故障后，该服务器存储的火车票信息可以恢复或不丢失，通常会进行数据备份。同一份数据可能会有多台服务器一起存储，比如京广线的火车票数据存储到服务器 A1、A2 和 A3 上，京沪线的火车票数据存储在服务器 B1、B2 和 B3 上。而数据备份，用到的就是分布式存储中的数据复制技术。由于同一份数据被多台服务器存储，自然就需要保证数据的一致性。关于数据一致性可以参考CAP 理论。

用户查询火车票

对于用户查询火车票来说，大致过程是用户向服务器发起查询请求，服务器根据用户请求， 通过数据索引，也就是导购技术，定位到火车票信息存储的位置，然后获取数据返回给用户。

正常情况下，用户并发请求量比较小，很少会出现服务器能力有限导致系统崩溃的情况。 但遇到节假日或春节，用户请求量通常会非常大，这时如果不采取一定策略的话，大概率会因为服务器能力受限导致系统崩溃。

而这里的策略，通常就是保证分布式高可靠的负载均衡和流量控制。比如，每年春运，火车票发布的瞬间，就有大量的用户抢票，如果购票系统后台不使用负载均衡和流量控制的话，服务器一下子就被击垮了。

除此之外，服务器还不可避免地会出现一些小故障，比如磁盘损坏、网络故障等问题。如何检测服务器故障，以及如何进行故障恢复，就需要用到分布式高可用的故障隔离与故障恢复的相关技术了。

接收用户请求后，接下来需要将请求转发至相应的服务器集群，然后再从中选择某一台服务器处理用户请求，也就是获取数据并返回给用户。本质上是在进行数据索引，设计分布式数据存储中的数据分布方式的相关技术。

以用户查询从北京到上海的火车票信息为例，查询流程如下：

1. 根据查询条件，系统将请求转发至存储京沪线火车票信息的服务器集群中；
2. 服务器集群再使用一次负载均衡，比如使用轮询算法， 将请求转发至某一台服务器；
3. 这台服务器将火车票的车次、余票等信息返回给用户。

在这个过程中，还可以使用限流算法，比如漏桶、令牌桶等策略来限制用户流量，保证系统高可用。

除此之外，在存储火车票信息的服务器中，各个服务器的服务单独运行，也就相当于做了一 定的故障隔离，比如图中的服务器 A1~ A3、B1~B3。

在上面的过程中，一直提到的是服务器集群。既然是集群，就会涉及集群架构、分布式选主等策略。

以集中式架构 Master/Slave 为例，服务器集群中会通过分布式选举算法选出一个 Master，Master 和其他服务器节点之间会维持心跳，并通过心跳来感知服务器节点的存活状态。比如，京广线服务器集群选出的 Master 节点为 A2，A2 与 A1 和 A3 之间一直维持心跳。

具体的集群架构原理可以参考分布式资源管理与负载调度；分布选主的原理可以再回顾分布式协同与同步的相关内容。

当集群中 Master 节点故障后，会从其他节点中重新选举出一个 Master 节点，继续为用户 提供服务，也就是备升主，以保证服务的可用性。备升主就是一种故障恢复策略。

用户购买火车票

与用户查询火车票的过程类似，用户购买火车票过程唯一不同的是，会造成数据库的变化。用户查询火车票是读请求，而购买火车票相当于一个写请求。

写请求与读请求的区别是，写请求会造成数据的变化，因此相对于查询火车票，购买火车票的过程涉及的技术问题会多一些，但多出的无非就是数据的一致性问题。谈到数据的一致性，就会想到 CAP 理论、数据复制技术、分布式事务、分布式锁等。其实不仅仅是购买火车票，任何一个简单的购买操作或写操作中，都会涉及这些分布式知识。

每次购买火车票的操作，就是一个分布式事务，要么执行成功要么执行失败。

当用户购买了火车票时，该火车票对应时间的车次余票数量必须相应减 1，如果减少时发现原先票数就已经为 0 了，此时就应该提醒用户购买火车票失败，余票为 0；同样的，如果票数不为 0，则票数应该相应减 1，并提示用户购票成功。

购买火车票会改变火车票数据，也不可避免地会存在多个用户同时购买相同路线、相同车次（比如京沪线的 T12）的场景。这个购买过程存在多个进程同时访问共享资源的问题，因此还要用到分布式锁的相关技术。

用户购买火车票的过程还会涉及用户体验、数据一致性和网络故障等问题，因此还涉 及 C、A、P 策略的选择问题。

在铁路局发布火车票的流程中，为了保证可靠性，同一数据通常会备份到多个服务器上。当用户购买火车票导致火车票数据改变时，主节点上的数据必须与备节点上的数据保持一致， 以防止主节点故障后，备升主，但数据不一致导致业务出错的情况。

比如，用户 A 购买 2019 年 10 月 12 日北京到上海的 T12 的火车票，已购买成功，座位号为 3 车厢 23B。假设主节点和备节点之间数据不一致，主节点上已经减去该火车票，但未在备节点上减去。此时，若主节点故障，备节点升主，用户 B 此时申请购买相同火车票，系统将 3 车厢 23B 火车票又卖给了用户 B。等到乘车时，用户 A 和 B 就难免“打架”了。

通常因为网络故障或节点故障等原因导致主节点不能正常工作，才会发生备升主，而备升主其实就是故障恢复策略，而一致性问题涉及的是分布式数据存储的相关技术。

同时，购买火车票的场景需要快速响应用户，以保证用户体验。因此，通常优先保证系统的可用性，稍微降低对数据一致性的要求，但也必须保证最终一致性。这就是平常遇到的，查询火车票时还有余票，但下单后却提示余票为 0，无法购买。

导致这个结果的原因是，下单前你访问的数据库中，数据还未同步，显示有余票；而下单后，数据实现同步了，发现余票数量已经为 0，因此提示你无法购买该火车票。

实现上述策略的方法，通常会采用半同步复制技术，即将修改后的数据同步到多个备数据库中的某一个或几个后立即响应用户，而不用将数据同步到所有备数据库。

除此之外，业务量很大的情况下，为了让服务更加健壮、低耦合、便于管理，会根据功能拆分为不同的服务。比如，将整个购票系统拆分为订单系统、支付系统和通知系统，而当购票系统拆分为 3 个子系统后，子系统之间不可避免的存在信息的交互，子系统之间的交互就会涉及分布式通信的相关知识，比如远程调用 RPC、消息队列等。

如图所示，用户购买火车票后，会首先在订单系统下单，下单成功后会调用支付系统的支付操作进行支付，之后将支付成功的消息存放到消息队列中，通知系统到消息队列中获取消息，最后通知用户购买成功。

总结

以购买火车票为例串联分布式技术在实践中的应用。购买火车票的模型简化为三个核心步骤，即铁路局发布火车票、用户查询火车票和用户购买火车票。

这三个核心步骤涉及的关键的分布式技术

• 对于铁路局发布火车票这个流程来说，铁路局是数据的生产者，需要将数据发布到服务器进行存储，主要涉及的是分布式数据存储相关技术，对应分布式数据存储的内容。
• 对于用户查询火车票来说，主要是读请求，涉及负载均衡、流量控制、集群管理及选主等技术，对应专栏分布式协调与同步、分布式资源管理与负载调度、分布式高可靠的内容。
• 对于用户购买火车票来说，是写请求，涉及数据的改变，因此除了用户查询火车票涉及的技术外，还额外涉及一致性、分布式事务、远程通信等技术，对应分布式协调与同步、分布式通信技术、分布式数据存储和分布式高可用等内容。