- 核心参数
- 持久化
- 常见面试题：
- 如何保证消息不重复消费
- 造成消息重复消费的原因
- 根本原因：在消息处理后未及时提交 offset
- 由于网络延迟、机器高 cpu 占用等原因导致 kafka 认为此消费者已经处于假死状态，进行了 rebalance
- 解决方案
- 关闭消息的自动提交，改为手动提交，在拉取到消息之后、处理消息之前提交offset，但是这样就造成消息丢失的可能性，一般基建比较好的公司在大数据部门的支持下，在凌晨（服务低潮期） 通过定时任务的方式进行补足
- 最有效：数据处理的时候做觅等，比如redis的set、数据库的主键均具有天然的觅等性
- 造成消息重复消费的原因
- 如何保证消息不丢失
- 关闭自动提交，在数据处理完之后手动提交 offset
- 如何保证消息顺序消费
- kafka 的分区设置为，这种方式强烈不建议使用，仅仅是八股文的解决方案。我们在选取 kafka 这种 mq 的时候大部分原因由于kafka的超高吞吐。这么高的吞吐就是因为分区的思想，现在分区变成 一个，与 kafka 的设计背离。
- 在业务当中很难有全局有序性，更多的是局部有序性，比如一个订单的从点击、加购物车、下单、付款，我只要保证我的这四个步骤有序即可。所以真正的场景 是将这四步有序，我们不妨将这四步的有序操作放在 kafka 上游，合成一条日志消息发到 kafka ，这样就保证了严格有序，也没有牺牲任何吞吐
- 加入我就是碰上全局有序的场景，这样的话放到下游去做，在日志消息中有顺序维度比如时间，让下游在自己的存储中使用时排序
- kafka如何能保证高吞吐
- 分区
- pull方式拉取数据
- 如何预估分区数量和大小
- //todo
- 如何保证消息不重复消费
消息队列面试的时候，建议要结合自己的业务场景来说明，不能光背八股，还要尽量考虑周全，尤其是边界情况
| 特性 | Kafka | RabbitMQ | RocketMQ |
|---|---|---|---|
| qps | 百万 | 万 | 万 |
| 事务支持 | 支持 | 支持 | 支持 |
| 社区活跃 | 活跃 | 活跃 | 一般 |
- Redis
- 常见的五种数据结构及底层实现
- bitmap的使用及优势场景
- redis的"快"的原因
- redis的持久化文件rbd和aof的原理及使用
- redis三种集群模式
- redis同步机制
- redis流量和存储倾斜
- 布隆过滤器
- redLock的优劣
- Memcached
- Zookeeper