如何使用Redis優化高并發場景下的接口性能

這篇文章主要介紹了如何使用Redis優化高并發場景下的接口性能，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

本文內容

使用Redis優化高并發場景下的接口性能
數據庫樂觀鎖

隨著雙12的臨近，各種促銷活動開始變得熱門起來，比較主流的有秒殺、搶優惠券、拼團等等。
涉及到高并發爭搶同一個資源的主要場景有秒殺和搶優惠券。

前提

活動規則

• 獎品數量有限，比如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，更新條件只有ID=獎品ID

• 上述SQL執行是成功的，影響行數也是1，此時接口會返回用戶1中獎

• 接下來將中獎用戶更新為用戶2，更新條件也只有ID=獎品ID

• 由于是同一個獎品，已經發給用戶1的獎品會重新發放給用戶2，此時影響行數為1，接口返回用戶2也中獎

• 所以該獎品的最終結果是發放給用戶2

• 用戶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多路復用

實現流程

• 活動開始前將數據庫中獎品的code寫入Redis隊列中

• 活動進行時使用lpop彈出隊列中的元素

• 如果獲取成功，則使用UPDATE語法發放獎品

UPDATE reward SET user_id=用戶ID,reward_at=當前時間 WHERE code='獎品碼'

如果獲取失敗，則當前無可用獎品，提示未中獎即可

使用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)
            _, _ = 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))
}

感謝你能夠認真閱讀完這篇文章，希望小編分享的“如何使用Redis優化高并發場景下的接口性能”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!