口试场景题系列：设计支付系统

从网约车、旅游、外卖到电商大概医疗保健，幕后运行的支付系统让全部的经济运动酿成可能。比年来，设计一个可靠、可扩展、机动的支付系统成为盛行的系统设计口试题。
什么是支付系统？维基百科上是这么说的，“支付系统是通过转移货币代价来完成金融生意业务的系统，包罗促成生意业务的机构、工具、人员、规则、程序、标准和技术。”支付系统被广泛利用。从外貌上来看，支付系统很容易理解，但是对大部分开发人员来说它很可怕，因为一个很小的问题就可能导致庞大的收入损失及用户流失。在本文中，我们会解密支付系统。
1.场景界定

第一步　理解问题并确定设计的界限对不同的人来说，支付系统可能有非常不同的含义。有些人可能会以为它是像Apple Pay大概Google Pay之类的电子钱包；有些人可能以为它是一个处理支付的后端系统；还有一些人以为它是支持PayPal大概信用卡支付的系统。从通用性考虑，本文我们聚焦于设计一个能支持如下利用场景的支付系统。 •收款流程：支付系统代表卖家向顾客收款。
•付款流程：支付系统每个月给全世界的卖家付款。
•支持提到的全部主流支付方式
•系统每天生意业务笔数：100万笔
•及时卖家仪表板：表现卖家将要收到的款项。仅了解顾客的利用场景并不敷以提出可靠的设计。
为了设计出可以处理数百万笔生意业务的支付系统，理解电商商家可能面临的挑战很告急。
2018年MRC Global Payments Survey做了一次调查，将商家管理电商支付时遇到的挑战做成了一个排行榜（如图-1所示）。在我们的设计中，我们会把一些排名靠前的挑战考虑进来。

图-1
2 顶层设计

在高层级上，这个系统可以分成3个部分： •收款流程。
•付款流程。
•及时卖家仪表板。
2.1 收款流程

我们先看一下当顾客在亚马逊下单之后会发生什么，如图-2所示。

图-2
•顾客：将产物添加到购物车中。
•订单系统：创建订单。
•支付系统：记录资金的流动，但是并没有真正地转移资金。
•支付服务处理器(Payment Service Processor，PSP)：PSP把资金从账户A转移到账户B。“PSP”这个词在本文中也代表银行。请注意，真实的资金流动过程很复杂，图-2是对现实的简化和抽象。
流程的抽象

亚马逊不仅仅有购物网站，它还有凌驾40家子公司，包罗Audible、IMDB、Zappos、AWS等[插图]。其中的一些子公司可能共享同一个支付系统。别的，亚马逊还有不同的业务线，好比购物、亚马逊Prime视频、亚马逊音乐等。为了支持全部这些业务，我们对支付流程干系的组件进行抽象，并提供一个如图-3所示的简单模子。

图-3
•业务事件：业务事件触发资金的流动。这些事件包罗顾客下单、订阅亚马逊Prime视频等。
•支付系统：之前已经解释过了。
•PSP：之前已经解释过了。
这里会有多种范例的业务事件和很多不同的PSP，如图-4所示。

图-4
当我们设计支付系统时，很告急的一点是把不停变化的组件与稳固的组件分开。举个例子，亚马逊不停拓展新的市场并增加新业务线。新的业务线通常意味着新的支付业务事件。现在没有单一的PSP可以担当全部的支付方式。为了支持国际支付，你需要添加更多的支付服务提供商。
我们看看收款流程的哪些部分是稳固的，哪些部分是不停变化的。收款流程有3个组件：支付API、支付核心和支付传输（见图-5）。

图-5
支付API：隐藏了系统其他组件的复杂性，并为业务事件提供了高层级接口。这个组件应该具有可扩展性以容纳新的业务事件。
支付核心：代表系统的核心。这个组件通常是稳固的。
支付传输：提供了支付路由以及与不同PSP的集成。这个组件应该具有可扩展性以采取新的PSP。
2.2 复式记账系统(Double-Entry System)

在继续详解高层级设计之前，让我们看一个告急概念：复式记账系统（也叫作复式记账/簿记）[插图]。复式记账系统是支付系统的基础，并且对记录资金的流动很关键。它把每笔支付生意业务记录在两个相互独立的账户中，金额相同，一个账户借记，另一个账户就会贷记相同金额（见图-6）。 复式记账系统声明全部生意业务分录之和必须等于0。每一个账户中损失的金额（好比，失去1分钱），一定对应在另一个账户中获得的相同金额（好比，得到1分钱）。它提供了端到端的可追踪性并确保了整个支付周期的同等性。

图-6
2.3 托管支付页面

大部分中小型公司倾向于不存储顾客的信用卡账户信息，因为如果要这么做，就必须遵守支付卡行业数据安全标准(Payment Card Industry Data Security Standard，PCI DSS)中的全部复杂规定。为了避免处理信用卡信息，这些公司会利用由PSP提供的托管信用卡页面。在网站上，它可能是一个窗口小组件大概iframe；在移动应用中，它可能是一个支付SDK预先构建的页面。图-7是一个集成了PayPal的结账界面。这里的关键点是PSP提供了一个托管支付页面，可以直接获取顾客的信用卡信息而不是由支付系统来获取。

图-7
高层级架构

收款流程的高层级架构如图-8所示。

图-8
我们先细致看每个组件，然后理解它们是怎样一起工作的。圆圈里的数字代表处理支付时的流程顺序。
业务事件

如之前解释的那样，资金的流动是通过业务事件来触发的。 支付API

我们的支付API支持幂等性，以是顾客可以安全地重试支付请求而不消担心会重复付款。有关幂等性的具体内容会在3.1节先容。最常用的支付API有如下4个。 (1)创建支付：请求付款。

1. POST /v1/payments

复制代码

请求头(Header)和路径参数：amount（金额）、currency（币种）
(2)重试支付：因为网络故障大概超时而重试支付操作。

1. POST /v1/payments

复制代码

添加额外的幂等性键Idempotency-Key：<key＞header，避免做重试操作的时间向顾客收两次钱。
(3)获取支付细节：获取特定支付的干系信息。

1. GET /v1/payments/{id}

复制代码

(4)退款：把钱款退回顾客。

1. POST /v1/payments
3. /{id}/rufunds

复制代码

嵌入的{id}表示某支付生意业务的ID。
上面提到的支付API和PSP API类似。如果你想更全面地了解支付API，请参阅Stripe官网上的API文档。
支付处理器

支付处理器协调和管理不同的支付服务。它把支付系统其他服务的复杂性都隐藏起来。它是一个提供如下功能的编排层。 •调用反欺诈和风险服务，检查支付中是否存在欺诈活动。
•调用路由服务，决定哪个PSP对于支付生意业务是最好的选择。
•调用支付集成服务，处理支付生意业务。反欺诈和风险服务反欺诈和风险服务担当正常的生意业务并拒绝欺诈性生意业务。支付生命周期的任何阶段都可能存在风险，以是这个服务在一个支付生意业务中可能会被请求很多次。
反欺诈和风险服务

反欺诈和风险服务担当正常的生意业务并拒绝欺诈性生意业务。支付生命周期的任何阶段都可能存在风险，以是这个服务在一个支付生意业务中可能会被请求很多次。 路由服务

路由服务定义了支付路由规则，并动态地将支付生意业务路由到最合适的PSP。 •降低支付处理的成本。不同的PSP和银行收取的支付处理费用不同，路由服务会只管最小化这个费用。
•最大化成功率。如果一个支付生意业务失败，路由服务会选择另一个PSP来处理这个失败的支付生意业务。
•减小故障的影响。路由服务会自动检测故障，并把生意业务从发生故障的PSP切换到备用的PSP。
•降低支付处理的延时。路由服务紧密地监测生意业务延时，并选择响应快的PSP。
支付集成服务

没有一个环球性的PSP的服务可以覆盖全部国家和支付方式。因此，跨国运营的公司必须与多个PSP集成。支付集成服务提供统一的API来与第三方PSP和银行进行通信。一样平常而言，支付集成服务通过PSP与银行进行通信，但是有些银行自己就是PSP。如图-9所示，两种范例的通信协议被广泛利用。

图-9
•及时API集成（接纳HTTPS协议）。大部分PSP（如PayPal、Stripe等）为支付集成服务提供API，用于实现及时支付。
•批量文件集成（接纳SFTP协议）。这种方式不是及时的，支付请求有可能需要几天时间来处理。很多银行只提供利用安全文件传输协议(Secure File Transfer Protocol，SFTP)来集成的方式。SFTP有它的优势，可以异步处理大量的数据。我们的支付集成服务将每天的生意业务（或按照其他预设的频率）汇总到文件里，并将这些文件批量发送给银行。这里的一个告急考量是确定性批处理(Deterministic Batching)，意思是纵然多次运行同样的文件天生任务，结果也是一样的。如果服务器瓦解，只需重新运行这个任务。
PSP和银行

根据维基百科上的定义，“支付服务提供商(Payment Service Provider，PSP)为在线购物提供服务来担当电子支付，有多种支付方式，包罗信用卡、基于银行的支付（好比直接借记、银行转账）和基于网上银行的及时银行转账”。简而言之，PSP和银行负责实际的资金收付。 数据层

我们选择关系型数据库来存储支付数据，因为它提供了ACID特性。一些最告急的数据库列举如下：生意业务日记(Transaction Log)数据库、令牌保险库(Token Vault)、支付档案(Payment Profile)和用户档案(User Profile)。 生意业务日记数据库

全部支付生意业务都存储在生意业务日记数据库中。它是一个关系型数据库，因为ACID特性对于支付数据很告急。维护数据完整性是很有挑战性的，但极度告急。第3节报告了更多细节。 令牌保险库

令牌保险库是一个安全地会合存储支付令牌的地方。它也是一个关系型数据库。支付令牌化是用唯一的支付令牌来更换敏感的信用卡大概银行账户细节信息的过程（如图-10所示）。因为不消暴露斲丧者的信用卡信息，令牌化让无卡支付变为可能。安全是最告急的。令牌保险库必须符合PCI规程。

图-10
支付档案

支付档案存储如下信息。 •支付方式：信用卡、借记卡、银行账户、PayPal等。
•订阅和定期支付(Recurring Payment)数据。
•支付方式对应的账户持有人的名字和账单地址。
图-11展示了创建支付档案的例子。尽管这里输入了卡号，但是我们的支付系统并不存储完整的卡号，而通常只存储最后4位和信用卡的到期日期。只有在传输大概完整保存时，主账号(Primary Account Number，PAN)才会被视为敏感数据。

图-11
用户档案

用户档案存储了用户数据，包罗姓名、暗码、地址等。 缓存

在支付系统中，读请求（比方检查支付状态）通常比实际的生意业务支付请求多。利用缓存不仅可以淘汰数据库和核心支付服务的负载，还可以显著提升读速度 2.4 付款流程

付款流程指的是亚马逊按照预先设定的频率（好比每个月一次）给卖家付款的流程。付款流程如图-12所示。

图-12
1.支付金额汇总在付出表里。
2.调度器从汇总的付出表中获取付出金额。
3.调用支付API请求付款给卖家。
4.把钱付给卖家。这个流程和图16-9中的收款流程一样：支付API请求支付处理器，并最终请求PSP转移资金。
2.5 及时卖家仪表板

除了收款和付款流程，卖家仪表板是我们想要支持的第三个功能。卖家仪表板展示卖家在下一个付款周期将要收到的总金额的及时数据。图-13展示了利用Apache Kafka支持及时卖家仪表板的设计。Apache Kafka是一个发布—订阅消息系统。它很快，具有高可扩展性、可用性以及对节点故障的容错性。Kafka类似于消息队列，但有几个关键区别。 •对于消息队列，消息/事件一旦被处理，就将从队列中被移除。一个消息/事件是由一个斲丧者处理的。
•对于Kafka，消息/事件被处理后并没有从Kafka中被移除，而是停留在队列中，直到队列大小凌驾了限定。这使我们能重新处理消息/事件。

图-13
因为同一个支付事件通常由多个下游服务来处理，好比付款流程、报告流水线、数据分析服务、管帐等，以是很合实用Kafka。在创建及时仪表板时，经常要用到Vertica、Druid、Amazon Redshift、Google BigQuery平分析型数据库。分析型数据库是为数据分析优化过的专业数据库。它们针对查询性能和可扩展性做了优化。
3. 深入设计

在本节中，我们会重点讨论怎样使系统更加健壮和安全。在分布式系统中，错误不仅无法避免，还很常见。举个例子，如果顾客多次点击付款按钮会发生什么？他会被多次收费吗？怎样处理因为网络连接差而造成的支付失败？在本节中，我们会深入探究如下关键话题。 •重试：至少一次交付。
•幂等：至多一次交付。
•维持同等性。
•修复不同等的数据。
•处理支付失败。
3.1 重试和幂等

为了确保顾客只被收费一次，我们需要确保支付生意业务至少发生一次，至多也只发生一次。你可能会疑惑为什么我们不直接说就发生一次。这是因为“至少一次”和“至多一次”办理的是两个不同的技术问题。 重试

因为网络故障大概超时，我们偶尔需要重试支付生意业务。重试可以包管支付生意业务至少发生一次。比方，如图-15所示，客户端（顾客）尝试请求支付10美元，但是因为网络连接不佳，支付总是失败。考虑到网络状况过一段时间可能会变好，客户端重试这个请求，并且在第4次的时间终于成功。 确定合适的重试时间隔断很告急。这里有一些常见的重试计谋。
•立即重试：客户端立即重新发送请求。
•固定隔断：在支付失败和重试之间等待固定长的时间。
•递增隔断：客户端在第一次重试时等待较短时间，后面每一次重试时则渐渐增加等待时长。
•指数退避(Exponential Backoff)[插图]：在每次重试失败之后增加重试之间的等待时间。比方，当一个请求第一次失败时，我们在1秒之后重试；如果它第二次也失败了，在重试之前我们等待2秒；如果它第三次仍然失败，我们在重试之前等待4秒。
•取消：客户端可以取消请求。这是当请求总是失败大概重试不太可能成功时的常见操作。

图-14
选定合适的重试计谋是有难度的。没有哪个办理方案适合全部场景。一样平常的做法是，如果网络故障不太可能在短时间内办理，则利用指数退避。激进的重试计谋会浪费计算资源并导致服务过载。好的做法是在Retry-After请求头里提供错误码。
重试可能造成的问题是重复支付。我们看下面两个场景。
场景1：顾客快速点击了两次支付按钮。
场景2：PSP成功地处理了支付请求，但是因为网络错误，响应未能到达我们的支付系统，如图-15所示。

图-15
如图-16所示，顾客被PSP A成功收费，但是因为网络错误，我们的支付系统没有收到收费成功的响应。支付系统以为PSP A发生故障，并且用PSP B来重试支付，导致重复收费。
接下来先容办理这两种重复支付问题的方法。
幂等性

幂等性是确保“至多一次”的关键。根据维基百科上的定义，“幂等性是一种在数学和计算机科学中特定操作所拥有的特性。由于具有此特性，这些操作可以进行多次但结果在第一次操作之后就不会再改变”。从API的角度来看，幂等性意味着客户端可以重复发送同一个请求且产生的结果相同。 对于客户端（网页/移动应用）和服务器之间的通信，幂等键(Idempotency Key)通常是客户端天生的唯一值，它会在肯定时间后逾期。UUID通常被用作幂等键，并且受到很多科技公司的保举，好比Stripe和PayPal[插图]。为了实行幂等支付请求，要将幂等键添加到HTTP请求里，HTTP请求头是存放“idempotency-key：<key＞”这个键值对的常见地方。
现在我们理解了幂等性的基本概念，让我们看看它怎样帮我们办理之条件到的重复支付问题。
如果顾客快速点击了两次付款按钮会怎样？
如图-16所示，当用户第一次点击付款按钮时（第一次请求），会天生一个幂等键，并且它作为HTTP请求的一部分被发给支付系统。

图-16
对于第二个请求，因为支付系统已经见过这个幂等键，以是它会将第二个请求视为重试。如果你在请求头里包含了之前指定的幂等键，支付系统会返回之前请求的最新状态。
如果支付系统检测到拥有相同幂等键的多个并发请求，则只有一个请求会被处理，对于其他请求，支付系统会返回“429 Too Many Requests”这个状态码。
如果支付请求已被成功处理，但是因为网络错误导致返回的响应丢失（如图-15所示），该怎么办？
在这个场景里，我们需要在和外部系统(PSP)交互时维持幂等性，并跟踪支付状态（成功、失败、等待）。图-17给出了一个例子。
1.支付系统首先在生意业务日记数据库中记录带幂等键的支付请求。
2.支付系统请求PSP A来初始化收款请求。
3.收款请求被PSP A成功实行，但是因为网络错误，本应返回给支付系统的响应丢了。
4.在重试支付之前，支付系统从生意业务日记数据库中获取之前的支付状态和它之前连上的PSP的信息。
5.通过检查生意业务日记，支付系统知道支付请求被PSP A处理过，但是系统没收到响应。因此，它利用PSP A重试支付，并在重试请求里包含幂等键。
6.PSP A利用幂等键来确保不会多次收款。它返回之前因为网络错误而失败的响应。7.在生意业务日记数据库中记录从PSP A返回的响应。
7.在生意业务日记数据库中记录从PSP A返回的响应。
大部分PSP和银行的服务都以幂等的方式实现。通过在生意业务日记数据库中保存支付生意业务的状态，我们总是可以知道在支付生命周期的那里遇到了问题。

图-17
3.2 同步支付vs.异步支付

支付流程可以是同步的也可以是异步的。这是必须在设计早期做的非常告急的决策。为了做出明智的决策，我们细致地研究这两个选项。 客户端和服务器之间的通信

在深入研究之前，理解一些术语很告急。 •客户端：可以是移动应用、网站、API请求等。
•服务器：我们的支付系统。客户端和服务器之间的通信可以分为两类。
•同步通信：客户端发送支付请求，然后等待服务器的响应，将连接保持为打开的状态，直到知道生意业务结果。HTTP就是这样工作的。
•异步通信：客户端不等待服务器的响应，一旦发送了支付请求，连接就关闭了。当请求被处理后，结果被返回给客户端，这通常是通过一个网络钩子(Webhook)[插图]来实现的。Webhook，也称为网络回调，是一个应用/服务提供及时更新给其他应用/服务的方式。
同步的客户端/服务器通信过程如图-18所示。客户端发送HTTP支付请求，然后服务器（支付系统）通过HTTP响应返回结果。

图-18
图-19展示了异步的客户端/服务器通信过程。异步通信的关键组件是队列。在我们的讨论中，队列和Kafka可互换利用。异步通信按如下方式工作。

图-19
1.客户端通常通过HTTP发送支付请求。这会触发一个业务事件，该事件被放入Kafka队列中。
2.异步Worker斲丧业务事件。
3.一旦业务事件被异步Worker处理完，后端就会发送响应给对应的客户端。
是等待响应还是把请求放入队列以便稍后再处理，这是值得好好斟酌的问题。我们来看几个利用场景。
•当顾客在网上买实体商品时，异步通信会是一个好的选择，因为通常商家需要时间来预备发货。
•如果顾客购买的是可下载的假造商品，在客户端和服务器之间利用同步通信是合理的。在答应下载假造商品之前，确认支付成功很告急。
•对于基于订阅的数字内容，好比Netflix和Spotify，异步通信可能是一个好选择，我们可以在收到支付成功的确认信息之前授权用户访问。大部分的生意业务最后都会成功，而顾客不再需要等待支付处理的结果就可以提前观看内容，这会提升用户体验。对于失败的生意业务，我们的系统会通知顾客，如果款项还是没有定时收到，可能会收回访问权限。
•对于数字钱包应用，如果我们的支付系统知道精确的账户余额，异步通信是一个好主意。
内部服务之间的通信

内部服务可以利用两种通信模式：同步和异步。两者的解释如下。 (1)内部服务之间的同步通信。同步通信，好比HTTP协议，在小规模系统中运作得非常顺畅，但是当业务规模扩大时，问题就变得显着，如图-20所示。这种通信模式创建了一个依靠很多服务的长请求和响应周期。

图-20
这个模式存在以下问题。
•性能低。如果链条中的任何服务性能不佳，整个系统都会受到影响。
•故障隔离差。如果PSP大概任何其他服务出现故障，客户端就不会收到响应。
•耦合度高。请求的发送者需要知道接收者。
•很难扩展。如果没有利用队列来作为缓冲区的话，系统很难扩展以支持突然增长的流量。
(2)内部服务之间的异步通信。
异步通信可以分为以下两类。
•单接收者：每个请求（消息）由一个接收者大概服务处理。这通常通过共享的消息队列来实现。消息队列可以有多个订阅者，但是一旦消息被处理，就会从队列中被移除。我们看一个具体的例子。在图-21中，服务A和B都订阅了共享消息队列。一旦消息m1和m2被服务A和B分别斲丧，这两个消息都会从队列中被移除，如图-22所示。

图-21

图-22
•多个接收者：每个请求（消息）被多个接收者大概服务处理。这里Kafka很管用。当斲丧者收到消息时，消息并没有从Kafka中被移除。同一条消息可以被不同的服务处理。这个模子很适合支付系统，这是因为同一个请求可能触发多个操作：发送推送通知、更新财政报表、进行数据分析等。图-23展示了一个例子。同一个支付事件被发布到Kafka上且被不同的服务斲丧，好比支付系统、数据分析服务、推送通知服务和记账服务。

图-23
一样平常而言，同步通信在设计上更简单，但它不答应服务自治，并且随着同步依靠的增加，团体的性能表现也会变差。异步通信在设计上可能会牺牲一些简单性和同等性，来换取可扩展性和故障容忍性。对于有复杂业务逻辑和对第三方依靠高的大型支付系统，异步通信是更好的选择。
3.3 同等性

在分布式支付系统中，通常需要多个服务一起来完成一个逻辑上的原子操作。纵然在单个服务内部，我们也有可能用到多个数据库、缓存服务器、消息队列等。为了达到可靠性和可用性要求，数据存储服务器通常在多个数据中央之间复制。如果一个服务大概服务器发生了故障，就有可能导致数据不同等。维护数据同等性是有挑战性的，但也非常告急。在本节中，我们会回答一些告急问题：数据不同等是怎样发生的？可以用什么技术来淘汰数据不同等？怎样修复不同等的数据？ 支付状态机

一个支付生意业务在它被完全处理完之前会经历不同的状态。图-24展示了信用卡支付生意业务可能经历的状态。请注意，下面列举的支付状态是针对这个系统设计口试的简化版本，你不需要记住这些概念。想要了解更严谨的定义和分析，你可以在一些重要的信用卡大概PSP的网站上找到这些信息。 •开始：启动一个支付生意业务。
•授权：支付服务商确保支付方式（信用卡/借记卡）是有效的，并且卡内有充足的资金。
•捕获(Capture)：在授权付款之后，需要进行捕获操作。捕获意味着通知信用卡公司，需要付给亚马逊须要金额的资金。
•结算(Clearing)：支付生意业务被记入持卡人的信用卡账户。
•入账(Funding)：将资金存入商家账户。
•取消支付(Void)：如果你不希望已授权的支付生意业务被捕获，可以取消支付。取消支付和退款的区别在于一个支付生意业务是否已结算（完成）。未结算的生意业务可以被取消。

图-24
•退款：把资金退还给顾客。
•失败：任何支付操作都有可能失败。在图-24中没有表现失败状态，但它是任何支付操作都可能出现的结果。
我们的一个设计目标是保持支付系统内部的状态与PSP中的外部状态同等，如图-25所示。

图-25
我们应该在那里存储生意业务状态数据呢？因为关系型数据库提供了ACID的特性，以是我们选择它。数据库事务可以用来有效地确保同等性。
数据库

我们从简单的设计开始，假设全部的数据都存储在单体数据库中。 (1)单体数据库。支付生意业务意味着把资金从一个账户转移到另一个账户。尽管真正的资金移动发生在PSP内部，但我们的支付系统也需要记录每个生意业务状态，包罗授权、捕获、结算、入账、退款等。
这个单体数据库可以用两张表来建模：transaction和transaction_entry（见图-26、表-1和表-2）。请注意，图-26所示的这两张表里只包含了最告急的参数。
•transaction：记录每个支付生意业务。
•transaction_entry：存储支付生意业务的不同状态。一个生意业务通常包含多个生意业务条目。
生意业务条目只能追加写（不可变），原因如下：
第一，我们必须存储完整的生意业务汗青以便审计。
第二，当支付生意业务堕落时，这种方式很容易追溯是哪一个步调导致了问题。

图-26

表-1

表-2
(2)分布式数据库。在单体数据库中保持数据同等性是相对简单的，但是在分布式数据库中实现数据同等性就很有挑战性了。图-27展示了一个例子。

图-27
在图-27中，幂等数据首先被写入主数据库n1，然后被复制到副本n2和n3。因为存在滞后，副本n3中没有最新的数据。如果客户端从副本n3读数据，获取的数据就是过时的。有三种方法可以办理这个问题。
第一种方法是为了避免副本滞后，只在主数据库上存储幂等数据。读和写的操作都只在主数据库上进行。但是，这个方法有一个显着的问题——缺乏可扩展性。Airbnb通过利用幂等键对数据库分片来办理这个问题。
第二种方法是利用强同等性的模子。强同等性意味着客户端不会看到过时的值。有一点要注意，强同等性通常需要牺牲性能：为了在某个值上达成同等，我们要等待最慢副本的响应。
第三种方法是利用共识协议进行复制。共识是在分布式系统中的一个告急但复杂的话题。它意味着多个服务器对值达成同等。为了对一个值达成共识，大部分节点必须担当提议的值。如第4章讨论的那样，仲裁共识可以对读和写操作都包管同等性。
修复不同等的状态（数据）

为了确保服务之间的同等性，通常利用共识协议，好比两阶段提交(Two-phase Commit)、Raft、Paxos、Saga模式等。当两个不同服务之间的状态产生分歧时，我们希望修复状态，使它们保持同等。有两种方法可以修复不同等的状态：同步修复和异步修复。 •同步修复：通过后续的读/写请求来修复不同等的状态。
•异步修复：利用斲丧者、定时任务、表扫描等来发现同等性问题，并修复不同等的状态。我们来看一个同步修复的例子，如图-28所示。
对图-28的具体解释如下。
1.客户端向支付系统发送支付请求。
2.因为这是一个新请求，以是将幂等键插入数据库。
3.将支付状态存储在数据库中。
4.支付系统请求外部PSP来向客户端收款。
5.因为网络错误，支付系统没有收到来自外部PSP的响应。
因此，支付系统不确定支付请求是否已成功实行。

图-28
6.对外部请求的超时被触发，支付系统返回一个可重试的错误给客户端。
7.客户端重试支付来修复潜在的不同等状态。因为之前的状态被存储在数据库中，以是我们可以轻松地从之前停止的地方继续。
8.如果PSP API支持幂等性，我们就会利用相同的幂等键来重试支付。
9.HTTP响应被返回给客户端：要么成功，要么失败。如果一个可重试的错误被返回，客户端会再次重试支付。
网络请求可能不可靠。一个好的做法是当数据库事务处于运动状态时不要发送网络请求。很多公司把一个API请求分为3个阶段：预RPC、RPC和RPC后。RPC（Remote Procedure Call，远程过程调用）是一个协议，它使得应用程序可以向远端服务器发送请求。
•按照这种分阶段的方式，数据库交互应当只发生在预RPC和RPC后阶段。
•网络请求应当只发生在RPC阶段。
另一个好的做法是为外部请求设置一个超时时间，这样系统就不会在外部发生故障时一直等待。
我们来看一个异步修复的例子。如图-29所示，指定的服务器在运行同等性检查的任务。如果检测到任何不同等，异步修复斲丧者会尝试修复。这个过程也叫作支付对账(Payment Reconciliation)，通常是通过匹配内部数据（生意业务日记）和外部数据(PSP)来实现的。

图-29
3.4 处理支付失败

在分布式系统中，故障不仅无法避免而且很常见。每个支付系统都必须处理失败的生意业务。可靠性和容错性是支付系统的关键要求。我们来看几个应对这些挑战的技术：长期化保存支付“状态”、重试队列和死信队列(Dead Letter Queue)。 长期化保持支付“状态”

在支付周期的任何阶段都拥有明白的支付“状态”是至关告急的。这样，当发生故障时，我们就可以确定支付生意业务现在的“状态”，并决定是否需要重试大概退款。支付“状态”可以长期化存储在一个只可追加写的数据库表中。 重试队列和死信队

列为了优雅地应对失败，我们可以利用重试队列和死信队列，如图-30所示。•重试队列：可重试的错误，好比暂时性错误，都被路由到重试队列。•死信队列：如果一个消息一次又一次地失败，它最终就会被放入死信队列中。死信队列很有用，可以调试和隔离有问题的消息，以便手动对其进行检查，确定为什么它们没有被成功处理。

图-30
对图-30的解释如下。
1.对于可重试的失败生意业务，事件被路由到重试队列。
2.对于不可重试的失败，好比不符合规定的输入，会将错误存储到数据库里。
3.支付斲丧者从重试队列里拉取事件。
4.支付斲丧者请求支付系统来实行支付生意业务。
5a.如果支付生意业务失败且重试次数没有凌驾阈值，事件就被路由至重试队列。
5b.如果支付生意业务失败且重试次数凌驾阈值，事件就被路由至死信队列。这些事件可能需要手动检查。
我们需要回答的一个告急问题是：怎样对支付斲丧者实现幂等性。
•给每个事件指派唯一的ID。
•事件在被处理之前存储在长期化存储里。
•唯一的ID用来确保事件只被处理一次。
3.5 支付安全

支付安全正在酿成最严重的问题之一。我们总结了一些用来应对网络攻击和信用卡失窃的技术，如表-3所示。

4 .总结

在本文中，我们讨论了收款流程、付款流程和及时卖家仪表板，深入讨论了重试、幂等性和同等性的话题。在本文的最后，我们还探究了对支付错误的处理和支付安全。支付系统是极度复杂的。尽管我们已经探究了很多话题，但是依然有很多其他值得讨论的话题未涉及。下面列出了一些有代表性的（而非全部的）风趣话题。 •监控。监控关键指标是现代应用至关告急的部分。通过广泛的监控，我们可以回答像“特定支付方法的平均担当度怎样？”“服务器CPU的利用率是多少？”这样的问题。我们可以在仪表板上创建和展示这些指标。
•告警。当异常事件发生的时间，向值班开发人员发出警报，以便其快速响应，这一点很告急。
•调试工具。“支付为什么会失败”是一个经常会被问到的问题。为了让开发人员和客户支持人员进行调试时更容易，开发一些工具是很告急的，因为人们通过这些工具可以直观地看到支付生意业务的生意业务状态、处理服务器、PSP等信息。
•自动扩展。如果你的业务要处理数百万乃至十亿级的生意业务，你会希望你的数据库层、API层、缓存层等能够自动扩展。•货币兑换。货币兑换是设计面向国际用户的支付系统时要考虑的告急因素。
•地理位置。在不同地区，可能有完全不同的支付方式。
•现金支付。在印度、巴西和一些东南亚国家，现金支付非常普遍。设计支付系统时，我们必须考虑现金支付。
•与Google/Apple Pay集成。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。