支付核心系统设计：Airbnb的分布式事务方案简介( 五 ) _Airbnb

例如，假设支付服务将其幂等信息存储在从库中。客户端向支付服务提交付款请求，该请求最终成功，但客户端由于网络问题而未收到响应。虽然当前存储在服务主库中的响应最终将最终写入从库，但是，由于有同步延迟，客户端可能会进行重试，由于同步延迟，服务可能会错误地再次执行付款，从而导致重复付款。下面的例子说明了仅仅几秒钟的复制延迟可能会对Airbnb造成重大财务影响。

文章插图
由于复制延迟导致重复支付

文章插图
使用主库避免重复支付
当使用单个主数据库保证幂等性时，可伸缩性会成为主要问题。我们通过按照幂等键对数据库进行分片来缓解这个问题。我们使用的幂等键具有高基数和均匀分布，使分片更加高效。

最后的想法许多解决方案都可以缓解分布式系统中的一致性挑战。Orpheus是适用于我们的几种产品之一，因为它具有普遍性和轻量级这样的特性。开发人员可以在使用新服务时简单地导入类库，并且将幂等逻辑保存在独立于应用程序之外的单独的抽象层。
如果不引入一些复杂性，就不可能实现最终的一致性。客户端需要存储和处理幂等键并实现自动重试机制。开发人员需要额外的上下文，并且在实现Java lambda时必须如外科外科手术一样精确。处理异常时必须慎重。此外，由于当前版本的Orpheus经过了实战考验，我们也在不断寻找改进之处：改进请求负载匹配以便进行重试，改进对数据库模式更改和嵌套迁移的支持，在RPC阶段主动限制数据库访问等等。
原文地址：
https://medium.com/airbnb-engineering/avoiding-double-payments-in-a-distributed-payments-system-2981f6b070bb
本文由方圆翻译。转载本文请注明出处，欢迎更多小伙伴加入翻译及投稿文章的行列，详情请戳公众号菜单「联系我们」。

【支付核心系统设计：Airbnb的分布式事务方案简介】