这是我参与「第三届青训营 -后端场」笔记创作活动的第2篇笔记.
听过青训营老师讲的消息队列课程，本人对于kafka消息队列的底层原理做了一些总结和归纳：
先来看几个常见的案例：
案例一：
在购物直播间点击购买商品时的流程：
搜索直播间——> 点击商品（后台会新增一条点击的行为记录）——>点击行为记录
但是如果在记录存储的时候服务器出现问题，后台则会发生错误。
案例二：
客户有无数个商品想要买：
发起订单 ——> 处理订单 的请求量太大
该如何承载大量的请求?
案例三：（链路耗时长尾） 订单响应流程太长，操作太慢， 客户发起订单到商家的具体流程：
发起订单——>商家库存记录-1——>客户订单记录+1——>通知商家
处理速度太慢，无法承载大量订单。
总的来说服务器处理有以下四类常见问题：
1.发生系统崩溃，
2.处理服务能力有限
3.链路耗时长尾
4.日志如何处理。
面对这些问题，消息队列的应用就显得尤为重要：
1.针对问题一的解决：解耦
所有行为记录可以存储到消息队列当中，这样如果服务器发生宕机，也会顺利发送到消息队列中
2.针对问题二解决：削峰
处理订单的流程当中每次只获取10个请求
3.针对问题三解决：异步
订单库存商家都不在一个链路上，可以异步修改
4.针对问题四解决：
log——>消息队列——>LogStash——>es——>Kibana
所以什么是消息队列？
指保存消息的一个容器，本质是一个队列，但是这个队列需要支持：高吞吐，高并发，高可用。
消息队列发展历程：
tib ——> ibm mq、webSphere ——> MSMQ ——> jms（sun公司，只能够用在java api上）——> AMQP/RabbitMQ ——> KAFKA ——> RocketMQ ——> PUlsar（雅虎内部）
业界消息队列：
kafka：分布式的，分区的，多副本的日志提交服务（高吞吐环境下）。
RocketMQ：低延迟，强一致，高性能，高可靠，实时比较广泛
Pulsar：是下一代云原生分布式消息流平台，集消息，存储，轻量化函数式计算为一体，存算分离的架构设计
BMQ：和pulsar架构类似，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的卡夫卡集群。
本文详细介绍消息队列kafka：
使用场景:
1.离线的消息处理
2.日志信息
3.metric数据
4.搜索点赞评论收藏
如何使用kafka：
创建集群——>新增topic——>编写生产者逻辑——>编写消费者逻辑
kafka的架构：
cluster(集群)里面有多个topic，不同topic解决不同的问题，pattition（分区，可以并发处理）处理生产侧，Consumer处理消费侧.
partition内部有不同的消息，且每个消息由递增的offset，可以理解为唯一id，再partition内部严格递增。partition内部有严格递增。partion还有一个副本数，partition每个分片有多个Replica，以此来达到容灾的作用。
follower把leader数据从上拉下，并保持一样的状态。
对于集群cluster来说，其上面还有一个zookeeper：负责存储集群的元信息。
一条消息队列的过程：
producer——>broker机器——>consumer消费
producer与broker之间一发一收不能满足大量的业务需求：
方法：可以批量发送减少io次数，从而增强发送能力，带宽流量太大。
方法：通过压缩算法进行压缩再发送。
broker的存储：（切分）
会从partition到log存储Logsegment（.log .index .timeindex 其他文件）
broker磁盘结构：
磁头找到对应磁道找到对应的扇形区域，最后写入。，因为寻道成本较高，所以顺序写入比较好
broker如何找到消息：
发送request，broker会指定offset处的消息，按照时间窗口和信息大小窗口发送给consumer，寻找数据。
kafka提高吞吐和稳定性的功能总结：
Producer:批量发送，数据压缩
Broker：顺序写，消息索引，零拷贝
Consumer：Rebalance
kafka的缺点：
Broker不同分区有不同副本，对于每一个副本，数据都会存到该结点上，并通过数据复制的方式，最终达到集群。由此产生的问题：关闭broker1会选取broker2，但读写依旧进行，导致1和2数据不一致 ，需要重启的周期非常长（并且不能并发重启，两个分片在两台机器上是不一样的）
对于kafka集群来说，由于数据复制，必定带来事件成本，使得运维成本很高2.负载不均衡；
要将partiton3迁入Broker，会带来io升高的问题。
问题总结：
1.运维成本高
2.对于负载不均衡的场景，解决方法复杂
3.没有自己的缓存，完全依赖Page Cache
4.Controller和Coordinator和Broker在同一进程中，大量io会造成其性能下降
