如何避免重復(fù)提交？分布式服務(wù)的冪等性設(shè)計(jì)！

時(shí)間：2021-09-30 13:49:14

關(guān)鍵字：分布式

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]原文：www.cnblogs.com/QG-whz/p/10372458.html為什么需要保證冪等性編程中的“冪等性”是指任意多次執(zhí)行所產(chǎn)生的影響，與一次執(zhí)行的影響相同。一個(gè)擁有冪等性設(shè)計(jì)的接口，保證無論一次或多次來調(diào)用接口，都能夠得到相同的結(jié)果。接口的冪等性設(shè)計(jì)在某些場景下是...

為什么需要保證冪等性

編程中的“冪等性”是指任意多次執(zhí)行所產(chǎn)生的影響，與一次執(zhí)行的影響相同。一個(gè)擁有冪等性設(shè)計(jì)的接口，保證無論一次或多次來調(diào)用接口，都能夠得到相同的結(jié)果。接口的冪等性設(shè)計(jì)在某些場景下是必需的，例如用戶下單的場景。
我們知道，服務(wù)之間的調(diào)用存在三種狀態(tài)：成功、失敗、超時(shí)。超時(shí)是一種未知的狀態(tài)：被調(diào)服務(wù)是否執(zhí)行成功，這個(gè)狀態(tài)是未知的。上游服務(wù)調(diào)用下游服務(wù)超時(shí)時(shí)可能會(huì)進(jìn)行重試。對(duì)于用戶下單的場景的超時(shí)重試我們考慮以下問題：

是否會(huì)導(dǎo)致最終創(chuàng)建了兩條一樣的訂單？
是否會(huì)扣除兩遍庫存？
是否會(huì)重復(fù)扣除用戶的錢？

如果每一筆訂單都攜帶唯一的序號(hào)，下單接口可以借助這個(gè)序號(hào)，來記錄某次下單操作的狀態(tài)。當(dāng)下單的狀態(tài)為成功時(shí)，就將重復(fù)的執(zhí)行攔截住，避免出現(xiàn)上述的問題。這種方式是由下游被調(diào)方來保證冪等性。
除此之外，訂單服務(wù)也可以提供查詢訂單狀態(tài)的接口，上游在下單之前先進(jìn)行查詢，確認(rèn)該筆訂單并沒有成功支付后，再重復(fù)進(jìn)行下單操作。
一般來說，服務(wù)本身需要自己保證冪等性，而不應(yīng)該將冪等性交給上游的調(diào)用方來做。

唯一ID

就上面的冪等性下單接口來說，要做到冪等性，就需要借助一個(gè)唯一的ID來標(biāo)志每次交易。唯一ID的分配可以有幾種方式：

由一個(gè)統(tǒng)一的ID分配中心來分配。
由上游服務(wù)來生成唯一ID，但必須保證不產(chǎn)生沖突的ID。

采用統(tǒng)一的分配中心來分配唯一ID時(shí)，業(yè)務(wù)方每次調(diào)用接口都多了一次調(diào)用分配中心獲取唯一ID的請(qǐng)求。這多了額外的開銷。獲取唯一ID有一種方式，是借助mysql的自增索引，這其實(shí)也是一個(gè)ID分配中心。對(duì)服務(wù)性能有苛刻要求時(shí)，可以采用第二種方式，由主調(diào)服務(wù)本身來生成這個(gè)唯一ID。為了保持不會(huì)產(chǎn)生重復(fù)的ID，可以使用一下幾種ID生成方法：

UUID

UUID的全稱是Universally Unique Identifier，通用唯一識(shí)別碼。具體可以看維基百科的介紹：https://en.wikipedia.org/wiki/Universally_unique_identifier
UUID是一個(gè)128bit的數(shù)字，用于標(biāo)志計(jì)算機(jī)的信息，雖然UUID不能保證絕對(duì)不重復(fù)，但重復(fù)的概率小到可以被忽略。UUID的生成沒有什么規(guī)律，為了保證UUID的唯一性，規(guī)范定義了包括網(wǎng)卡MAC地址、時(shí)間戳、名字空間（Namespace）、隨機(jī)或偽隨機(jī)數(shù)、時(shí)序等元素，以及從這些元素生成UUID的算法。這也就意味著：

128bit，占據(jù)了太多的內(nèi)存空間
生成的ID不是人可以看懂的
無法保證ID的遞增，某些場景需要按前后排序無法滿足。

這是一個(gè)在線生成UUID的網(wǎng)站：https://www.uuidgenerator.net/ 你可以直觀感受一下UUID。

Snowflake

這是Twitter的一個(gè)開源項(xiàng)目，它是一個(gè)分布式ID的生成算法，它會(huì)產(chǎn)生一個(gè)long類型的唯一ID，其核心算法是：

時(shí)間部分：41bit作為毫秒數(shù)，大概可以使用69.7年
機(jī)器編號(hào)部分：10bit作為機(jī)器編號(hào)，支持1024個(gè)機(jī)器實(shí)例。
毫秒內(nèi)的序列號(hào)：12bit，一毫米可以生成4096個(gè)序列號(hào)

網(wǎng)上有各種語言實(shí)現(xiàn)的Snowflake算法的實(shí)現(xiàn)，有興趣的閱讀一下實(shí)現(xiàn)代碼。
實(shí)際上，redis 或是 mongoDB 的全局ID生成器的算法和Snowflake算法大同小異。這是基于redis的分布式ID生成器實(shí)現(xiàn)：https://github.com/hengyunabc/redis-id-generator
它的核心思想是：

使用41 bit來存放時(shí)間，精確到毫秒，可以使用41年。
使用12 bit來存放邏輯分片ID，最大分片ID是4095
使用10 bit來存放自增長ID，意味著每個(gè)節(jié)點(diǎn)，每毫秒最多可以生成1024個(gè)ID

共享存儲(chǔ)

如果我們的冪等性服務(wù)是分布式的，那么存儲(chǔ)唯一ID也需要采用共享的存儲(chǔ)，這樣每個(gè)服務(wù)就是無狀態(tài)的了?？梢允褂胢ysql來存儲(chǔ)，也可以使用k- v存儲(chǔ)例如redis。我在自己的業(yè)務(wù)中就采用了redis來存儲(chǔ)唯一key。

避免不必要的查詢

并不是所有的請(qǐng)求都是重復(fù)的，生產(chǎn)環(huán)境下可能99%的請(qǐng)求都不是重復(fù)請(qǐng)求。如果每個(gè)請(qǐng)求在執(zhí)行前都要去查詢下唯一ID是否存在，可能會(huì)帶來不必要的性能消耗。如果你使用mysql來存儲(chǔ)唯一ID，那么可以直接進(jìn)行insert，通過結(jié)果來判斷是否插入記錄成功，如果不成功則證明ID已經(jīng)存在：

insert into ... values ... on DUPLICATE KEY UPDATE ...
而如果使用的是redis，也可以使用redis的setEx，設(shè)置成功則證明key不存在，否則key存在說明是重復(fù)請(qǐng)求。