正如你可能之前看到的，Discord去年發(fā)布了一篇有價(jià)值的文章，討論了他們成功存儲(chǔ)了數(shù)萬(wàn)億條消息。雖然有很多關(guān)于這篇文章的YouTube視頻和文章，但我認(rèn)為這篇文章中一個(gè)名為“數(shù)據(jù)服務(wù)為數(shù)據(jù)服務(wù)”的部分沒(méi)有得到足夠的關(guān)注。在這篇文章中，我們將討論Discord對(duì)數(shù)據(jù)服務(wù)的方法，并探討如何利用Golang的并發(fā)特性來(lái)減少特定情況下的數(shù)據(jù)庫(kù)負(fù)載。

數(shù)據(jù)服務(wù)拯救熱分區(qū)

如你所知，消息和頻道是Discord中最常用的組件。讓我們想象一個(gè)場(chǎng)景：一個(gè)擁有50萬(wàn)成員的頻道的管理員提到@everyone。會(huì)發(fā)生什么？成千上萬(wàn)個(gè)同時(shí)的請(qǐng)求直接指向那個(gè)數(shù)據(jù)庫(kù)分區(qū)，所有請(qǐng)求的目標(biāo)都是檢索相同的消息。這種模式重復(fù)發(fā)生，直到該分區(qū)無(wú)法回應(yīng)其他請(qǐng)求。

Discord引入了一個(gè)位于Python API和數(shù)據(jù)庫(kù)集群之間的中間服務(wù) — 他們稱(chēng)之為數(shù)據(jù)服務(wù)。這個(gè)服務(wù)大致包含每個(gè)查詢(xún)一個(gè)gRPC端點(diǎn)，沒(méi)有任何業(yè)務(wù)邏輯。對(duì)Discord來(lái)說(shuō)，這個(gè)服務(wù)的重要特性就是請(qǐng)求合并。

請(qǐng)求合并

正如我們之前討論過(guò)的，每當(dāng)在一個(gè)龐大的頻道中有提及時(shí)，就會(huì)有大量類(lèi)似的請(qǐng)求直接指向數(shù)據(jù)庫(kù)分區(qū)。通過(guò)合并這些請(qǐng)求，如果多個(gè)用戶(hù)請(qǐng)求相同的數(shù)據(jù)庫(kù)行，我們可以將這些請(qǐng)求合并成一個(gè)選擇查詢(xún)，并執(zhí)行該查詢(xún)。

通過(guò)使用數(shù)據(jù)服務(wù)而不是直接連接到數(shù)據(jù)庫(kù)，我們可以實(shí)現(xiàn)許多令人興奮的功能，比如批量查詢(xún)，這些功能可以顯著減少數(shù)據(jù)庫(kù)開(kāi)銷(xiāo)，并改善查詢(xún)的平均值，特別是第99百分位數(shù)。

使用Golang實(shí)現(xiàn)簡(jiǎn)單的請(qǐng)求合并

與許多其他公司一樣，Discord使用Python作為其主要的后端語(yǔ)言。無(wú)論是微服務(wù)還是單體架構(gòu)，后端服務(wù)通常直接連接到數(shù)據(jù)源進(jìn)行查詢(xún)。雖然Python確實(shí)是一種多功能語(yǔ)言，但在并發(fā)性方面存在一些不足。使用Python實(shí)現(xiàn)并發(fā)和高吞吐量的服務(wù)可能有些挑戰(zhàn)，而性能與用C++、Rust和Golang等編譯語(yǔ)言編寫(xiě)的類(lèi)似服務(wù)相比，往往會(huì)較低。

在進(jìn)行任何操作之前，讓我們模擬一下提到的情況。假設(shè)服務(wù)總共收到了5,000個(gè)請(qǐng)求，其中并發(fā)數(shù)為1,000。

• 總請(qǐng)求數(shù)： 5,000
• 并發(fā)數(shù)： 1,000
• 需要檢索的唯一消息數(shù)： 100

type Message struct {gorm.ModelText stringUser string // some random properties that a message row may have
}func generateRandomData(db *gorm.DB) {for i := 0; i < 100; i++ {msg := &messages.Message{Text: fmt.Sprintf("Message #%d", i)}db.Save(msg)}
}

我使用Gorm構(gòu)建了一個(gè)簡(jiǎn)單的數(shù)據(jù)庫(kù)模型來(lái)表示**Message（消息）**表，然后向表中填充了100條虛擬消息。

e := echo.New()
e.GET("/randomMessage", func(c echo.Context) error {randomMessageID := rand.Intn(100)var msg messages.Messageif err := db.Where("id=?", randomMessageID).First(&msg).Error; err != nil {return err}return c.JSON(200, msg)
})
e.Logger.Fatal(e.Start(":1323"))

我創(chuàng)建了一個(gè)簡(jiǎn)單的端點(diǎn)來(lái)模擬對(duì)0到100之間的隨機(jī)ID進(jìn)行SELECT查詢(xún)?，F(xiàn)在我們可以對(duì)這個(gè)端點(diǎn)進(jìn)行基準(zhǔn)測(cè)試，模擬在這種情況下會(huì)發(fā)生什么。

• 平均每秒請(qǐng)求數(shù) (RPS)： 300
• 平均響應(yīng)時(shí)間： 3.2秒
• 50% 響應(yīng)時(shí)間： 546毫秒
• 99% 響應(yīng)時(shí)間： 14.7秒

如果我們有10秒的超時(shí)策略，大約有2%的請(qǐng)求將收不到響應(yīng)?，F(xiàn)在讓我們改變代碼。Golang有一個(gè)名為“single flight”的內(nèi)置包。這個(gè)包提供了重復(fù)函數(shù)調(diào)用抑制機(jī)制。一般來(lái)說(shuō)，你給它一個(gè)鍵和一個(gè)函數(shù)，而不是多次運(yùn)行該函數(shù)，SingleFlight會(huì)暫時(shí)保持其他調(diào)用，直到第一次調(diào)用完成其請(qǐng)求并以相同的結(jié)果作出響應(yīng)。

var g = singleflight.Group{}
e.GET("/randomMessage", func(c echo.Context) error {randomMessageID := rand.Intn(100)msg, err, _ := g.Do(fmt.Sprint(randomMessageID), func() (interface{}, error) {var msg messages.Messageif err := db.Where("id=?", randomMessageID).First(&msg).Error; err != nil {return nil, err}return &msg, nil})if err != nil {return err}return c.JSON(200, msg)
})

func (g *Group) Do(key string, fn func() (interface{}, error)) (v interface{}, err error, shared bool)

Do 執(zhí)行并返回給定函數(shù)的結(jié)果，確保同一時(shí)間針對(duì)給定鍵只有一個(gè)執(zhí)行過(guò)程。如果出現(xiàn)重復(fù)，重復(fù)的調(diào)用者會(huì)等待原始調(diào)用完成并接收相同的結(jié)果。返回值 shared 表示是否將 v 給了多個(gè)調(diào)用者。

現(xiàn)在讓我們重新運(yùn)行模擬并比較結(jié)果。

• 平均每秒請(qǐng)求數(shù) (RPS)： 2309
• 平均響應(yīng)時(shí)間： 433毫秒
• 50% 響應(yīng)時(shí)間： 389毫秒
• 99% 響應(yīng)時(shí)間： 777毫秒

正如你所看到的，僅使用了一個(gè)簡(jiǎn)單的技術(shù)就將第99百分位數(shù)減少了14秒，新方法支持的每秒請(qǐng)求次數(shù)提高了7.6倍。

結(jié)論

從那時(shí)起我們就注意到，通過(guò)優(yōu)化數(shù)據(jù)庫(kù)查詢(xún)，可以大大提高應(yīng)用程序的整體性能。雖然我們討論的方法是情景性的，但Discord已經(jīng)使用了一年多，對(duì)他們有很大幫助。

你應(yīng)該知道，如果你使用數(shù)據(jù)服務(wù)，你將面臨其他的復(fù)雜情況。例如，你可能會(huì)有多個(gè)數(shù)據(jù)服務(wù)實(shí)例，而你的Python API必須有一種機(jī)制將類(lèi)似的請(qǐng)求發(fā)送到同一個(gè)實(shí)例。