JAVA理论第十七章-RocketMQKafaka

Kafka

1.1 Kafka 是什么?

Kafka是一款分布式流处理框架，用于实时构建流处理应用。它有一个核心的功能广为人知，即作为企业级的消息引擎被广泛使用

1.2 Kafka 的特点？

高吞吐量、低延迟：Kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒

可扩展性：Kafka集群支持热扩展

持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失

容错性：允许集群中节点失败（若副本数量为n，则允许n-1个节点失败）

高并发：支持数千个客户端同时读写

1.3 什么是消费者组?

消费者组是Kafka独有的概念，如果面试官问这个，就说明他对此有一定了解的。我先给出标准答案：

1、定义：即消费者组是Kafka提供的可扩展且具有容错性的消费者机制。

2、原理：在Kafka中，消费者组是由多个消费者实例构成的组。多个实例共同订阅若干个主题，实现共同消费。同一个组下的每个实例都配置由相同的组ID，被分配不同的订阅分区。当某个实例挂掉的时候，其他实例会自动地承担起它负责消费的分区。

此时，又有一个小技巧给到你：消费者组的题目，能够帮你在某种程度下掌握面试的方向

如果你擅长位移值原理，就不妨再提一下消费者组的位移提交机制;

如果你擅长 KafkaBroker，可以提一下消费者组与 Broker 之间的交互

;如果你擅长与消费者组完全不相关的 Producer，那么就可以这么说:“消费者组要消 费的数据完全来自于 Producer 端生产的消息，我对 Producer 还是比较熟悉的。”

1.4 Kafka 中，ZooKeeper 的作用是什么?

目前，Kafka使用ZooKeeper存放集群元数据、成员管理、Controller选举，以及其他一些管理类任务。之后，等KIP-500提案完成后，kafka将完全不再依赖于ZooKeeper。

记住，一定要突出”目前“，以彰显你非常了解社区的演进计划。”存放元数据“是指主题分区的所有数据都保存在ZooKeeper中，且以它保存的数据为权威，其他”人“都要与它保持对齐。”成员管理“是指Broker节点的注册、注销以及属性变更，等等。“Controller 选举”是指选举集群Controller，而其他管理类任务包括但不限于主题 删除、参数配置等。

不过，判处KIP-500也可能是个双刃剑。碰到非常资深的面试官，他可能会进一步追问你KIP-500是做的/一言蔽之：KIP-500思想，是使用社区自研的基于Raft的共识算法替代zookeeper，实现Controller自选举

1.5 如何估算 Kafka 集群的机器数量?

这道题目考察的是机器数量和所用资源之间的关联关系。所谓资源，也就是CPU、内存、磁盘和宽带

通常来说，CPU和内存资源的充足时比较容易保证的，因此，你需要从磁盘空间和带宽占用两个维度取评估机器数量。

在预估磁盘的占用时，你一定不要忘记计算副本同步的开销。如果一条消息占用1KB的磁盘空间，那么，在由3个副本的主题中，你就需要3kb的总空间来保存这条消息。显示的将这些考虑因素答出来，能够与彰显你考虑问题的全面性，是一个难得的加分项。

对于评估带宽来说，常见的带宽有1Gbps和10Gbps，但你要切记，这两个数字仅是最大值。因此，你最好和面试官确定一个给定的带宽是多少。然后，明确阐述当带宽占用接近总带宽的90%时，丢包情形就会发生。这样能显示出你的网络基本功

1.6 Kafka 为什么不支持读写分离?

这道题目考察的是你对Leader/Follower模型的思考

Leader/Follower模型并没有规定Follower副本不可以对外提供读服务。很多框架都是允许这么做的，只是卡夫卡最初为了避免不一致性的问题，而采用了让Leader统一提供服务的方式

不过，在开始回答这道题时，你可以率先亮出观点：Kafka2.4之后，卡夫卡提供了有限度的读写分离，也就是说，Follower副本能够对外提供读服务

kafka2.4以前不支持读写分离的理由

场景不适用:读写分离使用于那种读负载很大，而写操作相对不频繁（读多写少）的场景，可Kafka不属于这样的场景

同步机制：Kafka采用pull方式实现follower的同步，因此Follower与Leader存在不一致性窗口。如果允许读Follower副本，就势必要处理消息滞后的问题

RocketMQ

2.1 消息中间件的区别？

2.2 为什么要使用MQ？

2.3 RocketMQ由哪些角色组成，每个角色作用和特点是什么？

2.4 RocketMQ消费模式有几种？

2.5RocketMQ如何做负载均衡？