跳转到主要内容

如何使用幂等性设计出高可靠的API?

阅读需 1 分钟Tian PanTian Pan

为什么API会不可靠?

  1. 网络会出错
  2. 服务器会出错

怎么解决这个问题呢?三个原则

  1. 客户端用“重试”来保证状态的一致性

  2. 重试的请求里要有==幂等的唯一性ID==

    1. 在 RESTful API 设计里面,PUT 和 DELETE 的语义本身是幂等的
    2. 但是 POST 在在线支付领域可能会导致==“重复付两次钱”的问题==,所以我们用“幂等的唯一性ID”来识别某个请求是否被发了多次
      1. 如果错误发生在到达服务器之前,重试过后,服务器第一次见到它,正常处理
      2. 如果错误发生在服务器,基于这个“唯一性ID”,用 ACID 的数据库保证这个事务只发生一次
      3. 如果错误发生在服务器返回结果之后,重试过后,服务器只需要返回缓存过的成功的结果
  3. 重试要负责任,比如遵循==指数退避算法==,因为不希望一大波客户端同时重试。

举个例子,Stripe 的客户端是这样计算重试的等待时间的:

def self.sleep_time(retry_count)
  # Apply exponential backoff with initial_network_retry_delay on the
  # number of attempts so far as inputs. Do not allow the number to exceed
  # max_network_retry_delay.
  sleep_seconds = [Stripe.initial_network_retry_delay * (2 ** (retry_count - 1)), Stripe.max_network_retry_delay].min
 
  # Apply some jitter by randomizing the value in the range of (sleep_seconds
  # / 2) to (sleep_seconds).
  sleep_seconds = sleep_seconds * (0.5 * (1 + rand()))
 
  # But never sleep less than the base sleep seconds.
  sleep_seconds = [Stripe.initial_network_retry_delay, sleep_seconds].max
 
  sleep_seconds
end

参考资料

保持联系,关注我获取更多内容

阅读需 3 分钟

一亿美元的遥测错误:OpenAI 的故障教会我们系统设计的知识

OpenAI 最近的故障揭示了现代系统设计的重要见解,突显了保障措施如何无意中成为风险。了解这一亿美元的遥测错误的教训,以及它们如何适用于你自己的技术基础设施。

OpenAI
system design
阅读需 7 分钟

如何设计区块链服务端的架构?

分布式的区块链记账和智能合约系统。要求节点之间不大信任,但是却激励他们互相合作:交易不可逆,不依赖可信的第三方,保护隐私,透露最少信息,一笔钱不能花两次。假设性能不是问题,暂不考虑如何优化性能。

system design
阅读需 4 分钟

快速介绍 Optimism 架构

什么是 Optimism?它的架构是什么样的?它的构建组件是什么,它们之间如何相互作用?

system design
阅读需 9 分钟

设计以人为本的国际化(i18n) 工程方案

硅谷公司的产品大多面向全球市场,而国际化正是跨国公司征战全球市场的战略要地。我们这次设计的 i18n 工程方案主要是解决网站和移动 App 开发过程中的三大问题:1. 语言、2. 时间与时区、3. 数字与货币。如同一切软件系统的开发一样,国际化这件事情没有银弹,好的作品都是靠基本功一点一滴磨出来的。

system design
阅读需 3 分钟

设计负载均衡器

互联网服务往往要处理来自全世界的流量,但是,一个服务器只能够同时服务有限数量的请求。因此,通常我们会有一个服务器集群来共同处理这些流量。那么问题来了,怎样才能够让这些流量均匀地分布到不同的服务器上呢?

system design