1.背景
REAL TIME
Latency low
data in motion
延時性要求高，系統(tǒng)快速收集數(shù)據(jù)快速處理。 所以需要消息系統(tǒng)，你不能都存下來等一天再處理。不然就不能即使防止類似信用卡盜刷的問題。
歷史數(shù)據(jù)（DATA IN DISK）
DATA IN MOTION（數(shù)據(jù)流動）
需要一個系統(tǒng)去分析數(shù)據(jù) 傳遞數(shù)據(jù)，這就是我們說的消息系統(tǒng)。
2.什么是消息系統(tǒng)
Minix : IPC
Message Apps: wechat/ facebook messenger
TCP: 點到點的消息通訊（通過鏈路層傳遞消息）
Messaging Middle(消息中間件）: AWS SQS(simple queue service)
SNS (push notification)
Open Source: XXX-MQ
MESSAGING VS STREAMING
streaming 偏重計算
messaging 偏重投遞
streaming 有order
messaging 不保證
-
Messaging models
JMS ->1. 點對點（一條消息，對應(yīng)一個生產(chǎn)者和一個消費者）:Queue
2. 發(fā)布訂閱模式 （公告欄，廣播）：Topic
Queue:
image.png FIFO
2.點對點
3.Shared Consumption (消息隊列被共享）No ordering guarantee
SIMPLE JVM Process
sender/producer : 1+ producer threads
receiver/ consumer : 2+ consumer threads
messaging media : LinkedBlockingQueue
System :
sender/producer : 1+ producer machines
receiver/ consumer : 2+ consumer machines
messaging media : Distributed message queue system
用QUEUE的好處：
用淘寶來舉個例子，11.11那天流量 會100倍的增長，系統(tǒng)是按平時的情況去配置的機(jī)器。比如NORMAL 情況下 QPS 為10K，雙11 就可能是 1M
如果我每天都按洪峰去配置，那么就造成了讓費。
為了解決這個問題，淘寶里就有很多的QUEUE。BUFFER的效果。根據(jù)實際的資源，去慢慢處理的這些洪峰的訂單請求。
為什么可以用MQ接受那么大的流量而不能用數(shù)據(jù)庫來做這件事呢？
一個交易可能是個復(fù)雜的事務(wù)操作，而不是簡單的記一筆。用MQ簡化了復(fù)雜性，我只做簡單的一件事，存下來。把快速的發(fā)布者，和慢的消費者解耦合。當(dāng)流量不匹配時，使得系統(tǒng)不會被過高的壓力給擊垮。
缺點就是： 延遲高。
視頻編碼：
上傳的文件會很大，處理一個VEDIO時間特別長。然后往消息隊列丟，這個VEDIO需要轉(zhuǎn)碼。把這個事件轉(zhuǎn)移到其他機(jī)器去離線的做了。這樣就可以異步的完成。
TOPIC（訂閱發(fā)布模式）
好處：一份數(shù)據(jù)可以給多個消費者
Messaging Architecture
橘色和紅色部分是需要考慮的。
一個是存儲(message store)，一個是服務(wù)（broker）
single/multiple server : broker + message store(single/ multiple disks)
producer 和 consumer 會經(jīng)過 broker 進(jìn)行通訊。
CONSUMER 上下線的問題，如何知道上次讀到哪里
BROKER 是否要重傳
用戶最關(guān)心的是：Delivery semantics
消息 at most once 最多只發(fā)一次
at least once 最少一次
exactly once 只被消費一次
使用者的角度，消息能不能丟？
消息能不能重復(fù)？
No retries -> at most once
retries -> at least once
exactly once -> retires + mechanism (de-duplication, transaction)
producer 需要自己產(chǎn)生ID，然后去重。
保證至少一次的設(shè)計。
當(dāng)BROKER投遞了一個消息后，把這個消息從發(fā)送隊里移除，加入到PENDING隊列。
如果對面沒有發(fā)ACK，過了很久，這個時候要把消息從PENDING隊列重新加回發(fā)送隊列。
如果收到ACK，就從PENDING隊列里REMOVE。
