消息队列
消息队列：支持高吞吐、高并发、高可用的保存消息的队列
kafka
放到消息队列的数据：处理日志信息、metrics数据（程序状态的采集）、用户行为数据 创建kafka集群-新建topic-便携生产者逻辑-编写消费者逻辑
基本概念
topic
定义：逻辑队列，中间有patition分区，partition可以并行 patition内部： offset，标识消息的相对位置信息，在patition内部严格递增 replica:不同的replica在不同的机器上，达到容载的作用。 leader对外进行写入/读取，直接与生产者/消费者对戒。 follower不断从leader拉取数据。 isr 机制（时间，offset差距）保证高可用。r当leader宕机之后选择最相似的follower
cluster:物理集群，每个集群中可以建立多个不同的topic
cluster！= broker brokers 是Kafka中的节点，broker中包含不同topic的partition。 producer- broker- producer controller broker负责对集群中的所有replica通过计算分配 存储方式？ 顺序写入message。 offset偏移量索引-二分查找 时间戳索引-通过时间戳找offset-offset二分查找 数据拷贝？ broker零拷贝。磁盘空间-内存空间
- 顺序写，消息索引、零拷贝提高吞吐性和稳定性
producer
吧业务消息发送到topic中
- 批量发送，数据压缩-提高吞吐性、稳定性
consumer
负责消费topic中的信息 consumergroup:不同组之间的消费进度互不干涉 low level: 手动分配consumer消费那些partition 很快 不能容载；consumer不够的话会导致进程起停 high-level: broker中的一个coordinator broker进行rebalance rebalance? 找一个负载最低的broker作为coordinator,
- rebalance提高吞吐性、稳定性
缺点
- leader（broker1）重启的时候，follower（broker2）变成leader，实现leader的切换。 由于全过程一直有数据的输入，leader一直需要接受数据。 因此，broker1重启之后，需要追赶数据（让offset缩小到一定的范围），复制leader（broker2）的数据 由于某些原因，需要实现leader的会切，也就是让broker1重新成为leader,broker1就需要在短时间内复制大量的数据。 最终导致时间过长。 节点的复制时间成本较高
- 负载不均衡 迁出broker还需要考虑数据迁移。
- 运维成本高
- 对于负载不均衡的场景，解决方案复杂
- 对于自己的缓存，完全依赖page cache
- controller和coordinator、broker在同一进程中，大量io会导致性能下降
