消息队列
处理什么样的问题？
对此呢一共有以下几个应用场景。系统崩溃，服务处理能力有限，链路耗时长尾以及日志处理。如何具体应用呢，将很多信息放在可控消息队列当中解决，相当于是缩小了规模。
定义：字面意思，就指的是保存消息的一个容器，属性即为我们所熟知的队列，但同时呢又支持一些额外的功能来处理这些稍微复杂一些的消息，这个队列呢需要支持高吞吐，高并发，并且需要高可用
消息队列其一——kafka（提供搜索服务，直播服务，订单服务，支付服务）
使用方法基本逻辑：
创建集群->新建topic->编写生产者逻辑->编写消费者逻辑
topic架构：多个分片
kafka为什么能支持这么高的吞吐呢？
首先，Producer采用批量发送的形式，减少IO的次数，同时对批量发送的内容进行数据压缩，使得带宽够用；Broker再将已经压缩过后的数据写到磁盘当中，会讲压缩后的数据进行切分，通过偏移量也就是offset来精准索引文件，采取零拷贝的形式；Consumer利用Rebalance的形式完成读入
关于kafka的数据复制问题
①基本重启操作：
关闭，重启；Leader切换，追赶数据；数据同步完成；Leader回切
②替换、扩容、缩容
基本与重启一致，追赶数据的多少问题
关于kafka的负载不均衡问题
这个就没有什么好解决的问题了，往往是拆东墙补西墙，解决方案相当复杂。
以上对kafka的问题进行总结：1.运维成本高2.对负载不均衡的场景，解决方案往往十分复杂3.没有缓存4.Controller，Coordinator和Broker处于同一进程当中，如果IO过多的话会导致性能下降
消息队列其二——BMQ（基于kafka存在的问题，对其进行解决）
BMQ的基础架构架构模型，用于解决kafka存在的问题
BMQ的读写流程（采用的Failover的机制，写入状态机）
BMQ高级特性（泳道，Databus，Mirror，Index，Parquet）
消息队列其三——RocketMQ
RocketMQ的基本概念（Queue，Tag）
RocketMQ的底层原理（架构模型，存储模型）
RocketMQ的高级特性（事务消息，重试和死信队列，延迟队列）
