TableStore TimeLine 的爬坑指南
我們在 https://blog.csdn.net/u013501718/article/details/89425060 一文中，介紹了一個類似於微博、網易雲的消息中心模塊的設計和實現思路。今天跟大家介紹一下我們的實現後升級數據時踩的一些坑。
本次考慮到消息中心的數據量會比較大，所以持久層使用了阿里的 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 封裝，推薦幾篇文章，感興趣的可以去了解一下。
如果對於 TableStore 的介紹，大家可以看看這篇文章