美的中间件面试（部分）

忘是亡心i 2023-10-12 16:00 36阅读 0赞

*  用redis有遇到过大key问题吗，怎么解决
 *  我介绍项目中用异步解耦的思路来从mysql同步数据到redis，具体就是binlog+kafaka。面试官问读的主mysql的binlog,还是从的binlog。A：主mysql。Q：可以用什么中间件读binlog。A：可以用Canal。Q：除了Canal呢。参考答案1：kafka-connect、Maxwell。Q：读主mysql的binlog会有什么问题? 我没觉得有什么问题，找了一些相关文章：[MySQL事务还没提交，Canal就能读到消息了？][MySQL_Canal]、[canal基于binlog同步方案的局限性和思考][canal_binlog]，其中后面那一篇1.2.canal 高可用问题的部分完全没看懂。
 *  当kafka某topic有8个partition, 消费者组的消费者小于8个，会如何分配partition? 参考答案2,3：kafka的3种消费者分区分配策略：

1.  **range** : RangeAssignor对每个Topic进行独立的分区分配:  
    ![在这里插入图片描述][b40aa9911ac24a61b7b8dc1ccc1e70bf.png]  
    这种分配方式明显的一个问题是随着消费者订阅的Topic的数量的增加，不均衡的问题会越来越严重:  
    ![在这里插入图片描述][9f64d1f7765a4208b5ecd47077c838cf.png]
2.  **round-robin** : 将消费组内订阅的所有Topic的分区排序，所有消费者排序后，尽量均衡分配（RangeAssignor是针对单个Topic的分区进行排序分配的）:  
    ![在这里插入图片描述][96bdc43f2d834e16a0e126a9c6f4b26a.png]
3.  **sticky**：sticky分配策略是从0.11.x版本开始引入的分配策略，它主要有两个目的：  
    （1）分区的分配要尽可能均匀。  
    （2）分区的分配尽可能与上次分配的保持相同。  
    当两者发生冲突时，第一个目标优于第二个目标。  
    假设消费者组内有3个消费者（C0、C1、C2），他们都订阅了4个主题（t0、t1、t2、t3）,并且每个主题有两个分区。也就是说，整个消费者组订阅了t0p0、t0p1、t1p0、t1p1、t2p0、t2p1、t3p0、t3p1 8个分区。最终的分配结果为

消费者C0：t0p0、t1p1、t3p0
    消费者C1：t0p1、t2p0、t3p1
    消费者C2：t1p0、t2p1

这看上去似乎与round robin分配策略相同，事实上并不是这样。假设此时C1脱离了消费者组，那么消费者组就会执行rebalance,进而消费分区会重新分配。如果采用round robin策略，那么此时的分配结果如下

消费者C0：t0p0、t1p0、t2p0、t3p0
    消费者C2：t0p1、t1p1、t2p1、t3p1

如果采用sticky分配策略，那么分配结果为

消费者C0：t0p0、t1p1、t3p0、t2p0
    消费者C2：t1p0、t2p1、t0p1、t3p1

可以看到分配结果中保留了上一次分配中对消费者C0和C2的所有的分配结果，并将原来的消费者C1的负担分配给了剩余的两个消费者C0和C1，最终C0和C2的分配还保持了平衡。

*  生产环境下kafka的broker出现硬盘不足的告警，应该怎么办？参考答案：

1.  磁盘扩容4
2.  清理老数据4
3.  Kafka 对于数据迁移的官方说法是分区重分配。即重新分配分区在集群的分布情况。官方提供了kafka-reassign-partitions.sh脚本来执行分区重分配操作5

*  生产环境下kafka发生rebalance，会有什么问题？参考答案6：  
    1、可能重复消费: Consumer被踢出消费组，可能还没有提交offset，Rebalance时会Partition重新分配其它Consumer,会造成重复消费，虽有幂等操作但耗费消费资源，亦增加集群压力  
    2、影响消费速度：频繁的Rebalance反而降低了消息的消费速度，大部分时间都在重复消费和Rebalance
 *  ElasticJob为什么需要zookeeper? 参考答案7,8：  
    Elastic-Job依赖**Zookeeper实现选举**机制，在任务执行实例数量变化时（如启动新的实例或停止实例），会触发选举机制，选举出Leader实例，**Leader主要进行分片的划分**。即将任务划分成多个分片，然后由多个执行的机器分别领取这些分片来执行。比如一个数据库中有 1 亿条数据，需要将这些数据读取出来并计算，然后再写入到数据库中。就可以将这 1 亿条数据划分成 10 个分片，每一个分片读取其中的 1 千万条数据，然后计算后写入数据库。这 10 个分片编号为 0，1，2…9，如果有三台机器执行，A 机器分到分片（0，1，2，9），B 机器分到分片（3，4，5），C 机器分到分片（6，7，8） 。Leader将划分后的结果存放到 zookeeper 中，然后每个节点再从 zookeeper 中获取划分好的分片项。  
    利用 zookeeper 的 watch 机制来监听系统中各种元数据的变化，从而执行相应的操作。  
    持久化各种元数据到 zookeeper，如作业的配置信息，每个服务实例的信息等。
 *  为什么选型elasticJob

--------------------

1.  [kafka-connect实时流的应用][kafka-connect] ↩︎
2.  [Kafka 原理以及分区分配策略剖析][Kafka]\----2.3.2 分区分配策略 ↩︎
3.  [Kafka Rebalance详解][Kafka Rebalance] ↩︎
4.  [阿里云------EMR Kafka磁盘写满运维][------EMR Kafka] ↩︎ ↩︎
5.  腾讯云中间件团队------[避坑指南：Kafka集群快速扩容的方案总结][Kafka 1] ↩︎
6.  [Kafka的Rebalance机制可能造成的影响及解决方案][Kafka_Rebalance] ↩︎
7.  [Elastic-Job 的执行原理及优化实践][Elastic-Job] ↩︎
8.  [本博------如何执行定时任务，以及分布式任务调度][------] ↩︎

[MySQL_Canal]: https://www.cnblogs.com/CtripDBA/p/17265902.html
[canal_binlog]: http://www.fblinux.com/?p=2331
[b40aa9911ac24a61b7b8dc1ccc1e70bf.png]: https://img-blog.csdnimg.cn/b40aa9911ac24a61b7b8dc1ccc1e70bf.png
[9f64d1f7765a4208b5ecd47077c838cf.png]: https://img-blog.csdnimg.cn/9f64d1f7765a4208b5ecd47077c838cf.png
[96bdc43f2d834e16a0e126a9c6f4b26a.png]: https://img-blog.csdnimg.cn/96bdc43f2d834e16a0e126a9c6f4b26a.png
[kafka-connect]: https://blog.csdn.net/tom_fans/article/details/105145969
[Kafka]: https://segmentfault.com/a/1190000039010754
[Kafka Rebalance]: https://blog.csdn.net/qq_35901141/article/details/115710558
[------EMR Kafka]: https://help.aliyun.com/document_detail/423660.html#section-bg0-6qw-1rq
[Kafka 1]: https://cloud.tencent.com/developer/article/1866090
[Kafka_Rebalance]: https://blog.csdn.net/lzxlfly/article/details/106246879
[Elastic-Job]: https://xie.infoq.cn/article/3feec9831ad6984ef26122eca
[------]: https://blog.csdn.net/qq_23204557/article/details/115192329?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522168682880716800215015321%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=168682880716800215015321&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~rank_v31_ecpm-1-115192329-null-null.268%5Ev1%5Ekoosearch&utm_term=elasticjob&spm=1018.2226.3001.4450