15. Messaging System

1.背景
REAL TIME
Latency low
data in motion
延时性要求高，系统快速收集数据快速处理。 所以需要消息系统，你不能都存下来等一天再处理。不然就不能即使防止类似信用卡盗刷的问题。
历史数据（DATA IN DISK）
DATA IN MOTION（数据流动）
需要一个系统去分析数据 传递数据，这就是我们说的消息系统。

2.什么是消息系统
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 不保证

3. Messaging models
   JMS ->1. 点对点（一条消息，对应一个生产者和一个消费者）:Queue
   2. 发布订阅模式 （公告栏，广播）：Topic
   Queue:

   
   
   image.png

4. FIFO
   2.点对点
   3.Shared Consumption (消息队列被共享）

5. 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倍的增长，系统是按平时的情况去配置的机器。比如NORMAL 情况下 QPS 为10K，双11 就可能是 1M
如果我每天都按洪峰去配置，那么就造成了让费。
为了解决这个问题，淘宝里就有很多的QUEUE。BUFFER的效果。根据实际的资源，去慢慢处理的这些洪峰的订单请求。

为什么可以用MQ接受那么大的流量而不能用数据库来做这件事呢？

一个交易可能是个复杂的事务操作，而不是简单的记一笔。用MQ简化了复杂性，我只做简单的一件事，存下来。把快速的发布者，和慢的消费者解耦合。当流量不匹配时，使得系统不会被过高的压力给击垮。

缺点就是： 延迟高。

视频编码：
上传的文件会很大，处理一个VEDIO时间特别长。然后往消息队列丢，这个VEDIO需要转码。把这个事件转移到其他机器去离线的做了。这样就可以异步的完成。

TOPIC（订阅发布模式）

image.png

好处：一份数据可以给多个消费者

Messaging Architecture

image.png

橘色和红色部分是需要考虑的。
一个是存储(message store)，一个是服务（broker）

single/multiple server : broker + message store(single/ multiple disks)

producer 和 consumer 会经过 broker 进行通讯。
CONSUMER 上下线的问题，如何知道上次读到哪里
BROKER 是否要重传

用户最关心的是：Delivery semantics
消息 at most once 最多只发一次
at least once 最少一次
exactly once 只被消费一次

使用者的角度，消息能不能丢？
消息能不能重复？

image.png

No retries -> at most once
retries -> at least once
exactly once -> retires + mechanism (de-duplication, transaction)
producer 需要自己产生ID，然后去重。

保证至少一次的设计。

当BROKER投递了一个消息后，把这个消息从发送队里移除，加入到PENDING队列。
如果对面没有发ACK，过了很久，这个时候要把消息从PENDING队列重新加回发送队列。
如果收到ACK，就从PENDING队列里REMOVE。