1、我們爲什麼需要可靠消息？或者希望消息帶有事務？
（1）、我們的某些業務場景希望消息的發送消息和數據庫操作是綁定到一起的-》-需要事務性消息
（2）、我們某些業務場景不希望對外的消息發送丟失，導致業務無法繼續--》消息要可靠
2、消息可靠了，我們會損失什麼？
（1）、消息的順序性
因爲有些消息可能因爲網絡等原因當時發送不出去，後續的消息先發送出去被消費。後續的網絡
（2）、消息的實時性
有些消息
（3）、業務必須冪等--》額外的重複接收消息處理的工作量
3、一個activemq消息服務器會出現哪些問題？
（1）、消息丟失
沒發送到broker上就一定丟失了，在broker上消息丟失，從broker到訂閱者過程中丟失
（2）、併發量大的時候承接不了，服務器假死
單個mq服務器在併發量大的時候會出現網絡io等，cpu爆滿的瓶頸。
（3）、集羣的failover失敗
有些消息體很大的時候。當主服務器假死的時候，從服務器是不知道的。所以無法進行failover。
4、如何解決較大的併發量？
（1）、創建多組集羣，在多組集羣上創建相同的隊列。集羣採用failover的方式做ha
（2）、封裝生產者客戶端，將消息輪詢發送到多組集羣的隊列上。
（3）、封裝訂閱者客戶端，監控多組集羣的相同隊列，將消息消費。
5、如何解決這些問題
（1）、沒發送到broker上就丟失了：在發送broker之前，將消息本地化存儲。收到發送成功的反饋後移除本地文件。實時檢索本地文件，發現超過一定時間沒有發送直接重新發送。
（2）、在broker上丟失：將broker的持久化改成數據庫，將數據庫做主從處理
（3）、從broker到訂閱者丟失：在沒有收到訂閱者成功接收的時候，不移除broker的持久化數據，其實這個貌似有事務支持
（4）、集羣的failover失敗：建立一個測試隊列，定時發送消息測試每個節點是否服務正常。只能通過之類心跳類監控手段來確認服務器是否正常。
6、現階段市場上有哪些解決方案
阿里的notify策略比較類似。metaq更加側重的是訂閱端的數據pull