TableStore（表格存儲）的用戶羣裡面有很大一部分都是Feed流的客戶，包括一些很出名的，大家經常使用或看到的公司的Feed流系統、通知系統等都是基於表格存儲的。

Feed流系統裡面最關鍵的是：兩系統，一模型的選型。

兩系統分別是存儲系統和推送系統選擇。

  • 存儲系統：
    • 重點關注數據可靠性、擴展性、成本、是否適合存儲海量數據以及數據量大了是否影響性能這些方方面面。
    • 選擇一般有兩種，一種是關係型資料庫，一種是NoSQL資料庫，對於關係型資料庫，在可靠性，擴展性，成本，海量數據支持上讀不如NoSQL資料庫，而關係型資料庫擅長的功能在Feed流系統裡面基本用不到，所以，這一塊建議是用NoSQL。TableStore作為阿里雲的分散式NoSQL資料庫，10個9的可靠性非常適合用來存儲這些消息。
  • 推送系統：
    • 重點關注讀寫延遲、可用性、穩定性、吞吐等這些方面。
    • 選擇一般兩種，Redis或者分散式NoSQL（比如Cassandra，BigTable，TableStore等），一般情況下Redis可以滿足需求，但是為了保證高可用和高吞吐，需要replica，分散式等部署方式，這樣不僅帶來運維複雜度，而且帶來費用的增加。這一塊，對於阿里雲客戶，是建議使用TableStore的，而且TableStore的主鍵列自增功能可以自動為每條想消息生成一個順序ID，這樣讀取的時候可以根據順序ID順序讀，極大簡化了系統的架構設計。
  • 一模型：推拉模型
    • 對於推拉模型，也就是讀寫擴散，從產品方面來看，寫擴散是更有利於產品的，也更有利於做千人千面，但是寫擴散成本會大一些，在類似微博這種某些大V粉絲上億的系統裡面，一條微博可能會擴散1億份，這種擴散在TableStore上性能不是問題，之前測試過使用阿里雲的一核一GB的共享型ECS，搭配TableStore-Timeline，每秒可以寫入5.3萬行。主要問題是存儲成本，但是考慮到推送系統的消息生命週期可以很短，且現在存儲成本逐年下降的情況下，全部使用寫擴散也是一種可以考慮的情況，如果寫擴散量太大，可以使用寫擴散為主，讀擴散為輔的設計，比如對於活躍用戶使用寫擴散，非活躍用戶使用多擴散等等，這些都屬於折中方案了。

由於TableStore有大量的Feed流用戶，所以為了簡化用戶的使用，我們開發了一個TableStore-Timeline LIB，可以簡化用戶的使用。目前已經開源到GitHub。

上面大概說了下Feed流系統的存儲，推送系統選型，如果還想深入瞭解，可以看看下面兩篇文章：

  • 如何打造千萬級Feed流系統
  • TableStore發布Timeline Lib：輕鬆構建千萬級IM和Feed流系統

上面兩篇文章分別從Feed流系統設計，和Timeline抽象層描述了Feed流、IM系統類的設計和實現，希望對你有用。

如果有啥問題，可以聯繫我。

推薦閱讀：
查看原文 >>
相關文章