關於怎麼實現承載更多用戶量的系統，一直是我重點關注的一個技術方向。改造架構提高承載力，通常來講分為兩個大方向，互相配合實現。
硬件架構改進，主要是使用阿里雲這種多組件的雲環境：通過負載均衡SLB，模版克隆的雲服務器ECS，雲數據庫RDS，共享對象存儲OSS等不同職責的雲產品組合實現。
軟件架構優化，主要是軟件代碼開發的規範：業務解耦合，架構微服務，單機無狀態化，文件存儲共享等
在分佈式系統的學習途中也不斷見識新的知識點，今天要說的就是軟件開發時候對於接口服務的“冪等性”實現！
# 冪等性
效果：系統對某接口的多次請求，都應該返回同樣的結果！（網絡訪問失敗的場景除外）目的：避免因為各種原因，重複請求導致的業務重複處理
# 重複請求場景案例：
1，客戶端第一次請求後，網絡異常導致收到請求執行邏輯但是沒有返回給客戶端，客戶端的重新發起請求
2，客戶端迅速點擊按鈕提交，導致同一邏輯被多次發送到服務器
簡單來劃分，業務邏輯無非都可以歸納為增刪改查！
對於查詢，內部不包含其他操作，屬於只讀性質的那種業務必然符合冪等性要求的。對於刪除，重複做刪除請求至少不會造成數據雜亂，不過也有些場景更希望重複點擊提示的是刪除成功，而不是目標不存在的提示。
對於新增和修改，這裡是今天要重點關注的部分：新增，需要避免重複插入；修改，避免進行無效的重複修改；
# 冪等性的實現方式
實現方法：客戶端做某一請求的時候帶上識別參數標識，服務端對此標識進行識別，重複請求則重複返回第一次的結果即可。
舉個栗子：比如添加請求的表單裡，在打開添加表單頁面的時候，就生成一個AddId標識，這個AddId跟著表單一起提交到後臺接口。
後臺接口根據這個AddId，服務端就可以進行緩存標記並進行過濾，緩存值可以是AddId作為緩存key，返回內容作為緩存Value，這樣即使添加按鈕被多次點下也可以識別出來。這個AddId什麼時候更新呢？只有在保存成功並且清空表單之後，才變更這個AddId標識，從而實現新數據的表單提交。
搜索微信號（ID：Java面試那些事兒），可以獲得各類Java面試題、源碼解析、原理講解、IDEA學習指欄。
閱讀更多 憶蓉之心 的文章
