本文內容

• 使用Redis優化高併發場景下的介面效能
• 資料庫樂觀鎖

隨著雙11的臨近，各種促銷活動開始變得熱門起來，比較主流的有秒殺、搶優惠券、拼團等等。

涉及到高併發爭搶同一個資源的主要場景有秒殺和搶優惠券。

前提

活動規則

• 獎品數量有限，比如100個
• 不限制參與使用者數
• 每個使用者只能參與1次秒殺

活動要求

• 不能多發，也不能少發，100個獎品要全部發出去
• 1個使用者最多搶1個獎品
• 遵循先到先得原則，先來的使用者有獎品

資料庫實現

悲觀鎖效能太差，本文不予討論，討論一下使用樂觀鎖解決高併發問題的優缺點。

資料庫結構

• 未中獎時UserId為0，RewardAt為NULL
• 中獎時UserId為中獎使用者ID，RewardAt為中獎時間

樂觀鎖實現

樂觀鎖實際上並不存在真正的鎖，樂觀鎖是利用資料的某個欄位來做的，比如本文的例子就是以UserId來實現的。

實現流程如下：

1. 查詢UserId為0的獎品，如果未找到則提示無獎品

   SELECT * FROM envelope WHERE user_id=0 LIMIT 1
   複製程式碼

2. 更新獎品的使用者ID和中獎時間(假設獎品ID為1，中獎使用者ID為100，當前時間為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語句的執行返回值，如果返回1證明中獎成功，否則證明該獎品被其他人搶了

為什麼要新增樂觀鎖

正常情況下獲取獎品、然後把獎品更新給指定使用者是沒問題的。如果不新增user_id=0時，高併發場景下會出現下面的問題：

1. 兩個使用者同時查詢到了1個未中獎的獎品(發生併發問題)
2. 將獎品的中獎使用者更新為使用者1，更新條件只有ID=獎品ID
3. 上述SQL執行是成功的，影響行數也是1，此時介面會返回使用者1中獎
4. 接下來將中獎使用者更新為使用者2，更新條件也只有ID=獎品ID
5. 由於是同一個獎品，已經發給使用者1的獎品會重新發放給使用者2，此時影響行數為1，介面返回使用者2也中獎
6. 所以該獎品的最終結果是發放給使用者2
7. 使用者1就會過來投訴活動方了，因為抽獎介面返回使用者1中獎，但他的獎品被搶了，此時活動方只能賠錢了

新增樂觀鎖之後的抽獎流程

1. 更新使用者1時的條件為id=紅包ID AND user_id=0,由於此時紅包未分配給任何人，使用者1更新成功，介面返回使用者1中獎
2. 當更新使用者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語法發放獎品

   UPDATE reward SET user_id=使用者ID,reward_at=當前時間 WHERE code='獎品碼'
   複製程式碼

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()
	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)
			_,"Bad Request")
			return
		}
		// 檢測使用者是否搶過了
		if result,err := redisClient.HIncrBy(QueueUser,uid,1).Result(); err != nil || result != 1 {
			w.WriteHeader(429)
			_,"Too Many Request")
			return
		}
		// 檢測是否在佇列中
		code,err := redisClient.LPop(QueueEnvelope).Result()
		if err != nil {
			w.WriteHeader(200)
			_,"No Envelope")
			return
		}
		// 發放紅包
		envelope := &Envelope{}
		err = db.Where("code=?",code).Take(&envelope).Error
		if err == gorm.ErrRecordNotFound {
			w.WriteHeader(200)
			_,"No Envelope")
			return
		}
		if err != nil {
			w.WriteHeader(500)
			_,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
		}
		_,envelope.Code)
	})

	fmt.Println("listen on 8080")
	fmt.Println(http.ListenAndServe(":8080",nil))
}
複製程式碼