導語：一年一度的雙十一又雙叒叕來了，給技術人最好的禮物就是大促技術指南! 而經(jīng)過這些年的發(fā)展，大促早已不僅僅局限于電商行業(yè)，現(xiàn)在各行各業(yè)其實都會采用類似方式做運營活動，汽車界有 818，電商有 618 、11.11 等等，各種各樣的大促場景，對包括數(shù)據(jù)庫在內的基礎軟件提出了很多新挑戰(zhàn)，同時也積累了諸多最佳實踐。
在雙十一到來前，PingCAP 與汽車之家、易車網(wǎng)、京東、中通等用戶展開一系列深入探討，希望為大家揭秘逐年飆升的銷量背后隱藏著什么樣的技術難題?用什么技術架構才能平穩(wěn)地扛住流量洪峰?
汽車界的“大促”狂歡節(jié)
成立于 2000 年的易車，是國內最早一批汽車互聯(lián)網(wǎng)平臺企業(yè)之一，為汽車用戶提供專業(yè)、豐富的互聯(lián)網(wǎng)資訊服務，提升用戶在選車、購車、用車和換車過程中的全程體驗。
在今年“ 818 ” 期間，易車與浙江衛(wèi)視聯(lián)合推出了一臺綜合汽車工藝秀、明星歌舞演出和明星綜藝秀的車界“春晚”——“易車超級 818 汽車狂歡夜”。在為汽車用戶帶來視聽盛宴、購車福利的同時，晚會還推出超 150 臺半價車的超值福利，觀眾可邊看晚會邊搶 5 折售賣的好車，同時還有購車紅包、抵扣券、車款直降等多重優(yōu)惠，得到實實在在的購車福利。截至晚會結束，全平臺觀看直播人次達2.24億，獲得線上訂單4.39萬，累計成交額(GMV)64.2億元。
易車的大促首秀
在易車的 818 狂歡節(jié)中，數(shù)據(jù)庫的應用場景有很多，其中實時數(shù)據(jù)看板是主要的應用業(yè)務之一?？窗蹇梢詫崟r展示易車 818 購車節(jié)的專題、活動、流量、線索、互動等數(shù)據(jù)表現(xiàn)，是大數(shù)據(jù)平臺的整體數(shù)據(jù)輸出。
由于易車的這場汽車狂歡夜是臺網(wǎng)互動的直播活動，搖一搖(紅包、半價車、易車幣)和主會場分會場直播節(jié)目的投票都是用戶參與度最高、數(shù)據(jù)流量最大的環(huán)節(jié)。在整個活動過程中，不僅要求數(shù)據(jù)庫能夠存儲海量數(shù)據(jù)，同時還要求能夠應對高并發(fā)、低延遲等場景需求。這里的數(shù)據(jù)庫不僅會作為數(shù)據(jù)存儲的介質，還會作為實時計算的數(shù)據(jù)源頭，配合流量數(shù)據(jù)，實現(xiàn)秒級數(shù)據(jù)實時播報。
數(shù)據(jù)庫和 Flink 是整個系統(tǒng)中非常重要的兩個組件，F(xiàn)link 的數(shù)據(jù)來源包括數(shù)據(jù)庫和業(yè)務流量數(shù)據(jù)，所以數(shù)據(jù)庫不僅要滿足數(shù)據(jù)秒級實時推送，還要支持 Flink 高并發(fā)的讀寫請求。
易車數(shù)據(jù)庫負責人田震坦言，易車今年是第一次做大促，沒有太多經(jīng)驗，量也不好預估，很多需求都是在最后才提出。為了保險起見，DBA 團隊在設計大促方案時做了降級方案，但誰都不希望真的實施降級，這對用戶的體驗太不友好。所以整個 DBA 團隊將主要精力放在壓測上，并按照平時的兩個數(shù)量級(100倍)來規(guī)劃數(shù)據(jù)庫壓測方案。
一開始，易車考慮的首選數(shù)據(jù)庫依然是 MySQL。但在壓測過程中，為了保證計算結果的實時性，實時任務會頻繁對數(shù)據(jù)庫進行大批量數(shù)據(jù)寫入，MySQL 主從延遲高，極端情況下引起的 MySQL 主從切換，切換時間過長，導致數(shù)據(jù)庫出現(xiàn)短暫不可用狀態(tài)。同時，實時任務會持續(xù)寫入大量數(shù)據(jù)，引起磁盤爆滿。在分秒必爭的直播過程中這肯定是無法容忍的。
在情勢急迫下，田震想到了 TiDB。
“在游泳中學游泳” TiDB 臨危受命
實際上，田震很早就接觸過 TiDB ，那時候他一度認為 TiDB 是一款海外產(chǎn)品，了解 TiDB 主要也是從海外社區(qū)開始的。但出于謹慎的原因，田震希望將產(chǎn)品研究透徹再正式上線。本次大促給了雙方合作一個完美的契機，他形容這一過程就像是“在游泳中學游泳”。
TiDB 社區(qū)的技術支持給了易車 DBA 們非常重要的幫助，從七月正式立項，僅用了不到一個月時間就完成了選型、方案設計、壓測、上線部署，并在“818”中有驚無險地將大促流量平穩(wěn)承載過來。
818 汽車狂歡數(shù)據(jù)看板業(yè)務架構圖
在整個 818 活動中，TiDB 被用作 818 汽車狂歡節(jié)數(shù)據(jù)看板的核心數(shù)據(jù)庫。易車準備了兩套 TiDB 集群，和實時計算的主備方案一一對應。業(yè)務研發(fā)通過雙寫的方式把數(shù)據(jù)同時寫入兩個集群，一部分業(yè)務的查詢連接集群 1 ，另一部分業(yè)務的查詢連接集群 2，當其中一個集群出現(xiàn)問題，應用端就會切換到另外一個集群。兩個 TiDB 集群都是部署了 3 個 TiDB Server、3 個 PD Server、6 個 TiKV 節(jié)點、2 個 TiFlash 節(jié)點。此外，還準備了 4 臺機器做擴容以免數(shù)據(jù)量暴漲集群支撐不了。
最終，易車 818 汽車狂歡節(jié)期間數(shù)據(jù)量達到了平時的 10 倍以上，在直播最后蔡徐坤出場時，數(shù)據(jù)庫流量更是直接翻了四倍，差點啟用事先準備好兜底用的一鍵擴容方案。在整個過程中，818 汽車狂歡數(shù)據(jù)看板業(yè)務 SQL 999 始終控制在 8ms 以內，SQL 99 在 3ms 左右，QPS 達到 62k。
紅包搖一搖業(yè)務架構圖
同時，TiDB 也作為容災方案被應用在紅包搖一搖業(yè)務中，避免由于業(yè)務流量暴漲引起 MySQL 不可用的情況。一旦發(fā)生不可用，業(yè)務方可以直接將數(shù)據(jù)庫切換到 TiDB。TiDB 在整個業(yè)務中需要作為數(shù)據(jù)源、實時計算維表和實時計算結果存儲引擎三個角色。TiDB 通過 TiCDC 將數(shù)據(jù)實時推送到 Kafka 中，為了保證 TiCDC 穩(wěn)定高效，易車為 TiDB 中的每個庫創(chuàng)建了一個 TiCDC 任務，將數(shù)據(jù)實時推送到指定 Kafka 中，然后 Flink 負責將同一個 TOPIC 中的屬于不同庫表的數(shù)據(jù)進行解析，分流到庫表對應的 TOPIC 中，提供給實時計算業(yè)務使用。實時計算任務消費 Kafka 中的 TiDB 數(shù)據(jù)進行業(yè)務邏輯計算，同時還需要從 TiDB 中查詢對應的維度數(shù)據(jù)，最終將計算結果再輸出到 TiDB 中。
高速增長的挑戰(zhàn)：技術棧統(tǒng)一
大促的極限場景總能發(fā)現(xiàn)一些平時注意不到的問題，在易車的高速發(fā)展中，很多業(yè)務為了快速迭代、迅速上線，引入了非常多的技術棧，如 Lambda 、 Kappa 等大數(shù)據(jù)架構，Kylin、Druid、Clickhouse 等實時數(shù)倉等等。但易車 DBA 團隊卻只有 6個人，管理如此多的技術棧無疑是一個很大的挑戰(zhàn)。
統(tǒng)一技術棧成為易車 DBA 團隊的最佳選擇，借著這次大促的機會，易車希望用 TiDB 上線取代 Kylin、Druid、Clickhouse ，簡化技術棧，DBA 團隊也能將注意力放回專職工作上。
TiDB 的 HTAP 架構是一個混合了交易型事務和分析處理的融合架構，由于都是在同一個架構、同一套數(shù)據(jù)中，解決了易車實時數(shù)倉數(shù)據(jù)流延遲的問題。數(shù)據(jù)不用再從 OLTP 數(shù)據(jù)庫復制出來，經(jīng)過漫長的 ETL 清洗等過程進入分析工具。
而 TiDB 對 MySQL 的完美兼容，對 DBA 和開發(fā)者意味著不需要做什么改變，只要會 SQL 就能使用。在以往應用 Hadoop 或 Spark 時，由于學習成本比較高，對使用造成了一定壁壘。
經(jīng)此一役，易車的業(yè)務方對 TiDB 平添了許多期待與信任。未來，易車的廣告、媒體平臺、網(wǎng)站、投放數(shù)據(jù)、廣告效果都希望能夠實時看到，田震希望借用 TiDB 覆蓋易車整個混合技術棧的場景，與其他數(shù)據(jù)流進行打通，這些都需要 TiDB HTAP 對實時數(shù)倉進行支持。
大促對于企業(yè)而言，除了支持業(yè)務創(chuàng)新，也是一次對自身技術架構的大練兵和全鏈路演練。通過大促的極致考驗，企業(yè)的 IT 架構、組織流程、人才技能都獲得了大幅提升。而在大促中的經(jīng)驗和思考，也會加速企業(yè)日常的業(yè)務創(chuàng)新節(jié)奏，提升技術驅動的創(chuàng)新效率，打造增長新引擎。
（免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產(chǎn)權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）
