餓了么從 2008 年創(chuàng)建以來，一直都是飛速的發(fā)展。目前，餓了么已覆蓋了 2000 多個城市，擁有 2.6 億的用戶，130 萬的商戶，300萬的騎手。餓了么在配送時間上追求卓越，目前餓了么的準(zhǔn)時達(dá)訂單平均配送時長已達(dá)到 28 分鐘以內(nèi)。從 2015 年開始，餓了么形成了 2 大業(yè)務(wù)，在線交易平臺業(yè)務(wù)和即時配送平臺業(yè)務(wù)。餓了么的用戶量和訂單量的快速增長，帶來了數(shù)據(jù)量的快速增長，從而產(chǎn)生對大數(shù)據(jù)量存儲的強烈需求，并且很多數(shù)據(jù)都是 KeyValue 格式的數(shù)據(jù)。之前餓了么沒有統(tǒng)一的 Key-Value 存儲系統(tǒng)，這部分?jǐn)?shù)據(jù)被存儲在 MySQL、Redis、Mongo、Cassandra 等不同的系統(tǒng)中，將數(shù)據(jù)存儲在這些系統(tǒng)中，帶來一些問題，比如數(shù)據(jù)擴容不方便、內(nèi)存不可靠、性能不達(dá)標(biāo)、運維不方便等。

我們希望用一套統(tǒng)一的 Key-Value 存儲系統(tǒng)來存儲這些 Key-Value 形式的數(shù)據(jù)，并且滿足以下所有的技術(shù)要求：

• 大數(shù)據(jù)量，可以存儲至少數(shù)十 TB 級別的數(shù)據(jù)。
• 高性能，在滿足高 QPS 的同時，保證比較低的延時。
• 高可靠，數(shù)據(jù)被可靠的持久化存儲，少量機器的損壞不會導(dǎo)致數(shù)據(jù)的丟失。
• 高可用，作為在線服務(wù)的底層依賴存儲，要有非常完善的高可用性能力，外賣服務(wù)不同于電子商務(wù)，對實時性要求非常高，對系統(tǒng)的可用性的要求則是更高的。
• 易運維，可以在不停服的基礎(chǔ)上進(jìn)行數(shù)據(jù)遷移，和集群擴容。

從 2017 年下半年開始，餓了么開始基于 TiKV 構(gòu)建餓了么的 Key-Value 存儲系統(tǒng)，并且取得了很好的應(yīng)用效果。餓了么對 Key-Value 系統(tǒng)的使用是在線系統(tǒng)，由離線計算集群生成數(shù)據(jù)，在線服務(wù)消費這些數(shù)據(jù)。這些在線服務(wù)覆蓋了餓了么在線交易和即時配送 2 大平臺，在線交易平臺中的首頁搜索、商品品類、商品排序、天降紅包等等，即時配送平臺中的物流旗手智能調(diào)度等，各種在線服務(wù)都在使用我們的 Key-Value 系統(tǒng)。?

目前，TiKV 的應(yīng)用會影響?zhàn)I了么全平臺 80% 的流量，包括從用戶選餐下單到訂單配送整個餓了么流程。

TiKV集群上線情況：

• 目前已在餓了么部署了十幾套? TiKV? 集群，分別位于北京、上海、廣州的四個機房，共計 100+ 機器節(jié)點，承載了數(shù)十 TB 的數(shù)據(jù)。
• 配置了完備的監(jiān)控告警系統(tǒng)，所有集群都已接入，可以在集群出現(xiàn)問題時及時發(fā)送告警信息，為集群的正常運行提供了保障。
• 業(yè)務(wù)高峰期時，最繁忙的一個集群，寫入 QPS 近 5w，讀取 QPS 近 10w。
• 至今已穩(wěn)定運行大半年，沒有發(fā)生過線上事故。?

在 Key-Value 的這個領(lǐng)域中，有著林林總總的開源系統(tǒng)。我們?yōu)槭裁匆x擇 TiKV 呢？首先要從 TiDB 的架構(gòu)說起。TiDB 由 TiKV 存儲層和 TiDB SQL 層組成。TiKV 層是 TiDB 系統(tǒng)的底層存儲層，TiKV 層本身是一個分布式的 Key-Value 存儲系統(tǒng)。而 TiDB 層構(gòu)建于 TiKV 層基礎(chǔ)之上，實現(xiàn)了無狀態(tài)的 SQL 協(xié)議層，負(fù)責(zé)將用戶的 SQL 請求，轉(zhuǎn)化為 TiKV 的 Key-Value 請求，從而整體上實現(xiàn)分布式的 SQL 存儲。這種架構(gòu)借鑒了 Google 的 Spanner 系統(tǒng)，Spanner 是一個分布式的 Key-Value 存儲系統(tǒng)，Google 在 Spanner 的基礎(chǔ)之上，構(gòu)建了一個名叫 F1 的系統(tǒng)，實現(xiàn)了 SQL 協(xié)議。

我們也比較推崇這種架構(gòu)，并且我們認(rèn)為在 Key-Value 基礎(chǔ)之上，不僅僅可以構(gòu)建 SQL 協(xié)議，也可以構(gòu)建 Redis 這樣的 Key-Value 協(xié)議。

在這種架構(gòu)中，上層負(fù)責(zé)協(xié)議轉(zhuǎn)換。TiKV 層則通過數(shù)據(jù)分片、Raft 協(xié)議、MVCC、分布式事務(wù)等技術(shù)，實現(xiàn)了水平擴展、高可用、強一致性等分布式特性。?

我們的 Redis layer 實現(xiàn)如下：

我們構(gòu)建了一個 ekvproxy 的服務(wù)。在這個服務(wù)中，我們封裝了一個 TiKV 的 SDK，對 Redis 的協(xié)議進(jìn)行了解析，并且將 Redis 協(xié)議轉(zhuǎn)成對 TiKV 的調(diào)用。并且在這個基礎(chǔ)之上，實現(xiàn)了壓縮和限流等一些擴展功能。由于我們兼容了 Redis 協(xié)議，各種語言均可以在不做任何修改的情況下，直接使用官方的 Redis 客戶端訪問我們的 Key-Value 服務(wù)。在最大程度上減輕了使用方的負(fù)擔(dān)。便于 TiKV 的落地推廣。

另外，PingCAP 的工程師還第一時間幫我們實現(xiàn)了 TiKV 的 raw scan 的功能，從而能更好的與 Redis 協(xié)議兼容，在此表示感謝。

雖然系統(tǒng)在線上性能表現(xiàn)已經(jīng)非常不錯，但這仍然沒有達(dá)到 TiKV 的最大處理能力，上線前，我們對 TiKV 進(jìn)行了詳細(xì)的性能測試，我們測試環(huán)境選在 32 核 CPU，256G 內(nèi)存，3.5T PCIE SSD 硬盤的機器上， 得到了更好的結(jié)果，取其中典型數(shù)據(jù)如下：

使用 TiKV 的這半年的時間來，在餓了么取得了非常良好的應(yīng)用效果，應(yīng)用場景不斷增多，數(shù)據(jù)量不斷增大，對餓了么業(yè)務(wù)做了非常好的支撐，這也依賴于 TiKV 技術(shù)人員對我們的各種到位的技術(shù)支持。未來，TiKV 在餓了么的應(yīng)用場景會更加豐富。我們也會考慮將我們 Redis Proxy 開源，開放給社區(qū)。

作者介紹：陳東明，餓了么北京技術(shù)中心架構(gòu)組負(fù)責(zé)人，負(fù)責(zé)餓了么的產(chǎn)品線架構(gòu)設(shè)計以及餓了么基礎(chǔ)架構(gòu)研發(fā)工作。曾任百度架構(gòu)師，負(fù)責(zé)百度即時通訊產(chǎn)品的架構(gòu)設(shè)計。具有豐富的大規(guī)模系統(tǒng)構(gòu)建和基礎(chǔ)架構(gòu)的研發(fā)經(jīng)驗，善于復(fù)雜業(yè)務(wù)需求下的大并發(fā)、分布式系統(tǒng)設(shè)計和持續(xù)優(yōu)化。

總結(jié)

以上是生活随笔為你收集整理的TiKV 在饿了么的大规模应用实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。