阿里看了都说赞的微服务架构实战PDF

过去几年，“微服务架构”这个术语出现了，它描述了一种将软件应用程序设计为可独立部署的服务套件的特定方式。

49页PPT干货：微服务架构起源、简介及设计

尽管这种架构风格没有确切的定义，但围绕业务能力，自动化部署，端点智能以及语言和数据的分散控制等方面存在着某些共同特征。

“微服务” 是在拥挤的软件架构街道上又一个新名词。尽管我们的自然倾向是以轻蔑的眼光来传递这样的东西，但这些术语描述了一种我们发现越来越吸引人的软件系统风格。

我们已经看到许多项目在过去几年中都采用了这种风格，迄今为止的结果是积极的，因此对于我们的许多人来说，这正成为构建企业应用程序的默认风格。可悲的是，没有太多的信息概述微服务的风格以及如何去做。

简而言之，微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制(通常是 HTTP 资源的 API)进行通信。

这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。

在这里就简单记录一下期间我问到的一些关于 Kafka 的面试题目，这些都是我平时在学习 Kafka 的一些总结要点。

谈谈你对 kafka 的整体认识br> 问这个问题主要是想知道面试者对 Kafka 的整体认识如何，能够大致了解面试者对 Kafka 的相关概念的熟悉程度，比如消息、topic、partition、replica、offset、重平衡、leader/follower、ISR 等等。

谈谈 Kafka 吞吐量为何如此高br> 多分区、batch send、kafka Reator 网络模型、pagecache、sendfile 零拷贝、数据压缩。

谈谈你对生产者储水池机制的理解
sender 线程工作机制、ByteBuffer 缓冲区的作用等等：

• 如何提高 kafka 吞吐量/strong>

生产端调整 batch.size、linger.ms 参数，以及主题分区数合理分配等。

• 生产者 producer 是线程安全的吗线程实例还是单线程实例优缺点/strong>

• 消费者 consumer 是线程安全的吗线程实例、单线程实例、单 consumer + 多 worker 线程的优缺点/strong>

消息拉取时，什么情况下会造成消息重复消费谈你对位移提交的理解br> 理解消息交付语义：

最多一次（atmostonce）：消息可能丢失也可能被处理，但最多只会被处理一次；

至少一次（atleastonce）：消息不会丢失，但可能被处理多次；

精确一次（exactlyonce）：消息被处理且只会被处理一次。

假若消费者在消费前提交位移，那么就是“最多一次”，若在消费后提交位移，那么就是“最少一次”，如果能够保证消费和提交位移同在一个事务中执行，就可保证“精确一次”。__consumer_offsets的一些理解。

什么时候会产生消费组重平衡以及重平衡会涉及到哪些相关参数、频繁重平衡会造成哪些后果br> 消费组成员变更、主题数量变更、订阅信息变更；session.timeout.ms、max.poll.interval.ms、hearbeat.interval.ms；

kafka 默认不支持自动分区重分配，那么如果让你来执行分区重分配，有哪几个步骤，以及在重分配过程中 kafka 会有哪些动作br> RAR、OAR、AR、RAR-OAR、OAR-RAR 相关概念，

谈谈你对 Preferred leader 选举的理解br> 在 broker 挂掉之后，分区 leader 会变更，久而久之就会变得不均衡，Kafka 默认序号最小的副本为 Preferred leader，在 broker 重启回来后，Kafka 会重新调整分区的 Preferred leader 成为 leader，Preferred leader 选举分为手动选举和自动选举，涉及参数 auto.leader.rebalance.enable，还有个默认允许 10% 不均衡策略等等。

谈谈你对 ISR 副本同步的理解SR 副本同步的缺陷有哪些br> 谈谈你对水印备份机制的理解EO 更新机制、HW 更新机制br> 水印备份机制的一些缺陷据丢失、数据离散何解决的（leader epoch）
谈谈你对 controller 机制的理解ontroller 主要有哪些功能br>

更新集群元数据信息、创建主题、删除主题、分区重分配、preferred leader 副本选举、主题分区扩展、broker 加入集群、broker 崩溃、受控关闭、controller leader 选举。

• Kafka 的日志存储机制/strong>

每个分区拥有单独的日志（partition log）、顺序写、到一定大小分成日志段文件（log segment file）、每个 log 文件对应一个索引文件（.index .timeindex）等等。

Kafka 分区数越多性能就越好吗什么br> 我的理解：

每个分区数都对应一个 log 文件，log 文件是顺序写的，但如果有非常多分区同时刷盘，就会变相成乱序写了，我猜想这也是为什么 RocketMQ 一个 broker 只会拥有一个 CommitLog 的原因之一吧；
客户端会为每个分区调用一条线程处理，多线程并发地处理分区消息，分区越多，意味着处理的线程数也就越多，到一定程度后，会造成线程切换开销大；
其中一个 broker 挂掉后，如果此时分区特别多，Kafka 分区 leader 重新选举的时间大大增加；
每个分区对应都有文件句柄，分区越多，系统文件句柄就越多；
客户端在会为每个分区分配一定的缓冲区，如果分区过多，分配的内存也越大。

小伙伴们有兴趣想了解更多相关学习资料请点赞收藏+评论转发+关注我之后私信我，注意回复【000】即可获取更多免费资料！ 

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92624 人正在系统学习中

来源：倾听铃的声