一年一度的雙十一又雙叒叕來了，給技術人最好的禮物就是大促技術指南！而經過這些年的發展，大促早已不僅僅侷限於電商行業，現在各行各業其實都會採用類似方式做運營活動，汽車界有 818，電商有 618 、11.11 等等，各種各樣的大促場景，對包括資料庫在內的基礎軟體提出了很多新挑戰，同時也積累了諸多最佳實踐。
在雙十一到來前，PingCAP 與汽車之家、易車網、京東、中通等使用者展開一系列深入探討，希望為大家揭祕逐年飆升的銷量背後隱藏著什麼樣的技術難題？用什麼技術架構才能平穩地扛住流量洪峰？
818 全球汽車節
中國網際網路有三大購物節，11.11、618 還有 818。
618 與 11.11 都是大家非常熟悉的，818 則比較特殊，它是專為購車使用者打造的節日狂歡。汽車之家 “818 全球汽車夜” ，就是由汽車之家與湖南衛視聯手打造的汽車行業頂級盛典，到今年已經成功舉辦三屆。
相對於其它兩個購物節，818 可以說是全世界唯一的，其他任何汽車最發達的國家也沒有這類活動。對此，汽車之家資深工程師張帆解釋道：“我個人感覺，現在做電商和線上交易的這一塊，地球上應該沒有哪個國家能超越中國。而為什麼汽車之家是最早來做這個事情的呢？首先，汽車之家是全球訪問量最大的汽車型別網站。正是有著這樣巨大的凝聚力與使用者基礎，汽車之家才能做這個事情，才能在廣大使用者中帶來這樣的影響力。此外，這個活動的初衷就是希望為汽車使用者和汽車愛好者，提供一個類似於 11.11、618 一樣真正能在買車的時候得到優惠的機會，因此廣受使用者歡迎。”
從 2019 年開始，汽車之家與湖南衛視合作的 “818 全球汽車夜” 已經持續了三年。與傳統大促不同，818 全球汽車夜通過電視直播和與 APP 活動同步的方式將汽車購物節推到高峰，為 8 月的汽車行業帶來一場購車盛宴。
818 直播活動帶來的挑戰
張帆坦言，在汽車之家的 818 活動中，直播環節是最難的。與錄播完全不同，直播的過程中，會有非常多的變數，也許會有節目時間的拉長，也許會有主持人的即興發揮，也許後臺還會有一些突發的資料處理。而作為整場晚會的亮點，一元秒殺車、紅包抽獎以及超級大錦鯉等活動，是使用者參與度最高，峰值流量出現的環節。這些活動開始與結束的時機，必須以秒級的精度來讓前臺、後臺配合。
直播當天，汽車之家通常會專門派一支團隊到湖南衛視直播現場，通過手機、電話、5G 對講機、線上視訊連線等多路通訊與位於北京的 “作戰室” 之間實時溝通。由於直播訊號通常比現場訊號晚一分鐘，當前面主持人在說三二一秒殺開始後，後臺其實只有一分鐘的準備時間。一分鐘後，就要讓電視機前的上百萬使用者在手機上真的能看到三、二、一，秒殺的按紐點亮，可以去按下它參與活動。這個過程完全不能出錯，必須實現一比一同步。
整個過程對於後方 “作戰室” 中的張帆他們來說，感受非常直觀。這個 “作戰室” 內有資料大屏、監控大屏，以及現場直播的訊號和直播看到的電視訊號。每一次秒殺開始或紅包開始時，監控大屏中的幾條線就會隨著參與人數和互動次數的增加呈現斷崖式的波動。這些代表著業務指標的線被他們稱作 “心電圖”，而在直播中某些高人氣明星出場時，這個波動甚至會比其他時段高 2-4 倍多。
與此同時，現場的資料大屏也在以 1-2 秒的速度，實時展示大約 20 項資料指標，包括活動參與人數、使用者互動次數、獎品發放情況，甚至細化到這一輪一元秒殺車活動參與的使用者有哪些人，在什麼地方，中了什麼車。
這些實時的資料不僅會被後臺工作人員看到，同時資料也會實時展示到直播現場。這對現場活動的氣氛起到了非常重要的烘托作用。舉例來說，當使用者在螢幕前看到這場晚會人氣火爆，並真的有許多人蔘與到一元搶車互動中，這對他而言就相當於一個反向激勵，繼而也參與其中。
在這個過程中，實時資料大屏不僅要解決實時交易問題，還要將實時分析資料反饋給現場的主持人。當主持人幾乎實時地將中獎資訊公佈出來時，晚會氣氛也推到了高位，這對於吸引更多人蔘與其中起到了關鍵作用。而隨著秒殺的車越來越貴，越靠後系統所承受的波峰也越高。相對於汽車之家平時的業務，晚會經歷的流量翻了十倍都不止，對整個系統的壓力不言而喻。
汽車之家大促解決之道——分散式系統全家桶
大促場景通常要求系統具備快速擴充套件與高可用的能力，而分散式系統天然就具有這種能力。汽車之家採用了全家桶式的分散式系統，包括資料庫、佇列、快取等。
其中，分散式資料庫主要表現出三種能力，分別是水平高擴充套件性、容災能力、雲端能力。基於分散式架構的 TiDB 從一開始就支援這些特性，並在汽車之家的場景中得到了很好的驗證。
汽車之家資料庫負責人陶會祥表示，傳統關係型資料庫，如 MySQL 、SQL Server 等，在資料量特別大時，常常會碰到一些資料庫單機承載能力上限的問題。TiDB 從 TiDB Server，到 TiKV 、PD 都可以進行水平擴充套件，效能隨著水平擴充套件可以得到線性提升，很好地滿足了汽車之家對於效能和擴充套件性的要求。
818 對於汽車之家而言是一年中最重要的活動，系統必須保障絕對的可靠穩定。所以這次 818 活動，汽車之家在公有云上採用了同城三中心部署 TiDB 叢集，避免萬一某一個機房出了問題，影響整體活動的服務質量。
同城三資料中心方案，即同城有三個機房部署 TiDB 叢集，同城三資料中心間的資料同步通過叢集自身內部（Raft 協議）完成。同城三資料中心可同時對外進行讀寫服務，任意一個資料中心故障時，叢集能自動恢復服務，不需要人工介入，並能保證資料一致性。TiDB 同城三中心架構在 818 晚會期間順利地支撐了業務，執行表現十分穩定。
汽車之家 818 TiDB 叢集整體架構圖
本次 818 專案中，汽車之家使用了 TiDB 最新的版本 5.1.1，MySQL 的版本是 Percona 5.7.25；
TiFlash 是 TiDB HTAP 形態的關鍵元件，它是 TiKV 的列存擴充套件，主要用於 OLAP 業務。TiFlash 跨區部署提高容災能力，汽車之家利用 TiFlash 解決統計分析類的 SQL，實時展示在大屏；
TiCDC 是一款通過拉取 TiKV 變更日誌實現的 TiDB 增量資料同步工具，具有將資料還原到與上游任意 TSO 一致狀態的能力，支援其他系統訂閱資料變更。TiCDC 跨區部署， 將 TiDB 叢集資料實時同步至下游的 MySQL 資料庫，作為故障應急的備份，實現業務容災能力的提升；
MySQL 跨區部署主從，作為 TiDB 叢集的應急、降級之用，實現業務容災能力的提升。
資料庫壓測
在 818 活動前，資料庫團隊聯合業務方一起做了一輪一輪嚴格的故障演練壓測，確保後端的高可用。
陶會祥透露，汽車之家的故障演練分為多種，光資料庫就會演練主庫故障和機房故障，一共做了三輪。每一輪測試中 TiDB 的表現都非常優秀，KV 故障基本在幾十秒，只需 20 秒即可恢復，即使機房故障也能在一分鐘之內進行自動切換。
為了保障活動平穩支撐，PingCAP 社群技術專家連續三年為汽車之家提供了社群技術支援。在今年的壓測環節中，社群技術專家與汽車之家 DBA 一起完成了調優，良好地解決了寫入熱點問題，將效能翻了好幾倍。最終在 818 高峰時期，TiDB 順利支撐了晚會期間 APP 使用者 9048 萬次互動，並抗住了最大每秒 40 萬行的寫入，SQL 99 穩定在 30ms 以下。TiCDC 效能表現也十分強勁，向下遊 MySQL 同步速度高達 13 萬行每秒 。跨中心的 TiFlash MPP 架構，為大屏近實時展示助力總次數、秒殺和搖獎的每輪參與使用者等資訊提供了強有力的支撐。
陶會祥都對大促中 TiDB 的表現給予十分高的評價：TiDB 在這種十億以上的資料量級場景下是非常適合的，一是 TiDB 的分析能力是實時的，二是 TiDB 的資料儲存能力比傳統資料庫，如 SQL Server 之類強太多。TiDB 結合了傳統數倉和傳統關係型資料庫的優點，非常適合應用在大促這種量級的業務環境。
未來規劃
汽車之家的資料庫團隊在本次 818 大促中，也總結出了非常多的最佳實踐：
如同城三中心五副本架構，機房之間延遲應當儘量小，最好控制在 2ms 以內；
OLTP 的業務，通常壓測瓶頸在於 TiKV 的磁碟 IO 上，對於普通 SSD ，可以做成 RAID0 來提升 IOPS；
一旦某個可用區整體故障，正常不需要手動干預，但是為了避免效能下降嚴重，建議手動將五副本調整為三副本；
合理設計表結構和索引，儘量避免熱點問題，和業務一起做好充分壓測，壓測期間儘早發現問題並優化。
基於本次活動中的良好表現，陶會祥表示，汽車之家接下來還會在更多業務中推進 TiDB 上線。比如以前汽車之家的很多資料會跑在 Hive 裡，需要到第二天才能知道昨天發生了什麼事。如果應用 TiDB ，可以針對運營需要的使用者資料、業務指標的分析，去做秒級的準實時推送，預計能夠將這一時間壓縮到 5-10 秒。業務方可以立即知道上一刻使用者有什麼變化，資料有什麼更新。
618、11.11 對於企業而言，除了支援業務創新，也是一次對自身技術架構的大練兵和全鏈路演練。通過極致考驗，企業的 IT 架構、組織流程、人才技能都獲得了大幅提升。而在此過程中的經驗和思考，也會加速企業日常的業務創新節奏，提升技術驅動的創新效率，打造增長新引擎。