这是我参与「第五届青训营 」伴学笔记创作活动的第15天。
消息队列前世今生
系统崩溃的解决方法：解耦。
服务器处理能力有限的解决方法：削峰。
链路耗时长尾的解决方法：异步。
日志处理
消息队列：保存消息的一个容器，本质是一个队列。
消息队列的属性：高吞吐、高并发、高可用。
消息队列的发展历程：TIB->IBM MQ/WebSphere->MSMQ->JMS->AMQP/RabbitMQ->Kafka->RocketMQ->Pulsar。
Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色。
RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活性的可扩展性，在一些实时场景中运用较广。
Pulsar：下一代云原生分布式效力六平台，集信息、存储、轻量化函数式计算为一体、采用存算分离的架构设计。
BMQ：存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。
消息队列-Kafka
使用场景：离线消息处理，搜索服务、直播服务、订单服务、支付服务，日志信息，Metrics数据，用户行为。
使用Kafka的方法：创建Kafka集群->新增Topic->编写生产者逻辑->编写消费者逻辑。
Topic：逻辑队列。
Cluster：物理集群，每个集群中可以建立多个不同的Topic。
Producer：生产者，负责将业务信息发送到Topic中。
Consumer：消费者，负责消费Topic中的信息。
ConsumerGroup：消费者组，不同组消费者消费进度互不干扰。
Offset：消息在partion内的相对位置信息，可以理解为唯一ID，在partion内部严格递增。
每个分片内部有多个Replica（副本），来达到一个容灾的作用，Leader Replica将会从ISR（In-Sync Replicas（同步状态的副本））中选出，其他Replica为Follower Replica，Leader Replica起到一个对外写入读取的作用，Follower Replica不断拉取Leader Replica中读取的数据，尽量与Leader Replica保持一致状态，如果与Leader Replica差距过大会被踢出ISR，现在差距一般用时间差距衡量。
当Leader Replica出现问题，会将当前的Leader Replica踢出ISR，并从ISR中重新选出一个Leader Replica，并向前倒退最大时间差距重新写入读取信息。
数据复制
ZooKeeper：负责存储集群元信息，包括分区分配信息。
通过压缩，可以减少信息大小，Kafka支持Snappy（默认使用）、Gzip、LZ4、ZSTD（推荐）压缩算法。
Broker信息文件结构
传统数据拷贝
零拷贝
磁盘：移动磁头找到对应磁道，磁盘转动，找到对应扇区，最后写入，顺序写可以减少巡道成本。
通过二分法算短目标时间段，通过寻找Offset找到最终数据。
Producer特性：批量发送、数据压缩。
Broker特性：顺序写、消息索引、零拷贝。
Consumer特性：Rebalance。
Kafka问题：运维成本高，对于负载不均衡的场景解决方法复杂，完全依赖Page Cache没有自己的缓存，大量IO会由于Controller和Coordinator和Broker在同一进程中导致整体性能下降。
消息队列- BMQ
BMQ：兼容Kafka协议，存算分离，云原生消息队列。
BMQ架构图
不存在数据复制，因为BMQ的Proxy和Broker是无状态的。
BMQ重启、替换、扩容、缩容后，都可以直接对外服务，并且都是秒级完成。
写入文件是通过选择一定数量的随机的DataNode进行写入。
四层负载均衡四层负载均衡工作在OSI模型的传输层，由于在传输层，只有TCP/UDP协议，这两种协议中除了包含源IP、目标IP以外，还包含源端口号及目的端口号。四层负载均衡服务器在接受到客户端请求后，以后通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。
七层负载均衡七层负载均衡工作在OSI模型的应用层，应用层协议较多，常用http、radius、dns等。七层负载就可以基于这些协议来负载。这些应用层协议中会包含很多有意义的内容。比如同一个Web服务器的负载均衡，除了根据IP加端口进行负载外，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。
由于随机选择节点，分配相对均匀，解决了负载不均衡问题。
状态机是为了解决脑裂问题。
使用了状态机可以保证对于任意分片在同一时刻只能在一个Broker上存活。
Broker写文件流程
多机房部署的特性
BMQ的高级特性：泳道、Databus、Mirror、Index、Parquet。
BOE：一套完全独立的线下机房环境。
PPE：产品预览环境。
开发流程：开发->BOE->PPE->Prod。
直接使用原生SDK的问题：客户端配置较为复杂，不支持动态配置，更改配置需要停掉服务，对于latency不敏感的业务batch效果不佳。
Databus的作用：简化消息队列客户端复杂度，解耦业务与Topic，缓解集群压力，提高吞吐。
使用Mirror通过最终一致的方法，解决跨Region读写问题。
直接在BMQ中将数据结构化，配置索引DDL，异步构建索引后，通过Index Query服务读出数据。
直接在BMQ中将数据结构化，通过Parquet Engine，九二一使用不同的方式构建Parquet格式文件。
