网站的seo 如何优化,传奇网站怎么做,wordpress 字号,ps网页设计流程原文链接#xff1a;https://medium.com/airbnb-engineering/avoiding-double-payments-in-a-distributed-payments-system-2981f6b070bbAirbnb一直在将其基础架构迁移到面向服务的体系结构(SOA)。 SOA具有许多优势#xff0c;例如使开发人员能够专业化并具有更快迭代的能力。…原文链接https://medium.com/airbnb-engineering/avoiding-double-payments-in-a-distributed-payments-system-2981f6b070bbAirbnb一直在将其基础架构迁移到面向服务的体系结构(SOA)。 SOA具有许多优势例如使开发人员能够专业化并具有更快迭代的能力。 但是这也给计费和支付应用程序带来了挑战因为它使功能更加复杂。对服务的API调用对下游服务进行进一步的API调用其中每个服务都会更改状态并可能产生副作用这等效于执行复杂的分布式事务 。知识卡片SOA把系统按照实际业务拆分成刚刚好大小的、合适的、独立部署的模块每个模块之间相互独立。SOA 重要思想避免业务代码冗余。针对热服务扩展集群缓解压力。服务治理了解调用关系。服务监控和跟踪。rest vs rpc点评微服务的有状态会使得问题变得复杂为了确保所有服务之间的一致性可以使用诸如两阶段提交之类的协议。 如果没有这样的协议分布式事务将对维护数据完整性适度降级以及实现一致性提出挑战。 分布式系统中的请求也不可避免地会失败包括连接将在某个时刻断开并超时尤其是对于包含多个网络请求的事务。知识卡片 二阶段提交。一种基础的分布式事务的实现方法。会有一个主来决定事务是否可以提交 其他随从要提交事务的执行的结果给主。只要有一个节点挂了或者主节点挂了或者有一个从节点事务要回滚整个分布式事务都会以回滚告终。第8章 二阶段提交分布式系统中使用三种不同的通用技术来实现最终的一致性读修复写修复和异步修复。 每种方法都有优点和缺点。 我们的付款系统在所有功能中都使用这三个功能。知识卡片读修复当用户并行读取多个节点时它可以获取到其他过期的值的响应。所以用户会发现其中有些节点拥有过期的值这时用户可以主动将新值写入该节点。这种方法称之为读修复。DDIA 4 复制异步修复服务器负责运行数据一致性检查例如表扫描lambda函数和cron作业。 此外从服务器到客户端的异步通知在支付行业中被广泛使用以强制客户端保持一致。 异步修复和通知可以与读写修复技术结合使用从而提供了第二道防线也要权衡解决方案复杂性。我们在此特定帖子中的解决方案利用写修复其中从客户端到服务器的每个写调用都试图修复不一致的状态。 写修复要求客户端变得更聪明(我们将在稍后进行扩展)并允许客户端重复触发相同的请求而无需维护状态(重试除外)。 客户因此可以按需请求最终的一致性从而使他们可以控制用户的体验。 幂等性是实现写入修复时的一个极其重要的属性。image.png什么是幂等为了使API请求具有幂等性客户端可以重复进行相同的调用并且结果将相同。 换句话说发出多个相同的请求应具有与发出单个请求相同的效果。这项技术通常用于涉及资金流动的记账和支付系统至关重要的一点是付款请求必须完全准确地处理一次(也称为“exactly once”)。 重要的是如果多次调用一次转移资金的操作则基础系统最多应转移一次资金。 这对于Airbnb Payments API至关重要这样可以避免向主机多次付款甚至更糟的是向客人收取多次费用。根据设计幂等性使用API的自动重试机制安全地允许来自客户端的多个相同调用以实现最终的一致性。 这种技术在具有幂等性的客户-服务器关系中很常见并且在今天的分布式系统中也使用了这种技术。点评也就是说如果状态不一致api可以自动重试因为有幂等性的保护我们可以安全的重试(不会产生多次付款之类的问题)最后达到最终一致的效果。下图从高层次上说明了一些简单的示例场景这些场景具有重复的请求和理想的幂等行为。 无论提出多少收费请求客人始终最多只能被收取一次费用。image.png问题陈述确保我们支付系统的最终一致性至关重要。 幂等是在分布式系统中实现此目的的理想机制。 在SOA世界中我们不可避免地会遇到问题。 例如客户端如何恢复当他消费response失败 如果响应丢失或客户端超时怎么办 导致用户两次单击“预订”的竞争条件(race-condition)如何 我们的要求包括以下内容我们需要针对Airbnb的各种Payments SOA服务使用通用但可配置的幂等性解决方案而不是针对特定用例实现单一的定制解决方案。在迭代基于SOA的支付产品时我们不能在数据一致性上妥协因为这将直接影响我们的服务。我们需要极低的延迟因此仅建立一个独立的幂等服务是不够的。 最重要的是该服务将遭受最初打算解决的相同问题。当Airbnb使用SOA扩展其工程组织时让每个开发人员都专注于数据完整性和最终的一致性挑战将是非常低效的。 我们希望避免产品开发人员受到这些干扰从而使他们能够专注于产品开发并加快迭代速度。此外在代码可读性可测试性和故障排除能力方面的重大折衷都被认为是不可行的。总结实现一个幂等性解决方案是通用和可配置。要保证数据的最终一致性。需要极低的延迟(所以不要走网络)。对业务开发人员无感知。不牺牲代码的可读性可测试性和容易排除故障能力。解决方案说明我们希望能够唯一地识别每个传入的请求。 此外我们需要准确跟踪和管理特定请求在其生命周期中的位置。我们在多种支付服务中实施并利用了通用的幂等性库“ Orpheus”。 奥菲斯(Orpheus)是传说中的希腊神话英雄能够精心策划和吸引所有生物。我们选择一个库作为解决方案是因为它提供了低延迟同时仍将高速产品代码与低速系统管理代码之间完全分开。 从高层次上讲它包含以下简单概念幂等键被传递到框架中代表单个幂等请求幂等性信息表始终从分片主数据库读取和写入(出于一致性考虑)使用Java Lambda数据库事务在代码库的不同部分进行组合以确保原子性错误响应分为“可重试”或“不可重试”我们将详细介绍具有幂等性保证的复杂分布式系统如何能够自我修复并最终保持一致。 我们还将介绍解决方案中应注意的一些权衡和其他复杂性。尽量减少数据库提交幂等系统的关键要求之一是仅产生两个结果即成功或失败并且保持一致。 否则数据偏差可能导致数小时的调查和不正确的付款。 因为数据库提供ACID属性所以数据库事务可以有效地用于原子写入数据同时确保一致性。 可以保证数据库提交作为一个单元成功或失败。Orpheus围绕这样一个假设即几乎每个标准API请求都可以分为三个不同的阶段RPC前RPC和RPC后三个阶段。“ RPC”或“远程过程调用”是指客户端向远程服务器发出请求并等待该服务器完成所请求的过程然后恢复其进程。 在支付API的上下文中我们将RPC称为对网络上下游服务的请求该服务可以包括外部支付处理器和收单银行。 简而言之这是每个阶段发生的事情RPC之前付款请求的详细信息记录在数据库中。RPC通过网络使该请求对外部服务生效并收到响应。 在这里可以进行一个或多个幂等计算或RPC(例如如果尝试重试则要先query这个交易的状态)。RPC后来自外部服务的响应的详细信息记录在数据库中包括其成功以及错误请求是否可重试。点评这里有2次落库一次拿到响应。这中间任意点都可发生失败。为了保持数据完整性我们遵守两个简单的基本规则在RPC之前和之后的阶段中没有网络上的服务交互RPC阶段中没有数据库交互我们本质上是想避免将网络通信与数据库工作混合在一起。 我们已经了解了在RPC之前和之后阶段的网络调用(RPC)是脆弱的并且可能导致不良后果(如快速耗尽连接池和降低性能)。简而言之网络呼叫本质上是不可靠的。 因此我们将Pre-RPC和Post-RPC阶段包装在由库本身启动的数据库事务中。我们还想指出一个API请求可能包含多个RPC。 Orpheus确实支持多RPC请求但是在这篇文章中我们仅用简单的单RPC情况来说明我们的思考过程。如下面的示例图所示每个Pre-RPC和Post-RPC阶段中的每个数据库提交都组合到一个数据库事务中。 这样可以确保原子性整个工作单元(此处为Pre-RPC之前和Post-RPC阶段)可以始终失败或成功。这样做的动机是系统应该以可以恢复的方式发生故障。 例如如果几个API请求在长时间的数据库提交过程中失败那么系统地跟踪每个失败发生的位置将非常困难。 请注意所有网络通信(RPC)都与所有数据库事务显式分离。image.png这里的数据库提交包括幂等库提交和应用程序层数据库提交所有这些都合并在同一代码块中。 如果不加小心在实际代码中可能看起来真的很乱。产品开发人员也不应调用某些幂等例程。救星 Java Lambdas幸运的是Java lambda表达式可用于将多个句子无缝地组合到单个数据库事务中而不会影响可测试性和代码可读性。下面是个例子public Response processPayment(InitiatePaymentRequest request, UriInfo uriInfo)throws YourCustomException {return orpheusManager.process(request.getIdempotencyKey(),uriInfo,// 1. Pre-RPC() - {// Record payment request information from the request objectPaymentRequestResource paymentRequestResource recordPaymentRequest(request);return Optional.of(paymentRequestResource);},// 2. RPC(isRetry, paymentRequest) - {return executePayment(paymentRequest, isRetry);},// 3. Post RPC - record response information to database(isRetry, paymentResponse) - {return recordPaymentResponse(paymentResponse);});}public Response process(String idempotencyKey,UriInfo uriInfo,SetupExecutable preRpcExecutable, // Pre-RPC lambdaProcessExecutable rpcExecutable, // RPC lambdaPostProcessExecutable postRpcExecutable) // Post-RPC lambdathrows YourCustomException {try {// Find previous request (for retries), otherwise createIdempotencyRequest idempotencyRequest createOrFindRequest(idempotencyKey, apiUri);Optional responseOptional findIdempotencyResponse(idempotencyRequest);// Return the response for any deterministic end-states, such as// non-retryable errors and previously successful responsesif (responseOptional.isPresent()) {return responseOptional.get();}boolean isRetry idempotencyRequest.isRetry();A requestObject null;// STEP 1: Pre-RPC phase:// Typically used to create transaction and related sub-entities// Skipped if request is a retryif(!isRetry) {// Before a request is made to the external service, we record// the request and idempotency commit in a single DB transactionrequestObject dbTransactionManager.execute(tc - {final A preRpcResource preRpcExecutable.execute();updateIdempotencyResource(idempotencyKey, preRpcResource);return preRpcResource;});} else {requestObject findRequestObject(idempotencyRequest);}// STEP 2: RPC phase:// One or more network calls to the service. May include// additional idempotency logic in the case of a retry// Note: NO database transactions should exist in this executableR rpcResponse rpcExecutable.execute(isRetry, requestObject);// STEP 3: Post-RPC phase:// Response is recorded and idempotency information is updated,// such as releasing the lease on the idempotency key. Again,// all in one single DB transactionS response dbTransactionManager.execute(tc - {final S postRpcResponse postRpcExecutable.execute(isRetry, rpcResponse);updateIdempotencyResource(idempotencyKey, postRpcResponse);return postRpcResponse;});return serializeResponse(response);} catch (Throwable exception) {// If CustomException, return error code and response based on// ‘retryable’ or ‘non-retryable’. Otherwise, classify as ‘retryable’// and return a 500.}}这些关注点的分离确实提供了一些权衡。 开发人员必须使用前瞻性来确保代码的可读性和可维护性因为其他新的代码会不断做出贡献。 他们还需要一致地评估适当的依赖关系和数据传递。 现在需要将API调用重构为三个较小的块这可能会限制开发人员编写代码的方式。 实际上将某些复杂的API调用有效地分解为三步方法可能真的很困难。我们的一项服务已使用StatefulJ在每次转换中实现了有限状态机作为幂等步骤您可以在其中安全地在API调用中复用幂等调用。处理异常-重试还是不重试使用Orpheus这样的框架服务器应该知道何时可以重试请求何时不可以重试。 为此应谨慎处理异常将异常归类为“可重试”或“不可重试”。毫无疑问这给开发人员增加了一层复杂性如果他们不明智和谨慎的话可能会产生不良的副作用。例如假设下游服务暂时处于脱机状态但是当引发的异常本来应该是“可重试的”时被错误地标记为“不可重试”。 该请求将无限期“失败”随后的重试请求将永久返回不正确的不可重试错误。 相反如果在异常本来应该是“不可重试”且需要人工干预的情况下被标记为“可重试”则可能会发生双重支付。通常我们认为由于网络和基础结构问题(5XX HTTP状态)而导致的意外运行时异常是可以重试的。 我们希望这些错误是暂时的并且我们希望以后再次尝试相同的请求最终可能会成功。我们将验证错误(例如无效的输入和状态(例如您无法退回一笔退款))归为不可重试(4XX HTTP状态)我们希望同一请求的所有后续重试都将以相同的方式失败。 我们创建了一个自定义的通用异常类来处理这些情况默认为“不可重试”对于某些其他情况分类为“可重试”。至关重要的是每个请求的请求有PAYLOAD必须保持不变否则将破坏幂等请求的定义。image.png当然还有一些模糊的边缘情况需要谨慎处理例如在不同的上下文中适当地处理NullPointerException。 例如由于连接异常而从数据库返回的null与来自客户端或第三方响应的请求中的错误null字段不同。客户扮演重要角色正如本文开头提到的那样客户端必须在写入修复系统中更精明。 与使用幂等库(例如Orpheus)的服务进行交互时它必须承担几个关键职责为每个新请求传递唯一的幂等密钥 重用相同的幂等密钥进行重试。在调用服务之前将这些幂等性键持久化到数据库中(以后再用于重试)。正确使用成功的响应然后取消赋值幂等密钥。确保重试尝试之间更改请求的payload不被允许。根据业务需求仔细设计和配置自动重试策略(使用指数退避或随机等待时间(“抖动”)以避免惊群问题。知识卡片 惊群问题是计算机科学中当许多进程等待一个事件事件发生后这些进程被唤醒但只有一个进程能获得CPU执行权其他进程又得被阻塞这造成了严重的系统上下文切换代价。如何选择幂等密钥选择一个幂等性密钥至关重要。客户可以根据要使用的密钥选择具有请求级幂等性或实体级幂等性。 决定使用哪一个取决于不同的业务用例但是请求级幂等性是最直接和最常见的。点评 请求级幂等表示这个KEY代表同一个请求。实体级幂等代表这个KEY代表同一个实体。比如我们有一个支付指令这个指令在发RPC时会被赋予一个KEY这个KEY是请求级幂等。这是支付指令本身有一个ID 与一次RPC无关代表它本身的状态是实体级幂等。对于请求级别的幂等性应从客户端选择一个随机且唯一的密钥以确保整个实体集合级别的幂等性。 例如如果我们想为预订房间允许多种不同的付款方式(例如“先付少付”)我们只需要确保幂等性键不同即可。 UUID是一个很好的示例格式。实体级的幂等性比请求级的幂等性要严格得多。 假设我们要确保给定的ID为1234的10美元付款仅能退款5美元因为从技术上讲我们可以两次提出5美元的退款请求。 然后我们希望使用基于实体模型的确定性幂等性关键字以确保实体级别的幂等性。 示例格式为“ payment-1234-refund”。 因此每笔要求退款对唯一PAYMENT在实体级别(payment id1234)都是幂等的。每个API请求都有一个到期的租约由于多次用户单击或客户端具有积极的重试策略可能会触发多个相同的请求。这可能会在服务器上造成竞争状况或者为我们的产品加倍付款。为了避免这些情况API调用在框架的帮助下每个都需要获得对幂等键的数据库行级锁。这将授予给定请求以进一步进行其他事情的租约。租约附带一个到期时间以涵盖服务器端超时的情况。如果没有响应则仅在当前租约到期后才能重试API请求。应用程序可以根据需要配置租约到期和RPC超时。一个好的经验法则是其租约到期时间要比RPC超时时间长。点评 RPC超时之后租约没超时可以有效防止客户端的积极重试策略带来的竞争情况。Orpheus还为幂等KEY提供了一个最大的可重试窗口以提供一个安全网从而避免了由于系统意外行为而导致的恶意重试点评限制一个时间窗口内的最多重试次数。记录Response我们还记录响应以维护和监视幂等行为。 当客户对已达到确定性最终状态的事务提出相同的请求时例如不可重试的错误(例如验证错误)或成功的响应该响应将记录在数据库中。持久化response确实需要在性能上进行权衡客户能够在后续重试中获得快速回复因为幂等结果已经落库。但是存响应的表的增长与应用程序吞吐量的增长成比例。 如果我们不小心的话这张表很快会变得臃肿。 一种可能的解决方案是定期删除早于特定时间范围的行但是过早删除幂等响应也会产生负面影响。 开发人员还应该警惕不要对响应实体和结构进行向后不兼容的更改。避免副本数据库-坚守master使用Orpheus读写等幂信息时我们选择直接从master数据库中进行。在分布式数据库系统中要在一致性和延迟之间进行权衡。由于我们无法忍受高延迟或读取未提交的数据因此对这些表使用master是最有意义的。这样做无需使用缓存或数据库副本。如果未将数据库系统配置为具有强读取一致性(我们的系统由MySQL支持)则从等幂角度来看对这些操作使用副本实际上会产生不利影响。例如假设支付服务将其幂等信息存储在副本数据库中。客户向该服务提交了付款请求该请求最终在下游成功完成但是由于网络问题该客户未收到响应。当前存储在服务的主数据库中的响应最终将被写入副本。但是在副本滞后的情况下客户端可以正确地对服务发起幂等重试并且响应尚未记录到副本中。因为响应“不存在”(在副本上)所以该服务可能会错误地再次执行付款从而导致重复付款。下面的示例说明了复制延迟仅几秒钟如何对Airbnb社区造成重大财务影响。image.png点评网络超时副本同步超时造成重试的那次没有被幂等造成重复打款。只存在MASTER解决了这个问题image.png当使用单个主数据库进行幂等时很明显毫无疑问扩展无疑会成为一个问题。 我们通过使用幂等键对数据库进行分片来缓解这种情况。 我们使用的幂等密钥具有高基数和均匀分布使其成为有效的分片密钥。最后的想法有许多不同的解决方案可以缓解分布式系统中的一致性挑战。 Orpheus是适用于我们的几个组件之一因为它具有通用性和轻巧性。开发人员在使用新服务时可以简单地导入该库并且幂等逻辑保存在特定于应用程序的概念和模型之上的单独的抽象层中。但是要实现最终的一致性就必须引入一些复杂性。客户需要存储和处理幂等密钥并实现自动重试机制。开发人员需要更多的上下文并且在实施Java lambda并对其进行故障排除时必须具有外科手术的精确性。在处理异常时它们必须是深思熟虑的。此外由于Orpheus的当前版本经过了实战测试我们不断发现需要改进的地方重试请求payload匹配对模式更改和嵌套迁移的改进支持在RPC阶段积极限制数据库访问等等。虽然这些是最重要的考虑因素但到目前为止Orpheus在哪里获得了Airbnb Payments自该框架启动以来我们的付款一致性达到了五个九而我们的年度付款量同时翻了一番(如果您想了解有关我们如何大规模衡量数据完整性的信息请阅读此信息)。我的思考与启示了解了实现最终一致性的3个手段读修复异步修复写修复。异步修复可以做第二道防线。低延迟的幂等LIBRARY设计把幂等的框架统一化。抽象出一个支付请求的模板使得RPC前后的数据库操作以优雅的方式写进一个事务。为了解决支付业务的复杂性和框架的简单性之间的GAP运用STATEFUL J这个工具来实现。RETRY 和NOT RETRY的情况和显式回传给客户端。实体级幂等和请求级幂等为了避免不一致采用只在MASTER上操作而选取高基数的幂等KEY 和 做分片以缓解压力。避免惊群效应需要指数回退或者随机等待的重试策略幂等KEY的租约和底层框架的最大重试窗口 来保护系统不会HANDLE很多无用的请求。