最近一兩年，大部分系統的資料流由基於日誌的離線處理方式轉變成實時的流式處理方式，並逐漸形成幾種通用的使用方式，以下介紹微博的訊息佇列體系。
當前的主要訊息佇列分成如圖3部分：
1、feed資訊流主流程處理，圖中中間的流程，通過相關mq worker將資料寫入cache、redis及mysql，以便使用者瀏覽資訊流。傳統的佇列使用主要是為了將操作非同步處理，起到削峰填谷的作用，並解除多個序列操作之間的耦合關係。
2、流式計算，圖中左邊的流程，主要進行大資料相關實時處理。
3、多機房處理，將資料分發到多個機房，由於微博使用了一種多機房資料對等架構，通過訊息佇列將資料同步到多個機房，因此在每個機房都會有乙個類似蟲洞這樣的訊息收發模組idc exchange mq。
系統的主要單元架構主要特點
實時性：所有的資料在100ms之內處理完成，包括儲存型任務。
可擴充套件性：系統主要單元mq, firehose, worker都是無狀態設計，同乙個pool每個節點可以處理相同的工作，因此可以線性擴充套件。
可用性：由於上述的無狀態設計，可用性可達 99.999%，自動failover，無單點。
資料流設計特點
統一的資料推送通道 firehose
統一的標準化的格式，所有資料採用內部的protocol buffers格式輸出
目前在實時資料流及處理方面存在多種技術，為什麼沒有採用相關成熟的解決方案？
linkedin databus
linkedin databus主要原理是基於資料庫變化事件的觸發寫入乙個統一的databus，所有的業務都消費databus，和firehose解決的問題比較類似，不過firehose是業務主動寫入的事件，在早期做多機房架構時候也曾經嘗試過類似databus資料庫觸發方案，但在乙個高度拆分的資料庫場景中，乙個業務的操作可能對應多個資料庫操作（比如修改索引表和實體表），多個資料庫操作並沒有嚴格的時序性。因此基於資料庫的變化的事件比較難實時合併成乙個完整的業務事件。而通過業務寫入事件只需要乙個簡單的mq操作寫入即可，因此在資料庫有複雜拆分的場景下，業務獨立寫入變化事件結構上更簡單，也保證了事件本身的原子性。
storm
apache storm是和微博架構同一時間發展的技術，主要對worker的管理抽象成乙個框架，支援任務排程，任務容災，任務多級傳遞（bolt a處理完後傳遞給bolt b），資料轉換從worker中分離出來變成獨立的spout。對於乙個複雜且資料來源多樣的環境，storm確實具有更好的優勢。
kafka
apache kafka是乙個分布式的訊息佇列產品，支援按照partition線性擴充套件，投遞上也預設at-least-once。而圖中firehose是一種面向feed業務的訊息服務，同時根據社交關係的特點，還具備根據關係將資料fan-out的能力。
ps：
1、上述內容會在 2014.12.19 archsummit beijing 大資料feed架構演講中介紹，歡迎參會的同行前來交流。
2、有關大資料及流式計算，可參閱前微博同事張俊林的《大資料日知錄》一書。
佇列 使用訊息佇列發布微博
在一些使用者發布內容應用中，可能出現1秒上萬個使用者同時發布訊息的情況，此時使用mysql可能會出現 too many connections 錯誤，當然把mysql的max connections引數設定為更大數，不過這是乙個治標不治本的方法。而使用redis的訊息佇列，把使用者發布的訊息暫時儲存...
使用訊息佇列發布微博
在一些使用者發布內容應用中，可能出現1秒上萬個使用者同時發布訊息的情況，此時使用mysql可能會出現 too many connections 錯誤，當然把mysql的max connections引數設定為更大數，不過這是乙個治標不治本的方法。而使用redis的訊息佇列，把使用者發布的訊息暫時儲存...
Redis應用 使用訊息佇列發布微博
在一些使用者創造內容的應用中 如 sns 微博 可能出現1秒有上萬個使用者同時發布訊息的情況，此時如果只只用mysql資料庫，很可能出現 too many connections 的錯誤，當然，我們可以把mysql的max connections引數設定為更大的值，但這是乙個治標不治本的方法。這時，...