冪等性需要唯一的業務訂單號來保證，插入類介面
1.先select後insert——>再引數校驗是否支付過——>在執行支付；
缺點：1多一次select，高併發下效能低；
2.由於是兩個操作，不具備原子性，存在事務問題，需要加@transaction
2.樂觀鎖
只適合update類介面；
sql如下
update t_g7_test
age=#,
state=1
where id=# and state=0
3.mysql唯一索引
4.利用redis的原子性實現分布式鎖 將orderid作為key，setnx成功這進行insert/update，
5.或者支付系統使用uuid-生成token響應給訂單系統，並把token放在redis中，訂單系統依據此token來實現
這裡就不光要考慮集群高併發了，還需要路由策略，將orderid經過hash保證每次落到同乙個表中；比如mycat配置路由演算法函式
idrang-long
如何讓訂單服務具備冪等性？
先解釋下什麼叫冪等性 原本是數學上的概念，即使公式 f x f f x 能夠成立的數學性質。用在程式設計領域，則意為對同乙個系統，使用同樣的條件，一次請求和重複的多次請求對系統資源的影響是一致的。1.乙個冪等的建立訂單服務，無論建立訂單的請求傳送多少次，正確的結果是，資料庫只有一條新建立的訂單記錄。...
原子性 冪等性
原子性 如果這個操作所處的層 layer 的更高層不能發現其內部實現與結構，那麼這個操作是乙個原子 atomic 操作。原子操作可以是乙個步驟，也可以是多個操作步驟，但是其順序不可以被打亂，也不可以被切割而只執行其中的一部分。將整個操作視作乙個整體是原子性的核心特徵。冪等性 再簡單一點說，在乙個業務...
冪等性學習及介面的冪等性
冪等性學習 一 什麼是冪等性 在這裡需要有以下幾個問題需要注意 2 冪等性不僅僅只是一次或者多次請求的時候對資源沒有 比如根據id對資料庫的查詢操作，此操作對資料庫沒有增刪改，所以多次查詢操作對資料庫結果是沒有任何影響的 3 冪等性還包括了第一次請求資源的時候，對資源產生了 但是在以後多次同樣的請求...