| 核心思想 | 子分類 | 服務(wù)端的框架 | 移動端的框架 |
|---|---|---|---|
| 消息傳輸模型 | 生產(chǎn)者消費(fèi)者模型（Producer-Consumer） | Handler消息機(jī)制 | |
| 消息傳輸模型 | 發(fā)布訂閱模型（Pub/Sub 或Publisher-Subscriber） | Kafka（或Jafka） | |
| 消息傳輸模型 | 發(fā)布訂閱模型（Pub/Sub 或Publisher-Subscriber） | Redis | |
| 消息傳輸模型 | 發(fā)布訂閱模型（Pub/Sub 或Publisher-Subscriber） | RabbitMQ | |
| 消息傳輸模型 | 發(fā)布訂閱模型（Pub/Sub 或Publisher-Subscriber） | ZeroMQ | |
| 消息傳輸模型 | 發(fā)布訂閱模型（Pub/Sub 或Publisher-Subscriber） | ActiveMQ |
【Kafka生產(chǎn)者發(fā)送消息】
- 消息路由：
a. 發(fā)送消息時如果指定了 Partition鼻吮，則直接使用渤愁。
b. 如果指定了 Key犁享，則對 Key 進(jìn)行哈希枝哄，選出一個 Partition扑毡。
c. 如果都未指定狱意，通過 Round-Robin 來選 Partition就乓。 - 消息并不會立即發(fā)送片部，而是先進(jìn)行序列化后，發(fā)送給 Partitioner暇番，由 Partitioner 確定目標(biāo)分區(qū)后嗤放，發(fā)送到一塊內(nèi)存緩沖區(qū)中（發(fā)送隊列）。
- Producer 的Sender 線程則負(fù)責(zé)實時地從該緩沖區(qū)中提取出準(zhǔn)備好的消息封裝到一個批次內(nèi)壁酬，統(tǒng)一發(fā)送到對應(yīng)的 Broker 中次酌。
Radis發(fā)布訂閱使用：參考這個：https://www.cnblogs.com/longjee/p/8668974.html
ZeroMQ架構(gòu)圖：
參考：https://blog.csdn.net/flourishLi/article/details/54962713
ActiveMQ架構(gòu)圖：
EventBus
EventBus很像NATS（一對一恨课，多對一）
RxJava
Dagger2
Android事件分發(fā)機(jī)制用的責(zé)任鏈設(shè)計模式。對比服務(wù)端Spring框架中的Filter的加載流程和執(zhí)行流程就是用的責(zé)任鏈設(shè)計模式岳服。參考：實際項目中運(yùn)用責(zé)任鏈模式
生產(chǎn)者消費(fèi)者模式解析
生產(chǎn)者消費(fèi)者模式是通過一個容器來解決生產(chǎn)者和消費(fèi)者的強(qiáng)耦合問題剂公。生產(chǎn)者和消費(fèi)者彼此之間不直接通訊，而通過阻塞隊列來進(jìn)行通訊吊宋，所以生產(chǎn)者生產(chǎn)完數(shù)據(jù)之后不用等待消費(fèi)者處理诬留，直接扔給阻塞隊列，消費(fèi)者不找生產(chǎn)者要數(shù)據(jù)贫母，而是直接從阻塞隊列里取文兑，阻塞隊列就相當(dāng)于一個緩沖區(qū)，平衡了生產(chǎn)者和消費(fèi)者的處理能力腺劣。
這個阻塞隊列就是用來給生產(chǎn)者和消費(fèi)者解耦的绿贞。縱觀大多數(shù)設(shè)計模式橘原，都會找一個第三者出來進(jìn)行解耦籍铁，如工廠模式的第三者是工廠類，模板模式的第三者是模板類趾断。
參考：http://www.reibang.com/p/dc77009c45d2
圖解：
生產(chǎn)者消費(fèi)者模型簡單實現(xiàn)（Java多線程就是一個典型的示例）
參考：http://www.reibang.com/p/678be034abe2
總結(jié)一下：發(fā)布訂閱模式大量適用于服務(wù)端架構(gòu)拒名，這種思想也逐漸在移動端的SDK以及第三方框架里面開始擴(kuò)展開來，這種編程思想是很重要的芋酌，掌握了發(fā)布訂閱模式的思想增显，其實不管是什么開發(fā)，都可以快速實現(xiàn)一個類似的框架脐帝，歸根到底換湯不換藥同云，只是具體的體現(xiàn)形式不一樣而已，需要花點(diǎn)時間去掌握一下堵腹。
