1.點(diǎn)對點(diǎn) Queue類型

在該消息傳遞模型下，一個消息生產(chǎn)者向消息服務(wù)器端一個特定的隊(duì)列發(fā)送消息籽暇，一個消費(fèi)者從該隊(duì)列中讀取消息温治。在這種模型下，消息生產(chǎn)者知道消息消費(fèi)者的隊(duì)列并直接將消息發(fā)送到消息消費(fèi)者的隊(duì)列戒悠。

a).同一個隊(duì)列可以關(guān)聯(lián)多個消息生產(chǎn)者和消息消費(fèi)者熬荆，但一條消息只能夠被一個消息消費(fèi)者接收；如果多個消息消費(fèi)者正在監(jiān)聽隊(duì)列上的消息绸狐，JMS消息服務(wù)器將根據(jù)“先來者優(yōu)先”的原則確定由哪個消息消費(fèi)者接收下一條消息卤恳，消息消費(fèi)者接收到消息不重復(fù)——比如一個消息發(fā)布者發(fā)布了10個消息，兩個接收者A和B寒矿，那么A和B兩個接收者總共會收到10條消息突琳，不重復(fù)——也就是說一個Queue可以有很多消息消費(fèi)者，并且在多個可用的消息消費(fèi)者中負(fù)載均衡符相；

b).消息生產(chǎn)者不需要在消息接收者接收該消息期間處于運(yùn)行狀態(tài)拆融，消息接收者也不需要在發(fā)送消息時處于運(yùn)行狀態(tài)；

c).消息接收者接收的所有消息都需要簽收啊终，以通知消息服務(wù)器是否已接受镜豹。如果消息服務(wù)器獲知某條消息已經(jīng)被消息消費(fèi)者接收，那么該消息將從消息服務(wù)器端特定的隊(duì)列中移走蓝牲；否則該條消息將保留在消息服務(wù)器端特定的隊(duì)列中趟脂，一直到消息服務(wù)器獲知該條消息已被消息消費(fèi)者接受為止（即如果在消息生成者發(fā)送消息的時沒有消息消費(fèi)者接收該條消息，那么該消息將保留在消息服務(wù)器端特定的隊(duì)列中搞旭，一直到有消息消費(fèi)者接收該條消息）;

d).這種消息傳遞模型是傳統(tǒng)意義上的懶模型或輪詢模型散怖。在此模型中，消息不是自動推動給消息消費(fèi)者的肄渗，而是要由消息消費(fèi)者從隊(duì)列中請求獲得;

2.發(fā)布訂閱（pub/sub）Topic類型

在該消息傳遞模型下，一個消息發(fā)布者向一個特定的消息主題發(fā)布消息咬最，0或多個對此消息主題感興趣的并且處于活動狀態(tài)的消息訂閱者或者建立了持久訂閱的消息訂閱者才可以接收到所發(fā)布的消息翎嫡。在這種模型下，發(fā)布者和訂閱者彼此不知道對方（這種模式好比是匿名公告板）永乌。該模型分Nondurable subscription（非持久訂閱）和durable subscription (持久化訂閱惑申，即消息消費(fèi)者已注冊了特定的主題目標(biāo))2種消息處理方式。

a).與PTP消息傳遞模型不同翅雏，pub/sub消息傳遞模型允許多個主題訂閱者接收同一條消息（即一條消息可以傳遞給多個消息消費(fèi)）：比如一個消息發(fā)布者發(fā)布了10個消息圈驼，有兩個建立了持久訂閱(通過Session接口實(shí)現(xiàn)類調(diào)用createDurableSubscriber方法創(chuàng)建的訂閱者)的消息訂閱者A和B或者有兩個在消息發(fā)布者發(fā)布消息時處于活動狀態(tài)的消息訂閱者A和B，那么A和B兩個消息訂閱者各收到10條消息望几，也就是說總共會收到20條消息绩脆；

b).在發(fā)布者和訂閱者之間存在時間依賴性——當(dāng)消息發(fā)布者向特定的消息主題發(fā)布消息時只有對此消息主題（Topic）感興趣的并且處于活動狀態(tài)的訂閱者才會接收到所發(fā)布的消息（除非訂閱者建立了持久的訂閱。訂閱者建立持久訂閱后，消息發(fā)布者在消息訂閱者處于非活動狀態(tài)時發(fā)布的消息將在消息訂閱者再次處于活動狀態(tài)時重新發(fā)布以使再度處于活動狀態(tài)的消息訂閱者接收到該消息靴迫；

c).消息訂閱者接收的所有消息都需要簽收惕味，以通知消息服務(wù)器是否已接受（即JMS一直保留消息，直至某個特定主題對應(yīng)的所有訂閱者都接收到消息為止）;

d).pub/sub消息傳遞模型基本上是一個推模型玉锌。在該模型中名挥，消息服務(wù)器會自動將特定主題中的消息廣播出去，消息消費(fèi)者無須通過主動請求或輪詢主題的方法來獲得新的消息主守。

消息重發(fā)

如果消息接收者在處理完一條消息的處理過程后沒有對MOM進(jìn)行應(yīng)答禀倔，則該消息將由MOM重發(fā)。需要注意的是参淫，如果采用非事務(wù)持久化消息加Session.CLIENT_ACKNOWLEDGE應(yīng)答模式救湖，當(dāng)消費(fèi)者在處理完消息后沒有主動調(diào)用Message#acknowledge()方法時，MOM不會主動重發(fā)黄刚，如果這時候MOM宕機(jī)了捎谨，當(dāng)重啟MOM后，將消費(fèi)者機(jī)器也重啟后MOM才會重發(fā)消息憔维，但此時的消息不會有重發(fā)標(biāo)記涛救，因?yàn)镸OM都不記得自己有宕機(jī)過，也不知道這些消息被發(fā)送過业扒。

出現(xiàn)以下情況時检吆，消息會被redelivered

A transacted session is used and rollback() is called.

A transacted session is closed before commit is called.

A session is using CLIENT_ACKNOWLEDGE and Session.recover() is called.

? 消息事務(wù)

是指生產(chǎn)者同時發(fā)送幾條消息到broke時，保證所有的消息都發(fā)送成功程储，如果有一條發(fā)送失敗則回滾（發(fā)送之后一定要session.commit,否則事務(wù)將不會被提交）蹭沛。

生產(chǎn)者->broke

? 同步消息：生產(chǎn)者使用持久（PERSISTENT）傳遞模式發(fā)送消息，send( )方法會一直被阻塞章鲤，直到broke返回ACK確認(rèn)消息摊灭。

異步消息：生產(chǎn)者使用非持久（NON_PERSISTENT）傳遞模式發(fā)送消息，生產(chǎn)者不會阻塞send( )方法败徊。

想要使用異步帚呼，在brokerURL中增加 jms.alwaysSyncSend=false&jms.useAsyncSend=true

如果設(shè)置了alwaysSyncSend=true系統(tǒng)將會忽略useAsyncSend設(shè)置的值都采用同步

1) 當(dāng)alwaysSyncSend=false時，“NON_PERSISTENT”(非持久化)皱蹦、事務(wù)中的消息將使用“異步發(fā)送”

2) 當(dāng)alwaysSyncSend=false時煤杀，

如果指定了useAsyncSend=true，“PERSISTENT”類型的消息使用異步發(fā)送沪哺。 如果useAsyncSend=false沈自，“PERSISTENT”類型的消息使用同步發(fā)送。

總結(jié)：默認(rèn)情況(alwaysSyncSend=false,useAsyncSend=false)辜妓，非持久化消息枯途、事務(wù)內(nèi)的消息均采用異步發(fā)送忌怎；對于持久化消息采用同步發(fā)送。

消費(fèi)者確認(rèn)機(jī)制

https://blog.csdn.net/u014401141/article/details/54772847

消息接收的幾種方式

https://blog.csdn.net/songhaifengshuaige/article/details/54177339