业务视角谈谈Kafka（第二篇）

问题1：如果Producer对某些broker中的leader副本进行大量的写入，或者Consumer对某些broker中的leader副本进行大量的拉取操作，那台broker服务器的性能可能成为整个集群的瓶颈，如何解决？

•增加分区，负载均衡实现压力分摊

问题2：为什么Kafka不像Mysql那样允许follow副本对外提供读服务？

•Kafka设计本身已经能满足高性能要求，没有必要过度设计，额外增加系统复杂度。

•同一个topic可以有多个分区，位于多个broker上，支持多台consumer实例并行消费，已经实现压力分摊。不象Mysql，压力都在master节点上

•场景也不太一样，如果不考虑分库分表的复杂性，每台mysql实例存储的是全部数据。而kafka则只是一个分片的数据，同时采用磁盘顺序读写的设计，有较强性能优势（机械磁盘大部分开销花在磁道寻址上）

•kafka是消息队列，通过offset控制消费位移，如果在leader和多个follow副本间同时进行，需要解决一致性问题，控制逻辑实现过于复杂。另外Kafka也不属于典型的读多写少场景，主从分离的优势不明显。

•mysql的读操作天然幂等，而kafka则不是。

•副本同步是异步的，因此有可能出现follow副本还没有从leader副本那里拉取到最新的消息，从而使得客户端看不到最新写入的消息。

问题3：如何加快一个topic的消费速度？

•增加topic的分区数量。引入Consumer Group，将多台Consumer实例绑到同一个组。

问题4：“重平衡” 时Kafka怎么知道已经挂的消费者消费到哪里了？

•重平衡时每个消费者都会尽力去做一次位移提交（如果它会提交位移的话），这样当Rebalance完成后Kafka会告诉它们订阅的分区当前消费到了哪里。

问题5：副本设置多大合适？

•Hadoop三副本是很保守的方案。一般公司如果业务不值钱，冗余一份就够了。如果业务非常重要，可以冗余多份

问题6：leader副本分布在哪台broker上基于什么机制？

•无论leader还是follow副本在broker上的分配策略基本都遵循轮询的公平法则。

问题7：假如broker1挂掉，broker2上的follower副本会变为leader副本吗？过程是什么？

•从ISR中选择存活的第一个副本为新leader•如果ISR为空，看是否开启了unclean leader选举，如果没有开启，那么Kafka干脆就不选leader了，直接将分区置于不可用状态；否则Kafka就从剩下的存活副本中选第一个副本作为leader（这里的顺序就是ZooKeeper中保存的副本集合顺序，即assigned_replicas项）

问题8：Kafka如何保证leader副本和follower副本之间的数据一致性？

•基于领导者（Leader-based）的副本机制，异步拉取消息，并写入到自己的提交日志中，从而实现与领导者副本的同步。

问题9：消费者消费一条数据成功ack后，数据会不会在对应的Partiton删除？

•消息删除与否与消费者没有关系，受Kafka自己的留存策略控制，有定时任务检查

问题10：如果一个生产者，向一个topic一次写100万条消息，那他是会写到这个topic的一个分区还是写到多个分区里面？

•取决于很多因素。首先你的topic有几个分区，另外你的生产者是否指定了消息要被发送的分区？正常情况下，如果你有多个分区且没有指定特定的目标分区，那么producer会把消息发送到多个分区。

问题11：集群已经有3个分区，动态添加两个分区, 原有分区的数据会迁移到新分区吗？

•不会

问题12：如果多条消息组成消息集合发送，那是什么条件控制消息发送，如果是一条又是什么条件控制触发发送的呢？

•主要是这两个参数：batch.size 和 linger.ms。如果是生产了一条消息且linger.ms=0，通常producer就会立即发送这条消息。

问题13：Consumer端从 Kafka 拉取到消息后开启了多个线程异步处理消息，而 Consumer 程序自动地向前更新位移。假如其中某个线程运行失败了，它负责的消息没有被成功处理，但位移已经被更新了，如何解决？

•Consumer 端有个参数 enable.auto.commit，把它设置成 false，采用手动控制提交位移。

问题14：如果消息的存储容量超过了log.retention.bytes，生产者提交消息会不会失败？

•不会，log.retention.bytes 是留存策略，一旦超过阈值开始删除老消息，而不是拒绝新消息。

问题15：消息重复消费有什么解决方案？

•最靠谱的解决方案，消费端业务自己实现，保证消息的幂等

问题16：之前的业务数据是存储在mysql和es，双写非常耗时，导致QPS较低，有什么好的解决方案？

•改成异步消费，借助canel监听mysql主库，监听订单的变化，然后放入kafka，监听kafka，异步刷新到es

问题17：kafka会不会出现消息丢失？怎么解决？

•比如某个分区的leader挂了，在切换选举到其它副本为leader时，这个副本还没来的及同步之前的leader数据，这样数据就丢了。如果在乎数据持久性，应该设置acks=all，意味着leader需要等待所有备份都成功写入日志

问题18：Kafka 机器上没有混布其他服务，一台一个broker，为什么常规需要预留2/3带宽？

•为follower副本同步数据留一些带宽

问题19：如果单机起多个broker，可能造成同一个partition的多个副本在一台机器上，影响容灾能力？

•分布式集群更倾向于使用普通性能的机器搭建，单台单Broker性价比更高。但也要考虑IDC机架位的费用，毕竟现在机器廉价，机架位贵。

问题20：消息重试发送时，分区策略会重新再计算一次吗？

•不会。消息重试只是简单地将消息重新发送到之前的分区

问题21：consumer如何指定想消费的partition？

•consumer.assign()直接指定分区

问题22：如何保证副本均匀分布在broker上？

•创建topic的时候，Kafka会保证所有副本均匀地在broker上保存。

问题23：partition的个数在哪配置？

•topic创建时，需要指定分区数