TableStore TimeLine 的入坑指南

咱們在 仿微博消息中心的系統設計與實現 一文中，介紹了一個相似於微博、網易雲的消息中心模塊的設計和實現思路。今天跟你們介紹一下咱們的實現後升級數據時踩的一些坑。

本次考慮到消息中心的數據量會比較大，因此持久層使用了阿里的 TableStore（簡稱：ots）。在實現上，則使用了阿里提供的 TimeLine 封裝。

若是你是從 0 到 1 搭建消息中心的話，該封裝基本上夠用。但若是你同咱們同樣，不是從 0 到 1，須要考慮舊數據遷移的話，那我建議你仍是要慎重。若是數據量不是大到無可奈何，我仍是建議你優先使用關係型數據庫結合 nosql 的產品去實現。

接下來咱們一塊兒來看看升級過程可能碰到的一些坑，若是你也有同樣的場景，歡迎一塊兒討論。

坑一：升級效率較低，遷移方案的開發較繁雜。因爲使用了 TimeLine，遷移時，只能使用 TimeLine 的 sdk 去同步寫（異步寫，可能會亂序）。這就致使了升級時間會被拖長。若是數據量大的時候，這個遷移過程，就是個很大的問題。

坑二：若是以前的消息存在不一樣表結構中，而後如今但願表 A 和表 B 的點贊消息合併到一個時間線中，咱們只能本身先將表 A 和表 B 的數據合併，而後再作升級。因爲數據量都較大，這個合併的難度較大，耗時較長。

坑三：因爲 TimeLine 中的 sequenceId 是自增列。也就是說 sequenceId 是插入 ots 後，由 ots 自動產生。那麼就致使，咱們一旦升級失敗，咱們沒法重複升級。咱們能作的有三種。1.記住失敗的地方，而後從該處接着升。 2.遍歷查詢已升級的數據，而後批量刪除（ots 的限量刪除限制 200 筆），這種刪除方式能夠想象寫起來有多蛋疼。 3.直接刪庫重建，但若是已經升級了 90% 的數據了，這個時候去刪庫，顯然不是一個很好的選擇。無論是哪一種方式，其實風險都是比較高的。

坑四：若是是 2B 的企業往下看，不是的話能夠跳過本段。其實這個是對坑三的補充，因爲在 ots 沒有庫的概念，因此咱們只能在一張表裏去存全部租戶的數據。若是某個租戶升級時異常了，部分用戶升級一半數據，咱們會比較難處理。若是刪數據重升的話，刪除某個租戶的數據又很差刪（只能遍歷刪除，作法低效）。若是不刪數據，使用 TimeLine 又沒法重複升級。這個問題暫時無解。

關於 TimeLine 升級過程的這些坑，咱們本身也無解，後續考慮再也不使用 TimeLine 封裝。你們若是有碰到同樣的場景或相似的問題，歡迎留言討論！！

關於 TableStore 和 TimeLine 封裝，推薦幾篇文章，感興趣的能夠去了解一下。

什麼是表格存儲。

TimeLine介紹