我們在微博上訂閱並關注某些人的微博，這些關注的人發布一條微博的時候，我們開啟微博瀏覽會看到一條條訊息按照時間的逆序在我們的首頁展示出來，我們可以不停地往下閱覽這些訊息。那麼從訊息發布到閱覽，這背後的技術是怎麼實現的呢？下面我們來一看究竟。
方案一：在訊息發布的時候插入同乙個全域性的訊息主表中。當使用者檢視時間時，首先查詢所有關注的物件，列出這些人的所有訊息，最後以時間為序來排序合併。大概的關係型資料模型如下：
1. follows 表
follows 表
欄位名稱
備註follower_id
關注者id
last_sync_id
上次同步的訊息id
last_sync_time
上次同步訊息的最小時間戳
2. message 表
message 表
欄位名稱
備註id
訊息的自增id
send_id
發布訊息的id
text
內容timestamp
發布訊息的時間戳
3. user 表
user表
欄位名稱
備註id
自增user_name
使用者名稱
方案二：對每個使用者維護乙個快取，類似每個使用者都有個郵箱來儲存訊息。當使用者推送新的訊息時，查詢其關注者，將每條訊息插入到每個關注者的快取中。因為已經預先將結果取出，之後訪問的時候效能非常快。
當業務剛開始的時候可以採用第一種方案，因為這時候可能存在很多殭屍使用者，沒必要每次都先把訊息同步到使用者訊息表中。但是隨著業務量的增大，這時候需要同步的訊息會越來越多，如果每次使用者來讀取資料時都需要同步訊息，那麼會造成讀的壓力很大。
這時候可以採用第二種方案，提前把這些訊息同步到使用者的訊息表中，這樣使用者來讀取訊息的時候就無需同步。但是如果某個使用者的關注者很多，例如某某明星，那麼會每次發布一條訊息的時候，會造成寫的壓力。
這時候可以考慮將第一種方案和第二種方案結合起來，普通使用者採用第二種方案，提前將訊息同步好。而某些明星級別的使用者就等使用者讀取訊息時再同步。
而最近在專案中，我們要實現乙個站內的訊息中心，分為單播訊息（該條訊息針對某個使用者）、廣播訊息（針對所有使用者）、組播（某些特徵使用者）。我們的設計方案是單播訊息每次發布訊息都插入到使用者訊息表中，而廣播訊息我們有乙個廣播訊息表，發布廣播訊息的時候則先插入到廣播訊息表中，這時候還沒有同步到使用者訊息表中。而是等到使用者登入的時候，再同步這些訊息。我們再使用者屬性表中記錄上次在廣播訊息表同步的訊息id。這種方案跟上面討論的方案一是一樣的，因為我們的業務量和訊息量處於開始階段。
訊息佇列的兩種模式
支援訂閱組的發布訂閱模式 發布訂閱模式下，當發布者訊息量很大時，顯然單個訂閱者的處理能力是不足的。實際上現實場景中是多個訂閱者節點組成乙個訂閱組負載均衡消費topic訊息即分組訂閱，這樣訂閱者很容易實現消費能力線性擴充套件。可以看成是乙個topic下有多個queue，每個queue是點對點的方式，q...
過濾訊息的兩種方式
在大多數情況下，tag是乙個簡單而有用的設計，其可以來選擇您想要的訊息。例如 defaultmqpushconsumer consumer new defaultmqpushconsumer cid example consumer.subscribe topic taga tagb tagc 消費...
類似Google搜尋提示的兩種做法
做了個簡單的搜尋提示程式，類似google之類的搜尋提示，就是輸入乙個內容時，會把開頭對得上的內容顯示出來。下面可以測試看看 呵呵，這裡沒有顯示有多少條結果，當然也要做到統計也是可以的。這裡只做簡單的顯示。下面就說說兩種做法。第一種，是在使用者輸入提示資訊的時候，把使用者輸入的資訊跟應用中存的資料進...