12.26 Day 11 - 弹力设计篇之“幂等性设计”

大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 11 天，也是我第 11 次进行打卡这种操作。

今天我温习了该专栏里一篇叫《弹力设计篇之“幂等性设计”》的文章。

关键词总结：幂等性（作用）、幂等性方案（上游系统负责、下游系统负责）、全局 ID、幂等性处理流程、HTTP 幂等性（GET、HEAD、OPTIONS、DELETE、POST、PUT）、幂等性设计（PRG 模式）。

 

所学总结：

 

幂等性

作用

确保一个资源无论被访问多少次，其结果都是一样的。
 

幂等性方案

上游系统负责

上游系统在丢失与下游系统之间建立的连接之后通过下游系统所提供的验证接口来检查结果的正确性，确保结果和预想的一致。

下游系统负责

下游系统不管接收到多少次相同的请求，它对特征一样的多个请求，只做一次处理，幂等性设计将避免出现重复处理相同请求的现象。
 

全局 ID

可以借助由 Twitter 开源的基于全局唯一 ID 算法实现的分布式 ID 生成算法项目 Snowflake。它所产生的 ID 对应了 long 类型。其结构如下：

• 前 41 位：毫秒数，需要 69.7 年到达上线。
• 中 10 位：机器编号（前 5 位是数据中心，后 5 位是机器编号），支持 1024 个实例。
• 后 12 位：毫秒内序列号。每毫秒 4096 个序号。

Redis 和 MongoDB 的算法与 Snowflake 类似。
 

幂等性处理流程

在没有查询到对应数据的情况下，我们才进行处理操作，如果之前有做过处理则直接返回处理完的结果。

不会产生副作用的 SQL 更新方式：
update table set status = ‘paid’
where id = xxxxx
and status = ‘unpaid’;

我们需要一个分布式的存储系统，专门用来提供幂等性服务。这个系统可以是基于关系型数据库，或者 MongoDB 这样的高性能 NoSQL 数据库。
 

HTTP 幂等性

GET

• 类型：幂等
• 副作用：无
• 原因：获取接口返回的 Header 和 Body 数据，每次调用的结果都相同。

HEAD

• 类型：幂等
• 副作用：无
• 原因：获取接口返回的 Header 数据，每次调用的结果都相同。

OPTIONS

• 类型：幂等
• 副作用：无
• 原因：获取接口所支持的 HTTP 方法，每次调用的结果都相同。

DELETE

• 类型：幂等
• 副作用：有
• 原因：用于删除数据，每次调用的结果都相同。

POST

• 类型：不幂等
• 副作用：有
• 原因：用于创建数据，每次调用的 URI 不同。
• 解决办法：在表单里嵌入一个 token，检测到 token 存在则不做处理。处理完毕后做 302 重定向到成功页面。

PUT

• 类型：幂等
• 副作用：有
• 原因：用于创建或更新数据，每次调用的结果相同。
   

幂等性设计

PRG 模式

通常，在调用 post 请求处理完毕之后比较保险的做法是，做一个 302 重定向，到达跳转之后的页面显示出刚刚创建的数据。这种设计方式叫“创建/重定向/获取”，也即 Post/Redirect/Get（PRG 模式）。
 

末了

重新总结了一下文中提到的内容：幂等性含义、幂等性副作用（不取决于调用次数）、服务调用结果（成功、失败、超时）、可能产生不幂等的问题（超时）、幂等性方案（轮询处理结果、下游系统做幂等处理）、分布式系统幂等性（Snowflake 全局 ID）、幂等性接口处理流程。