redis抽奖并发_Redis优化高并发下的秒杀性能
本文內容
使用Redis優化高并發場景下的接口性能
數據庫樂觀鎖
隨著雙11的臨近，各種促銷活動開始變得熱門起來，比較主流的有秒殺、搶優惠券、拼團等等。
涉及到高并發爭搶同一個資源的主要場景有秒殺和搶優惠券。
前提
活動規則
獎品數量有限，比如100個
不限制參與用戶數
每個用戶只能參與1次秒殺
活動要求
不能多發，也不能少發，100個獎品要全部發出去
1個用戶最多搶1個獎品
遵循先到先得原則，先來的用戶有獎品
數據庫實現
悲觀鎖性能太差，本文不予討論，討論一下使用樂觀鎖解決高并發問題的優缺點。
數據庫結構
未中獎時UserId為0，RewardAt為NULL
中獎時UserId為中獎用戶ID，RewardAt為中獎時間
樂觀鎖實現
樂觀鎖實際上并不存在真正的鎖，樂觀鎖是利用數據的某個字段來做的，比如本文的例子就是以UserId來實現的。
實現流程如下：
1.查詢UserId為0的獎品，如果未找到則提示無獎品
SELECT*FROMenvelopeWHEREuser_id=0?LIMIT?1
2.更新獎品的用戶ID和中獎時間(假設獎品ID為1，中獎用戶ID為100，當前時間為2019-10-29 12:00:00)，這里的user_id=0就是我們的樂觀鎖了。
UPDATEenvelopeSETuser_id=100,?reward_at='2019-10-29?12:00:00'WHEREuser_id=0ANDid=1
3.檢測UPDATE語句的執行返回值，如果返回1證明中獎成功，否則證明該獎品被其他人搶了
為什么要添加樂觀鎖
正常情況下獲取獎品、然后把獎品更新給指定用戶是沒問題的。如果不添加user_id=0時，高并發場景下會出現下面的問題：
兩個用戶同時查詢到了1個未中獎的獎品(發生并發問題)
將獎品的中獎用戶更新為用戶1，更新條件只有ID=獎品ID
上述SQL執行是成功的，影響行數也是1，此時接口會返回用戶1中獎
接下來將中獎用戶更新為用戶2，更新條件也只有ID=獎品ID
由于是同一個獎品，已經發給用戶1的獎品會重新發放給用戶2，此時影響行數為1，接口返回用戶2也中獎
所以該獎品的最終結果是發放給用戶2
用戶1就會過來投訴活動方了，因為抽獎接口返回用戶1中獎，但他的獎品被搶了，此時活動方只能賠錢了
添加樂觀鎖之后的抽獎流程
更新用戶1時的條件為id=紅包ID AND user_id=0 ,由于此時紅包未分配給任何人，用戶1更新成功，接口返回用戶1中獎
當更新用戶2時更新條件為id=紅包ID AND user_id=0，由于此時該紅包已經分配給用戶1了，所以該條件不會更新任何記錄，接口返回用戶2中獎
樂觀鎖優缺點
優點
性能尚可，因為無鎖
不會超發
缺點
通常不滿足“先到先得”的活動規則，一旦發生并發，就會發生未中獎的情況，此時獎品庫還有獎品
壓測
在MacBook Pro 2018上的壓測表現如下(Golang實現的HTTP服務器,MySQL連接池大小100，Jmeter壓測)：
500并發 500總請求數 平均響應時間331ms 發放成功數為31 吞吐量458.7/s
Redis實現
可以看到樂觀鎖的實現下爭搶比太高，不是推薦的實現方法，下面通過Redis來優化這個秒殺業務。
Redis高性能的原因
單線程 省去了線程切換開銷
基于內存的操作 雖然持久化操作涉及到硬盤訪問，但是那是異步的，不會影響Redis的業務
使用了IO多路復用
實現流程
1.活動開始前將數據庫中獎品的code寫入Redis隊列中
2.活動進行時使用lpop彈出隊列中的元素
3.如果獲取成功，則使用UPDATE語法發放獎品
UPDATErewardSETuser_id=用戶ID,reward_at=當前時間WHEREcode='獎品碼'
4.如果獲取失敗，則當前無可用獎品，提示未中獎即可
使用Redis的情況下并發訪問是通過Redis的lpop()來保證的，該方法是原子方法，可以保證并發情況下也是一個個彈出的。
壓測
在MacBook Pro 2018上的壓測表現如下(Golang實現的HTTP服務器,MySQL連接池大小100，Redis連接池代銷100，Jmeter壓測)：
500并發 500總請求數 平均響應時間48ms 發放成功數100 吞吐量497.0/s
結論
可以看到Redis的表現是穩定的，不會出現超發，且訪問延遲少了8倍左右，吞吐量還沒達到瓶頸，可以看出Redis對于高并發系統的性能提升是非常大的!接入成本也不算高，值得學習!
實驗代碼
//?main.go
package?main
import?(
"fmt"
"github.com/go-redis/redis"
_?"github.com/go-sql-driver/mysql"
"github.com/jinzhu/gorm"
"log"
"net/http"
"strconv"
"time"
)
type?Envelope?struct?{
Id????????int`gorm:"primary_key"`
Code??????string
UserId????int
CreatedAt?time.Time
RewardAt??*time.Time
}
func?(Envelope)?TableName()?string?{
return"envelope"
}
func?(p?*Envelope)?BeforeCreate()?error?{
p.CreatedAt?=?time.Now()
returnnil
}
const?(
QueueEnvelope?=?"envelope"
QueueUser?????=?"user"
)
var?(
db??????????*gorm.DB
redisClient?*redis.Client
)
func?init()?{
var?err?error
db,?err?=?gorm.Open("mysql","root:root@tcp(localhost:3306)/test?charset=utf8&parseTime=True&loc=Local")
if?err?!=?nil?{
log.Fatal(err)
}
if?err?=?db.DB().Ping();?err?!=?nil?{
log.Fatal(err)
}
db.DB().SetMaxOpenConns(100)
fmt.Println("database?connected.?pool?size?10")
}
func?init()?{
redisClient?=?redis.NewClient(&redis.Options{
Addr:?????"localhost:6379",
DB:???????0,
PoolSize:?100,
})
if?_,?err?:=?redisClient.Ping().Result();?err?!=?nil?{
log.Fatal(err)
}
fmt.Println("redis?connected.?pool?size?100")
}
//?讀取Code寫入Queue
func?init()?{
envelopes?:=?make([]Envelope,?0,?100)
if?err?:=?db.Debug().Where("user_id=0").Limit(100).Find(&envelopes).Error;?err?!=?nil?{
log.Fatal(err)
}
if?len(envelopes)?!=?100?{
log.Fatal("不足100個獎品")
}
fori?:=?range?envelopes?{
if?err?:=?redisClient.LPush(QueueEnvelope,?envelopes[i].Code).Err();?err?!=?nil?{
log.Fatal(err)
}
}
fmt.Println("load?100?envelopes")
}
func?main()?{
http.HandleFunc("/envelope",?func(w?http.ResponseWriter,?r?*http.Request)?{
uid?:=?r.Header.Get("x-user-id")
if?uid?==?""{
w.WriteHeader(401)
_,?_?=?fmt.Fprint(w,?"UnAuthorized")
return
}
uidValue,?err?:=?strconv.Atoi(uid)
if?err?!=?nil?{
w.WriteHeader(400)
_,?_?=?fmt.Fprint(w,?"Bad?Request")
return
}
//?檢測用戶是否搶過了
if?result,?err?:=?redisClient.HIncrBy(QueueUser,?uid,?1).Result();?err?!=?nil?||?result?!=?1?{
w.WriteHeader(429)
_,?_?=?fmt.Fprint(w,?"Too?Many?Request")
return
}
//?檢測是否在隊列中
code,?err?:=?redisClient.LPop(QueueEnvelope).Result()
if?err?!=?nil?{
w.WriteHeader(200)
_,?_?=?fmt.Fprint(w,?"No?Envelope")
return
}
//?發放紅包
envelope?:=?&Envelope{}
err?=?db.Where("code=?",?code).Take(&envelope).Error
if?err?==?gorm.ErrRecordNotFound?{
w.WriteHeader(200)
_,?_?=?fmt.Fprint(w,?"No?Envelope")
return
}
if?err?!=?nil?{
w.WriteHeader(500)
_,?_?=?fmt.Fprint(w,?err)
return
}
now?:=?time.Now()
envelope.UserId?=?uidValue
envelope.RewardAt?=?&now
rowsAffected?:=?db.Where("user_id=0").Save(&envelope).RowsAffected?//?添加user_id=0來驗證Redis是否真的解決爭搶問題
if?rowsAffected?==?0?{
fmt.Printf("發生爭搶.?id=%d\n",?envelope.Id)
w.WriteHeader(500)
_,?_?=?fmt.Fprintf(w,?"發生爭搶.?id=%d\n",?envelope.Id)
return
}
_,?_?=?fmt.Fprint(w,?envelope.Code)
})
fmt.Println("listen?on?8080")
fmt.Println(http.ListenAndServe(":8080",?nil))
}
【編輯推薦】
【責任編輯：華軒 TEL：(010)68476606】
點贊 0
總結
以上是生活随笔為你收集整理的redis抽奖并发_Redis优化高并发下的秒杀性能的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： QSG92式手枪步入世界前列的国产手枪？
- 下一篇： aspmysql发布_ASP.NET E