問題描述

程序的邏輯：

程序事先生成了抽獎碼存在mysql中，然后有用戶來的以后，找到一個沒有用過的抽獎碼給他，然后把這個抽獎碼設置成為已經(jīng)使用過了

問題：當大量用戶同時并發(fā)請求的時候，大部分用戶返回同一個抽獎碼

原因大概是這樣子的

select codeid,codevalue from tb_code where isused=0 Limit 1

通過上面的sql找到一個沒有使用過的抽獎碼

update tb_code set isused=1 where codeid=codeid

然后上面的sql語句是更新為已經(jīng)使用

當大量用過過來的時候，比如A先取到一個碼XYBV，但是還沒有更新，B用戶也過來了的時候找到的也是這個碼值了。

code的返回都是在執(zhí)行完update以后返回

后來修改了下更新語句

update tb_code set isused=1 where isused=0 and codeid=codeid

根據(jù)affectedRows來判斷是不是更新成功了，如果成功的話，則返回code，否返回一個null

這樣雖然不會返回重復的值，但是會有一部分收不到碼值

再后來的搜了下，使用直接更新查找到碼值，最后再通過ranomno來查找剛才更新的碼值，如下面所示的sql

update tb_code set isused=1,randomno=’+randomno+’ where codeid in ( select codeid from (select codeid from tb_code where isused=0 Limit 1) as arbitraryTableName)’;

剛開始本地測試的時候，沒有問題，想著解決了。后來上線，檢測日志的時候，發(fā)現(xiàn)很多請求長時間沒有響應，應該是上面的sql語句執(zhí)行的效率太低了。

最后換了一種方法使用redis緩存code

先從庫里面取1000個code使用Lpush放去redis里面去，然后當用戶有請求過來，直接從redis里面取Rpop

然后做一個定時任務，檢測redis里面的code數(shù)量，如果少于設定的數(shù)量，就從庫里面取1000個Lpush到redis里面去

現(xiàn)在項目跑了幾個小時，暫時沒有發(fā)現(xiàn)請求超時的問題和碼值重復的問題。

但是感覺這種方式湊合能用，但不是最好的

想請問大家，對于類似的問題有沒有最佳實踐，比如在數(shù)據(jù)庫設計和程序結構上

問題解答

你可以事先生成所有的code，放redis里，這樣不用一千一千的再去弄了。

你也可以用mongodb,查詢修改數(shù)據(jù)庫并發(fā)性能也挺強的；

可以試試mysql 的事務呢？http://dwz.cn/3SrgGk

抽獎碼即時根據(jù)uid算一個 加一點隨機字符串