消息隊列作用一文介紹了為什么要使用消息隊列。我們再來討論下如何有效使用消息隊列。
消息隊列模式
目前主流消息隊列主要由兩種模式，1個是點對點模式，1個是發(fā)布訂閱模式。簡單做下介紹
- 點對點模式
1個消息只會被一個消費者消費?？梢杂幸粋€或者多個消費者同時消費一個隊列，但是被消費的消息不會重復。 - 發(fā)布訂閱模式
消息可以被多個消費者消費。此類隊列一般被稱為一個topic，所有訂閱該topic的consumer都可消費所有消息。
目前市面上有很多消息隊列產品，ActiveMq，RabbitMQ，Kafka，ZeroMQ，golang實現(xiàn)的NSQ，支持的隊列模式基本都可以以上面兩個模式總結，只是實現(xiàn)方式不同，具體選型需要根據(jù)自己的使用場景選擇。
比如kafka以其優(yōu)異的性能應用在日志收集，hadoop技術體系等場景中，但是目前不支持消費端的ack機制，需要consumer自己實現(xiàn)消費的可靠性。
再比如我們考慮優(yōu)先級隊列的場景。kafka可以把不同優(yōu)先級的消息放到topic里指定的partition，給高優(yōu)先級隊列提供性能更好的consumer。如果使用amq，rmq等，可以拆分出不同的queue來實現(xiàn)kafka的分區(qū)功能。根據(jù)自己的技術棧選擇即可。
另外還要考慮技術選型的可維護性，社區(qū)的完善性等。
解耦了嗎
這里再講一下消息隊列的設計問題。
提供一個場景，社交類APP里有很多實體，feed內容，評論，用戶信息等，同時有一個需求，提供統(tǒng)一的open api，將App里的實體信息提供給第三方。
我們選擇消息隊列的方式將各個模塊的數(shù)據(jù)同步給open api，實體信息發(fā)生的變化都都需要通過隊列來發(fā)布。
使用消息隊列，在部署層面上，各個模塊與open api實現(xiàn)了解耦。我們來考慮下細節(jié)，消息體如何設計更合適。
我們可能有兩種思路（可能更多，多思考）。
- 所有模塊將消息發(fā)送到open api定義的隊列里，隊列的消息體由open api定義，open api消費自己的隊列更新數(shù)據(jù)。
- 每個模塊有自己的更新topic，比如評論定義自己的topic，發(fā)生變化時，將評論id連帶信息發(fā)送到隊列里。open api訂閱各個模塊的topic，組裝成自己的實體信息。
思考下，這兩種方式有何優(yōu)缺點？
第一種方式，優(yōu)點是open api實現(xiàn)簡單，不依賴其他系統(tǒng)具體實現(xiàn)，消費消息更新數(shù)據(jù)即可。有沒有什么缺點呢？還是有的。首先各個模塊需要知道open api的數(shù)據(jù)定義方式（消息體），對open api還是有一定依賴。另外，如果還有一個系統(tǒng)，比如審核系統(tǒng)也需要同步評論數(shù)據(jù)做審核，評論模塊還要再發(fā)送一個審核隊列，數(shù)據(jù)格式可能還不相同。再有open api需要要做數(shù)據(jù)檢驗，不能讓評論模塊發(fā)成feed的數(shù)據(jù)。
第二種方式，優(yōu)點是各個實體模塊實現(xiàn)簡單，不需要關注open api實現(xiàn)細節(jié)，同時提供topic模式，其他微服務都可以監(jiān)聽評論的更新消息，更加靈活。缺點就是open api承受了所有的數(shù)據(jù)轉換工作，對實體模塊的消息定義有些依賴。
既然各有優(yōu)缺點，我們如何抉擇呢？需要我們權衡下利弊。有些像CAP原理，不能完全解耦的情況下，二者取其輕。
我個人理解是這樣，
設計模式里有一個基本原則是封裝變化，首先看哪邊變化的多，如果open api數(shù)據(jù)格式經(jīng)常變化，建議選第二種方式，反之，選第一種。
第一種方式還有一個缺點是有些更新比較頻繁的實體會影響其他類型實體進入open api，如果存在消費瓶頸，可以選第二種方式。第二種方式還可以對頻繁更新實體增加消費能力，相當于優(yōu)先級隊列。
