消息队列

1、网络通信、序列化与反序列化、分布式事务、内存管理

1、消息队列产品介绍

产品	优势	不足
RabbitMQ(Erlang编写)(使用的是队列消息模型)	1、支持的语言多；2、路由配置灵活(生产者和对列之间的模块)	1、消息堆积处理不好；2、性能很差。几万~十几万消息/s
RocketMQ (Java编写)	1、响应时延很短；2、性能高：几十万消息/s	1、国产消息队列，与其他生态系统的集成和兼容不够
Kafka (Scala与Java)	1、批量、异步处理好	1、攒一波消息再进行发送，请求量小的时候反而时延会比较高
Pulsar	1、新兴的开源消息队列；2、存储和计算分离的设计	1、成长期

队列模式(一份消息只能被一个消费者消费)：

发布-订阅模式(一份消息可以被多个消费者消费)：

生产者----发布消息

消费者----订阅主题，消费主题中的消息

主题-----传递消息

2、RocketMQ

// 重点理解实现

3、分布式事务

目前的分布式事务都是残缺版的事务。

使用消息队列的场景也需要达到数据一致的要求，此时需要了解事务消息。

简书

MQ：Mafka 事务消息

4、消息丢失

a、分布式链路追踪系统。

b、消息上附属自增的序号id，校验需要的顺序性。—消息队列拦截器中注入

生产阶段(produer) -> 存储阶段(broker) -> 消费阶段(consumer)

5、重复消息处理

MQTT协议->三种消息发布服务质量

名称	解释
至多一次(At most once)	消息最多发送一次，允许消息丢失
至少一次(At least once)	消息至少发送一次，允许消息重复，但消息不能丢失
恰好一次(Exactly once)	恰好一次，消息只会被送达一次，不允许丢失也不允许重复

幂等性：f(f(x)) = f(x), 则f(x)满足幂等性； // 多次作用产生的效果和一次作用产生的效果是一样的

• M1、建一个数据库表代表关联关系，建立字段的唯一索引，通过数据库层保证同样的数据只能有一条
• M2、发消息的时候在消息上加上前置条件，消息中加上版本号(针对指定版本号的数据进行处理)，更新数据时校验版本号
• M3、记录并检查。使用唯一标识加分布式锁实现

6、消息积压

单节点消息队列服务器处理能力：几万-几十万/s

单节点普通业务服务器处理能力(业务逻辑复杂)：几百-几千/s

• 发送端：批量发送/并行发送

  a、每次接收请求并处理请求业务逻辑的是一个线程，多个线程同时处理，同时调起发送消息。 ==> 并行发送

  b、离线处理数据服务，可一次攒很多条数据，一次发送给消息队列。 ==>批量发送

• 消费端：水平扩容Consumer的实例数量(主题的分区数量=消费端的实例数量)

  Q1:消费端可以批量消费吗？