这是我参与「第三届青训营 -后端场」笔记创作活动的第3篇笔记。
案例
- 系统崩溃-->解耦
- 服务能力有限-->削峰
- 链路耗时长尾-->异步
- 日志存储-->日志处理：Log-消息队列-LogStash-ES-Kibana
消息队列概述
定义
消息队列（MQ），指保存消息的一个容器，本质是个队列。
- 需支持高吞吐
- 高并发
- 高可用
业界消息队列对比
- Kafka：分布式的、分区的、多副本的日志提交服务，高吞吐场景
- RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，实时场景
- Pulsar：是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、存算分离的架构设计
- BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
消息队列-Kafka
- Kafka：分布式的、分区的、多副本的日志提交服务，高吞吐场景
使用场景
搜索、直播、订单、支付
如何使用Kafka
- 创建Kafka集群
- 在集群中创建一个Topic，并设置好分片数量
- 编写生产者逻辑，引入对应语言的SDK，配置好集群和Topic等参数
- 编写消费者逻辑，引入对应语言的SDK，配置好集群和Topic等参数
基本概念
Topic：Kakfa中的逻辑队列，每一个不同的业务场景就是一个不同的topic，对于这个业务来说，所有的数据都存储在这个topic中
Cluster：Kafka的物理集群
Producer：消息的生产端，负责将业务消息发送到Topic当中
Consumer：消息的消费端，负责消费已经发送到topic中的消息
Partition：通常topic会有多个分片，不同分片直接消息是可以并发来处理的，提高单个Topic的吞吐
Kafka 架构
其他参考： Kafka 的系统架构
提高吞吐或者稳定性功能
- Producer：批量发送、数据压缩
- Broker：顺序写，消息索引，零拷贝
- Consumer：Rebalance
问题总结
- 有数据复制的问题，Kafka运维的时间成本和人力人本高
- 对于负载不均衡的场景，我们需要有一个较为复杂的解决方案进行数据迁移，从而来权衡IO升高的问题
- Kafka没有自己的缓存，在进行数据读取时，只有Page Cache可用，不是很灵活
- Controller 和 Coordinator和Broker 在同一进程中，大量 IO会造成其性能下降
消息队列-BMQ
- BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
架构图
Broker-Partition 状态机
对于写入逻辑，还有一个状态机机制，用来保证不会出现同一个分片在两个Broker上同时启动的情况，另外也能够保证一个分片的正常运行。
Controller做好分片的分配之后，如果在该Broker分配到了Broker，首先会start这个分片，然后进入Recover状态。
消息队列- RocketMQBMQ
- RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，实时场景
RocketMQ 架构
- 数据流通过Producer发送给Broker集群，再由Consumer进行消费
- Broker节点有Master和Slave的概念
- NameServer为集群提供轻量级服务发现和路由
高级特性
- 事务消息，库存服务和消息队列必须要是在同一个事务内的
- 延迟消息
- 重试和死信队列
