導語：一年一度的雙十一又雙叒叕來了，給技術人最好的禮物就是大促技術指南！ 而經過這些年的發展，大促早已不僅僅局限于電商行業，現在各行各業其實都會采用類似方式做運營活動，汽車界有 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秒。業務方可以立即知道上一刻用戶有什么變化，數據有什么更新。
