走进消息队列
什么是消息队列
从本质上说消息队列就是一个队列结构的中间件，也就是说消息放入这个中间件之后就可以直接返回，并不需要系统立即处理，而另外会有一个程序读取这些数据，并按顺序进行逐次处理。
也就是说当你遇到一个并发特别大并且耗时特别长同时还不需要立即返回处理结果，使用消息队列可以解决这类问题。
消息队列主要解决了应用耦合、异步处理、流量削锋等问题。
当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，而部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能。
消息队列MQ，指保存消息的一个容器，本质是个队列，但这个队列需要支持高吞吐，高并发，并且高可用。
案例引入:1.系统崩溃，2.服务能力有限，3.链路耗时长尾，4.日志存储
消息队列开发出来是为了解决问题的。
1.解耦，2.削锋，3.异步，4.消息队列日志存储
Kafka：分布式的，分区的，多副本的日志提交服务，在高吞吐场景下发挥出色
RocketMQ:低延迟，强一致，高性能，高可靠，万亿级容量和灵活的可扩展性，在一些实时场景中运用较广。
Pulsar：下一代云原生分布式消息流平台，靠消息，存储，轻量化函数式计算为一体，采用存算分离的架构设计。
BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。
消息队列Kafka
offset：消息在partition内的相对位置信息，可以理解为唯一id，在partition内部严格递增。
Replica：每个分片(partition)有多个Replica，Leader Replica将会从ISR中选出。负载，数据复制概念，放进不同服务器。
ZooKeeper:负责存储群元信息，包括分区分配信息等.
一条消息的自述:
消息的batch批量发送，数据压缩机制，减少消息大小。
Broker消息文件的结构。
顺序写提高写入的效率。
Broker是什么:
在 kafka 里面,broker是消息的中介,生产者producer往broker里面指定的topic中写消息,消费者consumer从broker里面拉取指定topic的消息,然后进行业务处理,broker在中间起到一个代理保存消息的中转站。
Produce:批量发送，数据压缩
Broker：顺序写，消息索引，零拷贝
Consumer：Rebalance
提高高并发，高吞吐的能力
缺点:
1.运维成本高
2.对于负载不均衡的场景，解决方案复杂
3.没有自己的缓存，完全依赖Page Cache
4.Controller和Coordinator和Broker在同一进程中，大量IO会造成其性能下降。
字节内部BMQ
兼容Kafka协议，存算分离，云原生消息队列
架构图:
Broker-Partition状态机:保证对于任意分片在同一时刻只能在一个Broker上存活。
泳道消息:
开发->BOE->PPE->Prod
BOE: 字节的一套完全独立的线下机房环境
PPE:产品预览环境
Apache Parquet是Hadoop生态圈中一种新型列式存储格式，它可以兼容Hadoop生态圈中大多数计算框架(Hadoop，Spark等)，可以被多种查询引擎支持(Hive，Impala，Drill).
1.BMQ的架构模型(解决Kafka存在的问题)
2.BMQ读写流程(FailOver机制，写入状态机)
3.BMQ高级特性(泳道，Databus，Mirror，Index，Parquet)
RocketMQ
使用场景:
例如，针对电商业务线，涉及广泛，如注册，订单，库存，物流；同时，也会设计许多业务峰值时刻，如秒杀活动，周年庆，定期特惠。
RocketMQ基本概念:
高级特性:
1能够处理事务场景，具有最终一致性。
2延迟发送,定时任务。
3.消费重试和死信队列
RocketMQ基本概念:(Queue，Tag)
RocketMQ底层原理:(架构模型，存储模型)
RocketMQ高级特性:(事务消息，重试和死信队列，延迟队列)
常用开源消息队列总结:
个人思考:
消息队列是微服务架构中不可或缺，应用广泛的一环，但凡涉及到微服务，很多中间件和业务都需要消息队列来进行转移和存储，但是目前未知我所学的内容还没到微服务的阶段，所以各种消息队列也没有机会了解。但是没有应用场景，也应该深度理解其中的原理，这对于多种知识都有着促进的作用.
