本文內(nèi)容

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供雁塔網(wǎng)站建設(shè)、雁塔做網(wǎng)站、雁塔網(wǎng)站設(shè)計、雁塔網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、雁塔企業(yè)網(wǎng)站模板建站服務(wù)，10年雁塔做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

• 使用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，當前時間為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. 兩個用戶同時查詢到了1個未中獎的獎品(發(fā)生并發(fā)問題)
2. 將獎品的中獎用戶更新為用戶1，更新條件只有ID=獎品ID
3. 上述SQL執(zhí)行是成功的，影響行數(shù)也是1，此時接口會返回用戶1中獎
4. 接下來將中獎用戶更新為用戶2，更新條件也只有ID=獎品ID
5. 由于是同一個獎品，已經(jīng)發(fā)給用戶1的獎品會重新發(fā)放給用戶2，此時影響行數(shù)為1，接口返回用戶2也中獎
6. 所以該獎品的最終結(jié)果是發(fā)放給用戶2
7. 用戶1就會過來投訴活動方了，因為抽獎接口返回用戶1中獎，但他的獎品被搶了，此時活動方只能賠錢了

添加樂觀鎖之后的抽獎流程

1. 更新用戶1時的條件為id=紅包ID AND user_id=0 ,由于此時紅包未分配給任何人，用戶1更新成功，接口返回用戶1中獎
2. 當更新用戶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多路復用

實現(xiàn)流程

1.活動開始前將數(shù)據(jù)庫中獎品的code寫入Redis隊列中

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

3.如果獲取成功，則使用UPDATE語法發(fā)放獎品

 
 
 
 

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

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

使用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)的性能提升是非常大的!接入成本也不算高，值得學習!

實驗代碼

 
 
 
 

  
  
  
  
// 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)) 
  
  
  
  
} 
 
 
 
 

網(wǎng)頁名稱：Redis優(yōu)化高并發(fā)下的秒殺性能
文章鏈接：http://uogjgqi.cn/article/dpgjhpd.html