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

時間：2021-09-30 13:49:14

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

手機(jī)看文章

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

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

為什么需要保證冪等性

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

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

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

唯一ID

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

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

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

UUID

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

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

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

Snowflake

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

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

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

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

共享存儲

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

避免不必要的查詢

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

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