最近在負責一個禮品卡模塊，就是用返利獲得的余額，在APP端兌換不同面值的禮品卡，用于購物使用，類似于現金券。業務很簡單
，流程很簡單，但是查詢更新操作有好幾個，可以肯定的是這些操作必須要在一個事務執行，失敗必須回滾的。剛開始做的時候傻傻的以為同一個事務并發問題也不會有。功能做完之后，寫了個測試用例，啟20個線程同事去兌換禮品卡，結果發現有同一張禮品卡被兌換多次的問題。很明顯的并發問題，多個線程獲取到同一張未兌換的禮品卡。這個問題的原因是先查數據庫獲取未兌換的卡，這種做法肯定是不太好，即使同步去做，也需要進行一次查庫，非常不必要。設想在禮品卡導入的時候，可以把禮品卡放入一個池子中，每次兌換的時候取走一個，這個方式還是比較好實現的，前提池子肯定也得保證線程安全。
廢話了挺多，還是接著說下剛剛的問題，首先想到了jvm的同步方法，然后在方法或者需要同步的代碼塊上加上synchronized，然后還是開啟20個線程繼續測試，想象挺好，但是突然發現剛剛的問題怎么還是存在。一開始有點百思不得其姐。?？瓤?，是解，不要想遠了。都已經同步了，為什么還是會出現這種情況呢。想了想突然意識到，不管是同步代碼塊，還是同步方法，都是在@Transactional注解的方法下。線程釋放鎖的時候，也許AOP的事務處理，并未提交成功，然后另一個線程就拿到了鑰匙。獲取到了上個事務同一個未兌換的禮品卡，導致了這個現象出現。隨即又寫了個方法，在方法中寫上同步代碼塊，調用事務方法，結果沒有出現上面的情況。感覺猜想應該是正確的吧。。
問題雖然解決了一些，但是另一個問題接著就來了。。預生產，線上并非部署一個實例，如果使用jvm的同步方法，還是有一定幾率出現并發問題，這就想到了分布式鎖。之前一直聽說，也沒有實現過，馬上網上搜羅了一下。
一般的解決方案如下：
- zookeeper分布式鎖，基于自增節點
- memcache分布式鎖，基于add函數
- Redis分布式鎖，基于setnx命令【本次使用】
說下分布式鎖的基本功能：
- 同一時刻只能存在一個鎖
- 需要解決意外死鎖問題，也就是鎖能超時自動釋放
- 支持主動釋放鎖
下面說下我的實現思路，通過注解的方式，定義方法注解，然后通過Spring 的AOP方式，在方法執行前加鎖，方法執行后釋放鎖。
使用框架：
springboot + redis 集群
具體代碼如下：
1.編寫方法注解
在方法上使用此注解，就會被AOP攔截，并進行加鎖處理。
2.編寫方法參數上的注解
該注解的作用，主要是影響redis中鎖的key。
3.在需要調用的方法使用注解
我這里使用的模塊禮品卡，然后redis的鎖的輪訓時間為5s。用禮品卡的庫存ID，當做唯一鎖key。這樣做，不同庫存ID，或者說不同類型的禮品卡就是不同的鎖，也會提高一些并發。
4.spring AOP 攔截是實現
這里主要做的就是獲取獲取注解的值，和注解的參數的值，然后創建鎖對象獲取鎖。然后執行方法，最后在finally中釋放鎖。還是很簡單的
5.redis獲取鎖的主要實現
這里通過不斷的輪詢，從redis獲取鎖。如果未獲取到，怎返回false,業務處獲取false直接拋異常。主要是通過redis的setNx方法實現分布式鎖。刪除鎖的代碼很簡單，就是del，這里不展示了。
這里只是簡單的實現了下，后續再繼續完善。
