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