- 使用方式（嵌入模式、集群模式） - 概念：具體某一個隊列、整個隊列的創建、使用。一個broker - 連接方式（連接池？） - 支持協議 - 幾個端口作用、以及監控實現 - 消息模式（發送訂閱和點對點消息） - 與其它消息隊列比較 - 消息確認機制（事物） - ActiveMQ的設置消息時長，事務，確認機制 ，持久化(六)（http://blog.csdn.net/u014401141/article/details/54772847） - 集群方案（內嵌代理所引發的問題：消息過載、管理混亂） ### 隊列使用 講解流程 前言：斷連導致消息丟失問題，消費者沒有中斷。 1、隊列的優點，大概說一下（異步、系統之間解耦） 2、隊列的使用場景，復雜的交易系統消息異步，實現系統解耦合。 3、activemq相關（幾個端口，支持的協議，應用的連接方式，隊列的詳細：broker、及隊列及管理） 消息模式，消息時長的設置，事務，持久化機制。 4、我們對activemq的應用，應用內嵌模式。及用了之后的好處 (異步，提高系統性能、緩沖或者流量削峰，降低系統壓力、防止不正常因素<系統停止，連接斷連，>導致消息丟失，持久化消息) 或者說彌合 生產者和消費者速度和穩定性 不一致的差異。實現系統間解耦。 舉例，之前的積分系統，需要請求賬戶系統做積分增加。但賬戶系統某一天凌晨2點會停機升級。那這個積分就加不上了。 目前系統中的斷連的情況，沒有消息隊列，消息只能丟失，或者沒有好的處理方式防止丟失。 [為什么需要消息隊列](http://www.ywnds.com/?p=5791) 系統的性能（并發量，吞吐量，響應時間）會有瓶頸 [聊聊QPS/TPS/并發量/系統吞吐量的概念](http://blog.csdn.net/cainiao_user/article/details/77146049) > 短信發送時間肯定能達到1000，但完成單個事務的平均處理時間受到數據庫操作的影響，兩個同步數據庫操作，一個insert，一個update。 所以最多處理一秒1000個比較難。做一些細節的優化。 [數據庫優化](https://wiki.quartz.ren/database/mysql-optimize.html)