接口的幂等性設計

    在高并發或者是安全要求下，後端接口會有多次執行的結果與一次執行的結果要一緻的要求，這種接口就叫幂等性接口，需要用到幂等性的接口比較常見的就是使用者下單支付等，防止出現重試時對業務造成巨大災害的危險。下文為設計方案的各個要點。

前端幂等控制

1. 按鈕隻能點選一次，如使用者點選送出訂單号，按鈕變灰或頁面顯示loding狀态。防止使用者重複點選。
2. 重定向機制，當使用者送出了表單，跳轉到另外一個等待處理的頁面，然後背景處理完成後再跳轉到成功或者失敗的界面。這樣避免使用者按F5重新整理浏覽器導緻重複送出。

​

​

全局唯一ID

    要做到幂等性，就需要借助一個唯一的ID來标志每次交易。唯一ID根據業務情況來定，在執行操作前先根據這個全局唯一ID是否存在，來判斷這個操作是否已經執行。如果不存在則把全局ID，存儲到存儲系統中，比如資料庫、redis等。如果存在則表示該方法已經執行。

    從工程的角度來說，使用全局ID做幂等可以作為一個業務的基礎的微服務存在，在很多的微服務中都會用到這樣的服務，在每個微服務中都完成這樣的功能，會存在工作量重複。另外打造一個高可靠的幂等服務還需要考慮很多問題，比如一台機器雖然把全局ID先寫入了存儲，但是在寫入之後挂了，這就需要引入全局ID的逾時機制。

​

狀态機制控制

    很多時候業務表是有狀态的，比如訂單表中有：1-下單、2-已支付、3-完成、4-撤銷等狀态。如果這些狀态的值是有規律的，按照業務節點正好是從小到大，我們就能通過它來保證接口的幂等性。在更新表時判斷狀态字段是否符合即可，當資料庫更新成功時會傳回影響的行數，這樣就可做後續的成功與否的邏輯處理。

    在作者另一篇文章提到了關于消息隊列如何去重的文章裡，提到的就是用狀态機制來控制的方案，業界通常叫這種方式為重試機制，這裡放個圖。

​

分布式鎖

    分布式鎖的機制跟全局唯一ID是相似的，不過既然是鎖，那就說明同時隻能有一個線程執行同一種操作，對高并發場景是不太适用的，分布式鎖分三種實作方式：資料庫唯一索引、redission、zookeeper，感興趣深入的可自行查找相關資料，這裡就不擴充了。

​

消息隊列

    将請求快速的接收下來，放入消息隊列中，後續消費者服務可自行用邏輯去重。此方法優點是異步處理、高吞吐，不足是不能及時傳回請求結果。