關於怎麼實現承載更多使用者量的系統，一直是我重點關注的一個技術方向。改造架構提高承載力，通常來講分為兩個大方向，互相配合實現。

硬體架構改進，主要是使用阿里雲這種多元件的雲環境：通過負載均衡SLB，模版克隆的雲伺服器ECS，雲資料庫RDS，共享物件儲存OSS等不同職責的雲產品組合實現。

軟體架構優化，主要是軟體程式碼開發的規範：業務解耦合，架構微服務，單機無狀態化，檔案儲存共享等

在分散式系統的學習途中也不斷見識新的知識點，今天要說的就是軟體開發時候對於介面服務的“冪等性”實現！

冪等性

效果：系統對某介面的多次請求，都應該返回同樣的結果！（網路訪問失敗的場景除外）。

目的：避免因為各種原因，重複請求導致的業務重複處理。

重複請求場景案例

1、客戶端第一次請求後，網路異常導致收到請求執行邏輯但是沒有返回給客戶端，客戶端的重新發起請求；

2、客戶端迅速點選按鈕提交，導致同一邏輯被多次傳送到伺服器；

簡單來劃分，業務邏輯無非都可以歸納為增刪改查！

• 對於查詢，內部不包含其他操作，屬於只讀性質的那種業務必然符合冪等性要求的。
• 對於刪除，重複做刪除請求至少不會造成資料雜亂，不過也有些場景更希望重複點選提示的是刪除成功，而不是目標不存在的提示。
• 對於新增和修改，這裡是今天要重點關注的部分：新增，需要避免重複插入；修改，避免進行無效的重複修改；

冪等性的實現方式

實現方法：客戶端做某一請求的時候帶上識別引數標識，服務端對此標識進行識別，重複請求則重複返回第一次的結果即可。

舉個例子：比如新增請求的表單裡，在開啟新增表單頁面的時候，就生成一個AddId標識，這個AddId跟著表單一起提交到後臺介面。

後臺介面根據這個AddId，服務端就可以進行快取標記並進行過濾，快取值可以是AddId作為快取key，返回內容作為快取Value，這樣即使新增按鈕被多次點下也可以識別出來。

這個AddId什麼時候更新呢？只有在儲存成功並且清空表單之後，才變更這個AddId標識，從而實現新資料的表單提交。