本文來自塗鴉智慧的劉筠鬆在 PingCAP DevCon 2021 上的分享，包括 TiDB 在 IoT 領域，特別是在智慧家居行業的使用。
關於塗鴉智慧
塗鴉智慧是一個全球化 IoT 開發平臺， 打造互聯互通的開發標準，連線品牌、OEM 廠商、開發者、零售商和各行業的智慧化需求。基於全球公有云，實現智慧場景和智慧裝置的互聯互通。涵蓋硬體開發工具、全球公有云、智慧商業平臺開發三方面； 提供從技術到營銷渠道的全面賦能，打造中立且開放的開發者生態。
目前塗鴉在國內外已經有超過十萬家的合作伙伴，在 IoT PaaS 和 IoT 的開發者平臺的生態客戶數量已經達到 32 萬 +，其涉及到製造業、零售業、運營商、地產、養老、酒店（PaaS）等。塗鴉賦能的有歐美品牌和中國品牌，包括飛利浦，國內的海爾以及三大運營商。
海量資料的實時響應：TiKV 選型歷程
塗鴉的裝置在全球每天處理 840 億請求，平均處理高峰次數能達到 150 萬 TPS，平均響應時間要求小於 10 毫秒。因為塗鴉是物聯網行業，區別於傳統行業，沒有低峰點，寫入量非常大，塗鴉用六年的時間不斷選型嘗試，探索最合適的資料架構。
塗鴉之所以有這麼大量的資料，是因為目前人們家裡應該都會使用到智慧裝置，例如智慧電燈、掃地機器人，裝置聯網後就與塗鴉平臺有了通訊的能力，而智慧裝置的各種定時觸發，比如家裡的攝像頭巡更、掃地機器人的位置資訊都需要上報給塗鴉的 Zeus 平臺。Zeus 系統作為塗鴉平臺最重要的角色，負責處理資料上報，業務拓撲如下圖所示，應用閘道器收集到智慧裝置上報的 MQTT 訊息之後會傳送到 Kafka 和 NSQ 上面，Zeus 系統會消費這些訊息進行解密，處理過後要放到儲存裡面。本文主要描述的也正是從 Zeus 到儲存之間的這段產品選型。
AWS Aurora
塗鴉在早期使用的是 AWS Aurora。Aurora 跟阿里雲的 PolarDB 類似，是存算分離的架構，塗鴉在 Aurora 上穩定執行了三年，在前三年使用中 Aurora 完全滿足需求。物聯網在六七年前還比較冷門，智慧家居裝置沒有這麼普及，使用者用的不多，但後來隨著業務的擴充套件，近幾年裝置呈指數級的成長，每年都要翻三到五倍，Aurora 就無法承受暴增的資料量，特別是物聯網響應時間要求是 10 毫秒以內，即使進行分庫分表，拆散叢集也達不到塗鴉的業務需求。
Apache Ignite
於是塗鴉開始嘗試使用 Apache Ignite，也是一個分散式的 KV 系統，類似於 PingCAP 的 TiKV，它是基於JAVA 架構進行資料分片的，其分片比較大，1G 的資料一個 Partition，並且其擴容沒有 TiKV 這麼線性。如果塗鴉的業務量翻倍，在機器要擴容的時候就不得不停機，還會有資料丟失的風險。這個時期我們在一個 Ignite 後面下掛了 Aurora 作為災備，資料會同步寫到 Aurora 裡面。然而隨著業務量的暴增，一個 Ignite 也不能滿足塗鴉的業務需求，就需要進行擴容，而 Ignite 架構下擴容的時候要求停機，這是物聯網所無法容忍的。
TiDB 3.0 和 4.0
在 2019 年塗鴉在嘗試替換掉 Ignite Cluster 的時候，美國區的儲存裝置已經達到 12 臺節點。恰逢 PingCAP 在杭州舉行 TUG 活動，我們對 TiDB 3.0 進行了驗證測試。但是 TiDB 3.0 上線沒有滿足塗鴉的要求，因為延遲高，吞吐也上不去，嘗試了幾個月以後只好作罷。
時間來到 2020 年，TiDB 4.0 上線了。我們又對 TiDB 4.0 進行了測試，對比 3.0 有非常大的進步，但是延遲高，吞吐量不足的問題依舊存在。這時候 PingCAP 研發團隊針對這個問題進行了深入分析，發現主要的耗時就在 SQL PARSER 層，而 TiKV 底層的儲存是完全閒著的，因為塗鴉的寫入量大，對延遲要求高，完全達不到預期。
既然出現的延時都消耗在 SQL PARSER 層，而物聯網寫入的資料雖然 TPS 高，但業務邏輯沒有那麼複雜，能不能去掉 SQL 層，直接寫入 TiKV 層？我們參照了 PingCAP 提供了 TiKV 的官方 API 文件，宣稱已經支援 JAVA、GO 和 Rust，開始了嘗試和探索。
上線應用的結果很驚喜，得到了全公司的認可。之後我們在全球各個地區都上線了 TiDB 4.0，經過一年的測試，執行正常沒有發現什麼問題，原本需要 12 臺機器，同等配置下現在只要 3 臺機器就能搞定了，也就是說硬體成本只有原本的四分之一。
塗鴉吞吐量上線的時候已經有 20 萬 TPS，以北美區的叢集來看，當時的版本是 4.0.8，查詢的響應時間 99% 是 150 微秒，寫入是 360 微秒（不到一毫秒），有類似場景的小夥伴們可以嘗試一下。
新的挑戰：跨區域部署
但是我們沒有高興多久就遇到了新的挑戰，因為 AWS 部署的時候是三個可用區的部署，比如法蘭克福一部署就是 ABC 三個區域，三個副本之間通訊是要消耗流量，而流量是要收費的，而且塗鴉所有的應用也是部署在三個區，也需要跨區域的呼叫，TiKV 並沒有像 Double 那樣同區呼叫的策略，所以這個費用的成本居高不下，儘管塗鴉只有以前四分之一的機器，但是成本比原本還高。目前進行的解決方案是進行了基於 RPC 的壓縮，降低網路的流量，但這種流量只能解決 Region 複製的流量，應用程式碼跨區的複製流量還是沒有降下來。
我們發現出現這種問題的原因是因為 TiKV 的服務端沒有進行服務端過濾，需要把 TiKV 儲存的資料取回到本地進行應用程式的過濾，然後再塞回去，這個跟 TiKV 的研發團隊進行了溝通，後續的版本可能會推出基於服務端的過濾，降低伺服器的負載，流量成本也可能會下降。
降本增效：從 X86 到 ARM 的架構升級
IoT 行業之所以注重降低成本，因為 IoT 行業的毛利率非常低，我們需要降低每一件模組的成本。在 2020 年 6 月，AWS 推出了 C6G 的產品，價效比宣稱比上一代 C5 高出 40%，於是我們對 AWS 的 C6G 進行了嘗試，但用 TiUP 編譯直接部署的時候發現響應時間比 X86 架構慢 6 到 7 倍，即 TiUP 部署的是通用編譯版本，跟硬體不是那麼貼切。經過測試驗證，發現現有的 TiKV 版本不支援 SSE 指令集，也就是說目前 TiKV 4.0 使用的 RocksDB 版本是不支援 SSE 指令集的。
SSE 指令集主要是進行 CRC 校驗、HASH 和浮點運算的。當時進行了折中方案就是混合部署，TiKV 這邊使用的是 X86 架構，其他節點使用的是 ARM 的架構，但這樣也帶來不方便，如果升級版本的話，指向的映象一會是 X86 的，一會是 ARM 的，這樣會是很麻煩，於是則整體切回了 X86 的架構。
到了今年，TiKV 推出了 5.0 版本，TiKV 5.0 是支援了 aarch 64 優化過的 CRC32C 指令集，也就是 SSE 4.2 指令集，但前提條件是 RocksDB 版本要大於 6.1.2，而 TiKV 5.0 版本的 RocksDB 的版本是 6.4.6，並且在 TiKV 上面可以找到 TiKV 針對 SSE 指令集的優化，也就是說 TiKV 5.0 現在已經完全支援 SSE 指令集了，下半年將會納入重點進行測試，這樣的話成本有可能會更大幅的下降。
業務展望
未來藉助 TiDB 5.0 和 5.1，塗鴉有信心能夠承接數倍的業務增長，預計年底 TiKV 的流量又會翻到現在的三到四倍。大資料平臺也用了 TiDB 作為大屏展示，並且物聯網的裝置流水也正在考慮使用 TiKV 5.1 作為儲存，更大程度上提高易用性，TiDB ARM 版本的部署也在下半年的規劃之中。