冪等性這個概念已經說爛了，就是不管你多少次執行多少次，產生的效果和返回的結果都是一樣的。
1，select操作
在資料不變的情況下，select操作多次查詢到的結果都是冪等的。
2.刪除操作
刪除語句內容不變的情況下，刪除多次的結果也是一樣的。但是得到返回值不是一樣的。
3.唯一索引。
為了新增讀髒資料。比如支付寶的資金賬戶，支付寶允許乙個使用者有乙個支付寶賬戶，就是給資金賬戶表中的使用者id加的唯一索引，所以乙個使用者新增成功乙個資金賬戶記錄。當表中存在唯一索引的時候，併發新增會報錯，再重新查詢一次就可以了。
4.token機制。
防止頁面重複提交。
業務要求：頁面的資料只能被點選提交一次；
發生的原因：由於重複點選或者網路重發，或者nginx重發等情況會導致資料被重複提交；
解決方法：集群建立實用token加上redis（redis是單執行緒的，處理需要排隊）；單jvm環境：採用token加redis或者token加上jvm記憶體。
處理流程：1，資料提交前需要向服務申請token，token梵谷redis或jvm記憶體中，token有效時間。
2，提交後後台檢驗token，同時刪除token生成新token。
token特性：要申請，一次有效性，可以限流。
5.鎖可以使用樂觀悲觀和分布式鎖實現。
高併發情況下如何保證資料的一致性
1.業務層面樂觀鎖cas，使用版本號解決aba問題，實際使用中使用時間戳，更新的時候把查出來的時間戳帶上，如果更新失敗可以自旋，獲取最近值和時間戳，直到更新成功。2.db層面開啟乙個事務，然後select一行for update給這一行加上排它鎖，再去更新行，然後提交，其他事務就會阻塞在select...
高併發情況下 如何支撐大量的請求
幾點需要注意 盡量使用快取，包括使用者快取，資訊快取等，多花點記憶體來做快取，可以大量減少與資料庫的互動，提高效能。用jprofiler等工具找出效能瓶頸，減少額外的開銷。優化資料庫查詢語句，減少直接使用hibernate等工具的直接生成語句 僅耗時較長的查詢做優化 優化資料庫結構，多做索引，提高查...
高併發情況下扣除庫存鎖表情況
toc 1.鎖表情景 查詢條件沒有索引時 總結起來就是兩個嚴重問題 1.扣庫存時沒走索引 2.在事務中，調第三方介面 sql create table gap id int,age int,primary key id select from gap insert into test gap id ...