Redis優(yōu)化高并發(fā)下的秒殺性能
本文內(nèi)容
- 使用Redis優(yōu)化高并發(fā)場景下的接口性能
 - 數(shù)據(jù)庫樂觀鎖
 
隨著雙11的臨近,各種促銷活動開始變得熱門起來,比較主流的有秒殺、搶優(yōu)惠券、拼團等等。
涉及到高并發(fā)爭搶同一個資源的主要場景有秒殺和搶優(yōu)惠券。
前提
活動規(guī)則
- 獎品數(shù)量有限,比如100個
 - 不限制參與用戶數(shù)
 - 每個用戶只能參與1次秒殺
 
活動要求
- 不能多發(fā),也不能少發(fā),100個獎品要全部發(fā)出去
 - 1個用戶最多搶1個獎品
 - 遵循先到先得原則,先來的用戶有獎品
 
數(shù)據(jù)庫實現(xiàn)
悲觀鎖性能太差,本文不予討論,討論一下使用樂觀鎖解決高并發(fā)問題的優(yōu)缺點。
數(shù)據(jù)庫結(jié)構(gòu)
- 未中獎時UserId為0,RewardAt為NULL
 - 中獎時UserId為中獎用戶ID,RewardAt為中獎時間
 
樂觀鎖實現(xiàn)
樂觀鎖實際上并不存在真正的鎖,樂觀鎖是利用數(shù)據(jù)的某個字段來做的,比如本文的例子就是以UserId來實現(xiàn)的。
實現(xiàn)流程如下:
1.查詢UserId為0的獎品,如果未找到則提示無獎品
- SELECT * FROM envelope WHERE user_id=0 LIMIT 1
 
2.更新獎品的用戶ID和中獎時間(假設(shè)獎品ID為1,中獎用戶ID為100,當(dāng)前時間為2019-10-29 12:00:00),這里的user_id=0就是我們的樂觀鎖了。
- UPDATE envelope SET user_id=100, reward_at='2019-10-29 12:00:00' WHERE user_id=0 AND id=1
 
3.檢測UPDATE語句的執(zhí)行返回值,如果返回1證明中獎成功,否則證明該獎品被其他人搶了
為什么要添加樂觀鎖
正常情況下獲取獎品、然后把獎品更新給指定用戶是沒問題的。如果不添加user_id=0時,高并發(fā)場景下會出現(xiàn)下面的問題:
- 兩個用戶同時查詢到了1個未中獎的獎品(發(fā)生并發(fā)問題)
 - 將獎品的中獎用戶更新為用戶1,更新條件只有ID=獎品ID
 - 上述SQL執(zhí)行是成功的,影響行數(shù)也是1,此時接口會返回用戶1中獎
 - 接下來將中獎用戶更新為用戶2,更新條件也只有ID=獎品ID
 - 由于是同一個獎品,已經(jīng)發(fā)給用戶1的獎品會重新發(fā)放給用戶2,此時影響行數(shù)為1,接口返回用戶2也中獎
 - 所以該獎品的最終結(jié)果是發(fā)放給用戶2
 - 用戶1就會過來投訴活動方了,因為抽獎接口返回用戶1中獎,但他的獎品被搶了,此時活動方只能賠錢了
 
添加樂觀鎖之后的抽獎流程
- 更新用戶1時的條件為id=紅包ID AND user_id=0 ,由于此時紅包未分配給任何人,用戶1更新成功,接口返回用戶1中獎
 - 當(dāng)更新用戶2時更新條件為id=紅包ID AND user_id=0,由于此時該紅包已經(jīng)分配給用戶1了,所以該條件不會更新任何記錄,接口返回用戶2中獎
 
樂觀鎖優(yōu)缺點
優(yōu)點
- 性能尚可,因為無鎖
 - 不會超發(fā)
 
缺點
- 通常不滿足“先到先得”的活動規(guī)則,一旦發(fā)生并發(fā),就會發(fā)生未中獎的情況,此時獎品庫還有獎品
 
壓測
在MacBook Pro 2018上的壓測表現(xiàn)如下(Golang實現(xiàn)的HTTP服務(wù)器,MySQL連接池大小100,Jmeter壓測):
- 500并發(fā) 500總請求數(shù) 平均響應(yīng)時間331ms 發(fā)放成功數(shù)為31 吞吐量458.7/s
 
Redis實現(xiàn)
可以看到樂觀鎖的實現(xiàn)下爭搶比太高,不是推薦的實現(xiàn)方法,下面通過Redis來優(yōu)化這個秒殺業(yè)務(wù)。
Redis高性能的原因
- 單線程 省去了線程切換開銷
 - 基于內(nèi)存的操作 雖然持久化操作涉及到硬盤訪問,但是那是異步的,不會影響Redis的業(yè)務(wù)
 - 使用了IO多路復(fù)用
 
實現(xiàn)流程
1.活動開始前將數(shù)據(jù)庫中獎品的code寫入Redis隊列中
2.活動進行時使用lpop彈出隊列中的元素
3.如果獲取成功,則使用UPDATE語法發(fā)放獎品
- UPDATE reward SET user_id=用戶ID,reward_at=當(dāng)前時間 WHERE code='獎品碼'
 
4.如果獲取失敗,則當(dāng)前無可用獎品,提示未中獎即可
使用Redis的情況下并發(fā)訪問是通過Redis的lpop()來保證的,該方法是原子方法,可以保證并發(fā)情況下也是一個個彈出的。
壓測
在MacBook Pro 2018上的壓測表現(xiàn)如下(Golang實現(xiàn)的HTTP服務(wù)器,MySQL連接池大小100,Redis連接池代銷100,Jmeter壓測):
- 500并發(fā) 500總請求數(shù) 平均響應(yīng)時間48ms 發(fā)放成功數(shù)100 吞吐量497.0/s
 
結(jié)論
可以看到Redis的表現(xiàn)是穩(wěn)定的,不會出現(xiàn)超發(fā),且訪問延遲少了8倍左右,吞吐量還沒達到瓶頸,可以看出Redis對于高并發(fā)系統(tǒng)的性能提升是非常大的!接入成本也不算高,值得學(xué)習(xí)!
實驗代碼
- // 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()
 - return nil
 - }
 - 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個獎品")
 - }
 - for i := 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
 - }
 - // 發(fā)放紅包
 - 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("發(fā)生爭搶. id=%d\n", envelope.Id)
 - w.WriteHeader(500)
 - _, _ = fmt.Fprintf(w, "發(fā)生爭搶. id=%d\n", envelope.Id)
 - return
 - }
 - _, _ = fmt.Fprint(w, envelope.Code)
 - })
 - fmt.Println("listen on 8080")
 - fmt.Println(http.ListenAndServe(":8080", nil))
 - }
 
















 
 
 









 
 
 
 