消息队列(基于Kafka)八股复习/面试提词器

消息队列(基于Kafka)

• Kafka高性能原因 - 分段索引 - topic目录+分区文件+段索引行数- 二分查找- 零拷贝 - 什么叫DMA- 原始双拷贝- 怎么实现零拷贝,哪个linux命令- 写入page cache- 顺序写(同分区/不同分区)- 分区过多如何解决?topic过多呢?- 分区的引入(解决了什么问题)- 批量IO 为什么高性能/兜底- 端到端压缩,存在的问题- 总之,高性能体现在什么方面,带来什么样的问题
• 消息队列解决什么问题 - 三大作用 - 异步- 解耦- 削峰- 业务应用场景 - 日志处理- 消息通讯- 订单支付- 超时取消- 不用消息队列带来的三大问题 - 性能差 同步调用/并发性差 但是不绝对- 可用性差 业务必须等待全部下游任务返回才能确认成功.- 扩展性差 接入新业务困难/侵入式设计
• 怎么在Kafka上支持延迟消息 - 哪些消息队列中间件支持延迟消息/怎么做到的/有什么问题 - RabbitMQ插件\NSQ内置/ 基于本地时延数据库/并发性差\基于内存可用性不高- RabbitMQ自行实现:队列设置ttl无消费者绑死信,消息超时自动丢进死信队列,真正业务消费死信/ttl只能设置为队列粒度太大- 定时任务 - Cronin守护进程注册定时任务,但是撑不住高并发- 延时topic+延迟消费者 如何操作/解决什么问题/存在什么问题 - 延时topic只被延迟消费者订阅,后者拉取消息看时间然后sleep/问题是容易被rebalance可以使用pause- 一致性问题 - 先提交还是先转发- 亮点(自创):幂级递增加逐级转发 - 以2的次方形式递增分区对应延时,带延时的消息先发到小于该延时最大的分区(或大于该延时最小分支),消费者接收后判断该延时是否比自己的一半小,是则转发到上述规则分区,否则睡到合适时间,醒来进行转发.优点:理论上可以支持任意时延时间,而空间复杂度只有o(logn)且消费者睡眠时间相对较少,减少无意义的空间占用.问题:小时延分区可能会出现消息积压,可以考虑采取异步批量转发.
• Kafka保证消息有序 - Kafka消息什么级别有序- 全局消息有序/业务消息有序- 单分区策略/存在什么问题/怎么解决 - 消息积压/异步消费- 多分区策略/存在什么问题/怎么解决 - Kafka不能保证同业务同分区\分区负载不均匀/一致性哈希+上线锁消费方法
• Kafka解决消息积压 - 评估:临时性积压/永久性积压(只解决后者)- 增加分区/创建topic(Kafka只允许单分区最多一个消费者)/合理规划- 优化消费者性能 - 消费者降级- 聚合消息与批量操作(Kafka提供接口)- 异步消费/消息丢失/批量提交/重复提交/部分失败/异步重试\丢回队列
• Kafka高可用/消息丢失问题 - Kafka是什么架构/broker如何存储分区合理- Kafka生产者决定写入消息可用性配置参数 - acks- 0:发送直接返回- 1:等待主节点确认返回- all:主节点等待所有ISR确认返回- 什么叫unclean机制,如何禁用- 刷盘机制 - 定时刷(两个参数)一个决定定时检查频率另一个决定需要更新的频率- 定量刷(一个参数)写入page cache检查- 1.保证生产者一定发到Kafka服务器上并正确刷盘 - acks=all 禁用unclean 加大刷盘频率(尽最大努力)- 2.保证服务器高可用,主从节点同步且隔离,宕机恢复可用- 3.保证消息被正确消费后提交 - 异步消费时设置部分重试或丢回队列- 可能存在重复消费
• Kafka重复消费 - 首先业务数据保证幂等(双保险)- 唯一索引(引出问题?) - 要加事务,begin->插入索引->业务操作->commit- 若分布式场景呢? - 核心:第三方数据库+第三方一致性检验- 插入唯一索引到远程数据库->业务操作->更新索引为commit状态- 唯一的问题出现在步骤2和3之间,需要定时任务检验业务操作和数据库,若一致则更新为commit,否则删除索引回滚重试- 分布式场景引申的问题/怎么解决 - 第三方数据库撑不住高并发- 布隆过滤器+redis层层削流
• Kafka 实践高性能 - 优化生产者 - 优化acks- 优化批次- 启用压缩(默认?)/有哪几种压缩算法,各有什么优缺点- 优化broker - 优化swap- 优化网络读写缓冲区- 优化磁盘IO- 优化主从同步