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:消费端可以批量消费吗？