嘗試試用了下rabbitmq ，比activemq 簡單很多，客戶端API很簡潔。
?
先普及幾個概念
?
?
AMQP
1.基本概念：
AMQP（消息隊列協議，Advanced Message Queuing Protocol）是一種消息協議 ，等同于JMS，但是JMS只是java平臺的方案，且只是API級別的一個協議，AMQP是一個跨語言的協議。AMQP允許來自不同供應商的消息生產者和消費者實現真正的互操作擴展，就如同SMTP、HTTP、FTP等協議采用的方式一樣。
?
?
2.AMQP模型
交換器，隊列，消息，綁定
?
2.1 交換器
?
交換器是消息送達的實體。他是具名的。
?
屬性：
passive：交換器不在事先被聲明，如果其不存在將拋出錯誤。
durable：該交換器將在broker重啟后生效。
auto-delete：該交換器將在沒有消息隊列綁定時自動刪除。一個從未綁定任何隊列的交換器不會自動刪除。
?
注意：AMQP 1.0規范將定義可移除的交換器。
?
2.2 隊列
?
隊列是接收消息的實體，具有名字和屬性，但沒有類型。客戶端可以訂閱隊列以便使broker遞送某消息隊列的內容到該客戶端。另，客戶端也可自動到隊列取他所感興趣的消息。
消息確保以它被送往隊列時的順序分發。但在進行某些重新路由的操作如失效處理時，其順序則不能保證。
?
屬性：
alternate-exchange ：當消息被訂閱者拒絕或者由于隊列被刪除而孤立時則被送往此交換器，同時隊列中的該消息被刪除。
passive ? ? ? ? ? ?：當隊列不存在時會拋出一個錯誤信息，仍然不會被聲明。
durable ? ? ? ? ? ?：隊列將在broker重啟時啟動。
exclusive ? ? ? ? ?：隊列僅服務于一個客戶端。
auto-delete ? ? ? ?：隊列在沒有活躍訂閱者的時候將自動刪除。這個類似于具有auto-delete屬性的交換器：如果隊列上從未有活動的訂閱者則不會自動刪除。當客戶端終結時，exclusive類型的隊列則一定會自動刪除。
?
注意：AMQP 1.0中，隊列將替代交換器。
?
2.3 消息
?
消息是不具名的。它被發布到交換器。它由消息頭和消息體組成。消息體是不透明的，而消息頭則由一系列的可選屬性組成：
?
routing-key ? ? ?：該域的使用取決于交換器的類型。
immediate ? ? ? ?：如果至少一個隊列可以接收，但卻沒有訂閱者，則該消息將被當作無路由進行處理。
delivery-mode ：指出該消息可能需要持久性存儲。broker僅對此類消息在被消費前進行最大能力的防丟失措施。如果不能確定broker終結時消息是否投遞成功則可能會發生消息被多次投遞的情況。不具有這個屬性的消息則不會如此。
priority ? ? ? ? ? ? ：相對于其他消息的優先權，范圍0至9.
expiration ? ? ? ?：消息在被broker當作不可路由處理前的存續時間，以毫秒為單位。
?
2.4 綁定
?
綁定是隊列和交換器之間的關系，規定消息如何由交換器到隊列。綁定的屬性被交換器用來與路由算法匹配。綁定和交換器算法可組合形成各種情形：
?
Unconditional：綁定無任何屬性，交換器請求所有的消息。
Conditional on a fixed string ? ? ? ? ? ? ? ?：綁定有一個屬性routingkey，請求所有與此標識相符的消息。
Conditional on a pattern match ? ? ? ? ? ：綁定有一個屬性routingkey，請求所有與此標識的模式匹配的消息。可以使用通配符。AMQP實現了主題匹配模式。
Conditional on multiple fixed strings ? ?：綁定有一個屬性表，請求所有與各個表項匹配的消息。各表項的條件可以是與、或。
Conditional on multiple patterns ? ? ? ? ?：綁定有一個屬性表，請求所有與各個表項的模式匹配的消息。
Conditional on algorithmic comparison ? ?：綁定有一個算術表達式(類似SQL的SELECT WHERE語句)，請求所有頭部匹配此表達式的消息。
Conditional on content inspection ? ? ? ?：綁定指定通配符，請求所有消息實際內容與此條件相符的消息。
?
注意：這些并非全部是標準，取決于具體實現。
?
3.交換類型及對綁定的影響
?
以上4個實體形成了AMQP的基本模型。理解消息如何傳遞到隊列的關鍵在于交換器的類型與路由關鍵字之間的關系。
?
當一個消息的路由關鍵字與綁定中的模式匹配時，交換器會把該消息的拷貝送達隊列。如何進行匹配僅依賴于交換器的類型：
?
direct型 ?：消息的路由關鍵字與綁定相同。
fanout型 ?：總是匹配，即使綁定無關鍵字。
topic型 ? ：匹配路由關鍵字屬性，字符串的各個部分以'.'分隔。可包含兩個特殊字符：'*'表示單個任意詞，'#'表示0個或多個詞，例如 *.stock.# 匹配usd.stock和eur.stock.db，但不匹配stock.nasdaq。
headers型 ：匹配各個鍵-值對的邏輯組合結果。
?
其它由供應商自定義的交換器也被允許。
?
命名隊列到命名交換器的綁定具有強大的屬性——通過綁定使得這兩個實體相互獨立。例如，可以將同一個隊列通過多個綁定連接到同一個或者多個交換器上。或者，多個消費者可以以相同的參數綁定到同一個隊列上，這樣每個消費者僅能得到其他消費者沒有消費的消息。或者，多個消費者可以聲明各自獨立的隊列但共享同一個綁定，如此，每個消費者都將得到與其他消費者相同的消息。
?
注意點：
?
?
AMQP 1.0規范草案改變了AMQP的模型：移除交換器和綁定的概念，代之以隊列和鏈接。這變將導致2個問題：
?
1. 發布者需要知道接收者的拓撲，即何種交換器及其類型；
2. 生產者的流控：如果一個交換器對兩個不同的隊列進行路由，其中一個空閑而另一個近乎滿載，那么如何流控進行呢？
tips:
QOS：（Quality of Service）即服務質量。對于網絡業務，服務質量包括傳輸的帶寬、傳送的時延、數據的丟包率等。在網絡中可以通過保證傳輸的帶寬、降低傳送的時延、降低數據的丟包率以及時延抖動等措施來提高服務質量。
?
?
QoS服務模型
通常QoS提供以下三種服務模型：
1.Best-Effort service（盡力而為服務模型）
Best-Effort服務模型Best-Effort是一個單一的服務模型，也是最簡單的服務模型。對Best-Effort服務模型，網絡盡最大的可能性來發送報文。但對時延、可靠性等性能不提供任何保證。
? Best-Effort服務模型是網絡的缺省服務模型，通過FIFO（first in first out 先入先出）隊列來實現。它適用于絕大多數網絡應用，如FTP、E-Mail等。?
?
2.Integrated service（綜合服務模型，簡稱Int-Serv）
? Int-Serv服務模型Int-Serv是一個綜合服務模型，它可以滿足多種QoS需求。該模型使用資源預留協議（RSVP），RSVP運行在從源端到目的端的每個設備上，可以監視每個流，以防止其消耗資源過多。這種體系能夠明確區分并保證每一個業務流的服務質量，為網絡提供最細粒度化的服務質量區分。
?
3.Differentiated service（區分服務模型，簡稱Diff-Serv）
? Diff-Serv服務模型Diff-Serv是一個多服務模型，它可以滿足不同的QoS需求。與Int-Serv不同，它不需要通知網絡為每個業務預留資源。區分服務實現簡單，擴展性較好。
?
?
已有 0 人發表留言，猛擊->>這里<<-參與討論
ITeye推薦