消息队列(基于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
- 优化主从同步
- 优化生产者
1983
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
