在大型互聯網中，主要采用消息中間件來進行業務的解耦和操作的異步化，這也是消息中間件最基礎的特點，也是業務系統對消息中間件的最基本需求。
在這個基礎之上，本篇來談一下業務系統從功能、性能等各個方面對消息中間件的需求。
功能
功能需求核心的其實就發送消息和消費消息，細化下去，發送需求會有同步發送、異步發送，會有實時消息、定時消息等；消費需求會有各種模式，比如業務方主動Pull、或者消息中間件Push的模式等等。
消息發送
消息發送功能從編程接口的角度出發就只有兩個需求：同步發送接口和異步發送接口。
從消息類型的角度出發，會有以下幾點需求：
-
實時消息
-
定時消息
-
事務消息
實時消息最簡單了，Producer發送一條消息，這條消息對Consumer是立即可見的，會盡快被消費掉的。
定時消息則是Producer發出一條消息后，這條消息不是立即可見，可以被消費的，它需要等待一個固定時間之后才能被Consumer進行消息。
事務消息的含義是說它是和業務操作綁定在一起的，要么業務操作成功且消息發送成功，如果業務操作失敗，消息是需要回滾的。這里的事務其實就是表明了業務操作是消息是在一個事務內的，要么都成功，要么都失敗。
對事務消息多說一點。事務消息是個非常有趣的東西，因為業務操作和發送消息是兩個完全獨立的事情，是一個分布式事務，保證他們的一致性就變得非常困難。操作中如果先發消息再做業務，那么可能出現消息發送成功而業務做失敗了，此時就需要撤銷消息（這樣理解其實事務消息稱為可撤銷的消息，即如果業務執行失敗了，將發送的消息撤銷）；如果是先做業務再發消息，那么可能出現業務做成功了消息發送失敗了，此時就需要撤銷業務（先做業務有明顯的問題是消息發送的結果除了成功和失敗，還會有超時的狀態，是無法確認是否發送成功的）。
這里會引申出兩階段提交，第一階段發送消息，之后等業務完成后執行第二階段對消息進行提交。對事務消息，之后會專門出一篇文章描述場景和實現方案的。
另外消息發送還會有順序性的要求，消息的消費順序需要和發送順序保持一致。
消息消費
消費方式上需要提供集群消費和廣播消費（這兩個概念再上一篇都講過了）。另外對消息獲取的方式也會有特定的需求，比如一些業務方是期望由他們自己主動去獲取消息的，另一些會要求以監聽的模式，即提供Listener當有新消息時觸發Listener（對使用Pull還是Push模式也是非常有意思的一點，在之后會寫一篇專門的文章討論我們我們是怎么選擇Pull和Push的）。
和發送一樣，消費端也需要保證消息順序（廢話，如果只保證發送的順序，打這個順序在消費的時候錯亂了，那順序又有什么意義）。
除了這些基礎需求，消費時還會有位點重置的需求，即可以主動去修改消費位點來重新消費消息。
另外從功能上還會有消息跟蹤、消息堆積之類的需求。業務方需要知道一條消息的運行軌跡，定位一條消息從產生到經過MQ，再到被消費的完整軌跡。在高峰期，消息需要先堆積在MQ中之后進行消費（就是削峰的作用）。
性能
性能就兩點：延遲和吞吐。
對業務系統而言，它本身不會容忍在執行消息發送時消耗過多的時間，因為過長的耗時將直接影響它系統的吞吐，所以一般對消息的發送延遲要求都是毫秒級的，平均需要在2ms左右吧。對消費也是一樣，對實時性要求比較高的系統響應的會期望消息從發送出來到被消費到的這個時間盡可能的短。
吞吐也是一樣，因為直接影響到使用MQ的業務系統的性能，所以也是需要一個超過業務系統吞吐上限的能力。RocketMQ給出的性能指標是10字節的消息單機TPS在7w左右，但是沒有給機器指標給出消息延遲之類的指標，筆者也沒有測試驗證過。
可用性
互聯網產品我們會經常聽到高可用的概念，會要求7*24小時運行，可用性達到99.99%之類的描述。可用性是指系統可以提供服務的正常運行時間和總運行時間的比值。
對業務系統而言，中間件是他們依賴的服務，當然是希望可用性越高越好，但是現實中網絡是會故障的，機器是會宕機的，磁盤是會損壞的。所以對消息中間件而言，一般會要求99.99%的可用性之類的，即365天內不可用的時間不允許超過1個小時。
為了滿足可用性的要求，系統需要做備份等等，這些在之后的文章中也會展開去討論。
可靠性
在消息中間件中，業務方對可靠性的要求主要集中在消息會不會丟失。消息不丟失也是對消息中間件最最基礎的要求。
以上內容參考了部分RocketMQ的文檔和阿里雲上MQ的文檔。
結語
這篇文章簡單的概述了一下消息中間件的一些需求，部分需求並非核心需求，比如消息軌跡這樣的需求可能是在你的消息中間件已經完成的基礎下再去談的。
公眾號在計划寫文章時的出發點是去寫一個類似《從入門到XXX😂》的系列文章，所以會先聚焦在核心的功能上不會展開去討論像消息軌跡的實現之類的（可能會放到很后面）。
另外一點也在考慮要不要同時去寫一個討論冪等、一致性之類的分支，畢竟好像這幾篇都太基礎了，沒啥干貨。😕
最后，下一篇可能會寫如何滿足可用性、可靠性的需求，即在可用性和可靠性的基礎上去討論系統架構的選型，暫時叫《消息中間件架構討論》吧（題目取得有點大了）。
歡迎關注此公眾號交流消息中間件相關的技術、經驗等。