1.使用者短時間內提交次數過多導致的重複提交 

　　　同一條資料被使用者點選了多次，導致資料冗餘，需要防止弱網路等環境下的重複點選，復點選是指在指定的時間段內多次點選按鈕。

　　解決方案:通過將該次操作的唯一標識作為key存入redis,如果在規定時間內該key依然存在的話則代表重複提交

2.為什麼需要分散式鎖？（Redis分散式鎖）

　　參考連結 https://blog.csdn.net/weixin_39704078/article/details/86508137

　　　　　　https://blog.csdn.net/qq_42617455/article/details/115400004

　　2.1 使用lua+redis的方法。之所以使用lua是為了保證原子性

 3.Oauth2協議 進行請求介面之前的授權

• 共享Cache ，不怕丟資料，丟了可以從DB中reload；
• 共享Session ，不怕丟資料，丟了可以重新登入；
• batch job的中間結果。不怕丟資料，丟了重新跑job就可以了；
• 一些簡單資料的儲存，低頻改動，但是會被頻繁讀取。比如首頁推薦的產品列表。但此時必須增加HA的防護，sentinel、cluster或者自定義的機制都可以；
• 一些更加複雜儲存的building block，比如分散式鎖，此時需要多節點來實現一個簡單的quorum

其他場景，往往有更好的、更成熟的方案。

特別注意，不要用Redis儲存任何需要“認真對待”的資料，請用支援ACID事務的資料庫。

Redis是非常優秀的工具，但非是銀彈。只有認真的瞭解業務對“保證”的要求，認真的瞭解所用工具的工作原理，才能做出正確的設計決策。

5.Redis特點：

1、Redis是純記憶體操作，需要的時候需要我們手動持久化到硬碟中

2、Redis是單執行緒，從而避開了多執行緒中上下文頻繁切換的操作。

3、Redis資料結構簡單、對資料的操作也比較簡單

4、使用底層模型不同，它們之間底層實現方式以及與客戶端之間通訊的應用協議不一樣，Redis直接自己構建了VM 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求

5、使用多路I/O複用模型，非阻塞I/O

5.分散式環境使用redis防止重複提交

 思路：自定義註解+spring aop+redis分散式鎖

demo

轉載於:https://my.oschina.net/u/3734816/blog/3030940

• 中文（簡體）
• 中文（繁體）
• 丹麥語
• 烏克蘭語
• 烏爾都語
• 亞美尼亞語
• 俄語
• 保加利亞語
• 克羅埃西亞語
• 冰島語
• 加泰羅尼亞語
• 匈牙利語
• 卡納達語
• 印地語
• 印尼語
• 古吉拉特語
• 哈薩克語
• 土耳其語
• 威爾士語
• 孟加拉語
• 尼泊爾語
• 布林語(南非荷蘭語)
• 希伯來語
• 希臘語
• 庫爾德語
• 德語
• 義大利語
• 拉脫維亞語
• 挪威語
• 捷克語
• 斯洛伐克語
• 斯洛維尼亞語
• 旁遮普語
• 日語
• 普什圖語
• 毛利語
• 法語
• 波蘭語
• 波斯語
• 泰盧固語
• 泰米爾語
• 泰語
• 海地克里奧爾語
• 愛沙尼亞語
• 瑞典語
• 立陶宛語
• 緬甸語
• 羅馬尼亞語
• 寮國語
• 芬蘭語
• 英語
• 荷蘭語
• 薩摩亞語
• 葡萄牙語
• 西班牙語
• 越南語
• 亞塞拜然語
• 阿姆哈拉語
• 阿爾巴尼亞語
• 阿拉伯語
• 韓語
• 馬爾加什語
• 馬拉地語
• 馬拉雅拉姆語
• 馬來語
• 馬耳他語
• 高棉語