如何使用拉模式設計信息流系統？

所謂拉模式，指的是用戶自行獲取其關注的所有人的微博，并按照發布時間的倒序進行排序和整合，從而生成信息流數據的方法。在設計微博信息流系統時，會發現用戶的收件箱不再必要，因為信息流數據不再源自收件箱，而是來自發件箱。發件箱中包含了用戶關注的所有人數據的整合。因此，用戶在發布微博時只需將其寫入自己的發件箱，而不再需要將其推送給粉絲的收件箱。這意味著在獲取信息流時，需要查詢發件箱的數據

這個邏輯我還用 SQL 的形式直觀地表達出來，方便你理解。假設用戶 A 關注了用戶 B、C、D，那么當用戶 B 發送一條微博的時候，他會執行這樣的操作：

insert into outbox(userId, feedId, create_time) values("B", $feedId, $current_time); //寫入B的發件箱

當用戶 A 想要獲取他的信息流的時候，就要聚合 B、C、D 三個用戶收件箱的內容了：

select feedId from outbox where userId in (select userId from follower where fanId = "A") order by create_time desc

確實，拉模式相較于推模式具有明顯的優勢。首先，它解決了推送延遲的問題。在拉模式下，大 V 發微博時不再需要將消息推送到每個粉絲的收件箱，因此消除了推送延遲。其次，存儲成本大幅降低。

在推模式下，每條微博都需要被復制并寫入到每個粉絲的收件箱，而在拉模式下，只需保留發件箱，無需復制微博數據，從而降低了存儲成本。最后，拉模式具有更好的功能擴展性。例如，如果微博增加了分組功能，用戶想將關注的 A 和 B 分成一個單獨的組，那么 A 和 B 發布的微博就形成了一個新的信息流。在拉模式下，只需查詢該分組下所有用戶（即 A 和 B），然后查詢這些用戶的發件箱，按時間倒序重新排序聚合即可實現這個信息流。

List<Long> uids = getFromGroup(groupId); //獲取分組下的所有用戶
Long<List<Long>> ids = new ArrayList<List<Long>>();
for(Long id : uids) {
  ids.add(getOutboxByUid(id)); //獲取發件箱的內容id列表
}
return merge(ids); //合并排序所有的id

對于拉模式而言，盡管在業務上關注數有上限，但它并非完美無缺的方案。下面是針對拉模式可能存在的問題的優化建議：

查詢和聚合成本高： 在拉模式下，需要對多個發件箱的數據進行查詢和聚合，這可能會導致成本較高。針對這個問題，可以利用緩存來優化。根據用戶瀏覽信息流的特點，可以只緩存最近一段時間內的微博 ID，而不是所有用戶的所有微博。比如，僅緩存每個用戶最近幾天內發布的微博 ID。這樣，可以減少緩存的存儲成本，并在查詢時從多個緩存節點并行獲取數據，以加快查詢速度。

緩存節點帶寬成本高： 緩存節點的帶寬成本可能會很高，特別是在高流量情況下。針對這個問題，可以采取一些優化措施。例如，可以考慮對緩存數據進行壓縮，減少數據傳輸量，從而降低帶寬消耗。此外，可以使用更高帶寬的網絡設備或增加緩存節點數量來提升系統的帶寬處理能力。

推拉結合的方案是怎樣的？

這個方案的確是一個有效的解決方案，可以實現大 V 用戶微博推送的精準化，以及活躍用戶的識別和管理。以下是方案中關鍵點的總結和潛在的實施方法：

大 V 用戶識別： 以粉絲數為判斷標準是合理的方法，超過一定數量的粉絲可被視為大 V 用戶。這個閾值可以根據實際情況進行調整。一旦識別出大 V 用戶，系統就可以將他們作為特殊對象來處理。

活躍用戶標記： 活躍用戶的標記是方案的關鍵。可以通過記錄用戶最近幾天內的操作行為來判斷其活躍狀態，如刷新信息流、發布微博、轉發評論、點贊等。這些操作可以作為活躍用戶的判斷依據。

活躍粉絲列表管理： 對于大 V 用戶，需要維護一個活躍粉絲列表。這個列表應該是定長的，當一個用戶從不活躍變為活躍時，將其加入到相關大 V 用戶的活躍粉絲列表中。當列表長度超過設定值時，可以采取先進先出的策略，移除最早加入的粉絲，以保持列表的有效性。

微博推送和收件箱更新： 對于活躍粉絲，實時推送大 V 用戶的微博；對于不活躍粉絲或不在大 V 用戶的活躍粉絲列表中的用戶，將大 V 用戶的微博異步插入到其收件箱中，以保證其信息流數據的完整性。

圖片

推拉結合的方式可以在一定程度上彌補推模式的缺陷，但也帶來了額外的維護成本。隨著粉絲數量的增加，活躍粉絲列表的維護和推送延遲都會成為系統的瓶頸，這時候轉換為拉模式可能會更為合適。

在粉絲數量較大的情況下，拉模式相對于推模式更具可擴展性和效率。拉模式不需要維護活躍粉絲列表，也不需要實時判斷用戶的在線狀態，因此可以減少系統的維護成本和推送延遲。同時，拉模式也更適合應對高流量的情況，因為它不需要頻繁地向大量用戶推送消息，而是由用戶自行拉取所關注用戶的微博信息，減輕了系統的壓力。

因此，在粉絲數量較大、流量不斷增加的情況下，將推拉結合的方式轉換為純粹的拉模式可能會更好地支撐業務的發展，并提供更穩定、高效的服務。

總結：

在拉模式下，我們只需要保存用戶的發件箱，用戶的信息流是通過聚合關注者發件箱數據來實現的；

拉模式會有比較大的聚合成本，緩存節點也會存在帶寬的瓶頸，所以我們可以通過一些權衡策略盡量減少獲取數據的大小，以及部署緩存副本的方式來抗并發；

推拉結合的模式核心是只推送活躍的粉絲用戶，需要維護用戶的在線狀態以及活躍粉絲的列表，所以需要增加多余的空間成本來存儲，這個你需要來權衡。拉