Java面试：2021.05.29

1、Kafka的架构是怎样的？

图片

Kafka 的整体架构非常简单，是分布式架构，Producer、Broker 和Consumer 都可以有多个。 1.Producer，Consumer 实现 Kafka 注册的接口。 

2.数据从 Producer 发送到 Broker 中，Broker 承担一个中间缓存和分发的作用。 

3.Broker 分发注册到系统中的 Consumer。Broker 的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。 

4.客户端和服务器端的通信，是基于简单，高性能，且与编程语言无关的 TCP 协议。 几个重要的基本概念： Topic：特指 Kafka 处理的消息源（feeds of messages）的不同分类。 Partition：Topic 物理上的分组（分区），一个 Topic 可以分为多个 Partition 。每个 Partition 都是一个有序 的队列。Partition 中的每条消息都会被分配一个有序的 id（offset）。 

replicas：Partition 的副本集，保障 Partition 的高可用。  leader：replicas 中的一个角色，Producer 和 Consumer 只跟 Leader 交互。  follower：replicas 中的一个角色，从 leader 中复制数据，作为副本，一旦 leader 挂掉，会从它 的 followers 中选举出一个新的 leader 继续提供服务。

Message：消息，是通信的基本单位，每个 Producer 可以向一个Topic（主题）发布一些消息。 

Producers：消息和数据生产者，向 Kafka 的一个 Topic 发布消息的过程，叫做 producers 。 

Consumers：消息和数据消费者，订阅 Topic ，并处理其发布的消息的过程，叫做 consumers 。 

Consumer group：每个 Consumer 都属于一个 Consumer group，每条消息只能被 Consumer group 中的一个 Consumer 消费，但可以被多个 Consumer group 消费。

Broker：缓存代理，Kafka 集群中的一台或多台服务器统称为 broker 。

Controller：Kafka 集群中，通过 Zookeeper 选举某个 Broker 作为 Controller ，用来进行 leader election 以及 各种 failover 。

ZooKeeper：Kafka 通过 ZooKeeper 来存储集群的 Topic、Partition 等元信息等。

2、Kafka 和 RocketMQ的区别。

😈 单纯角色来说，Kafka 和 RocketMQ 是基本一致的。比较明显的差异是： RocketMQ 从 Kafka 演化而来。 

1、Kafka 使用 Zookeeper 作为命名服务；RocketMQ 自己实现了一个轻量级的 Namesrv 。 

2、Kafka Broker 的每个分区都有一个首领分区；RocketMQ 每个分区的“首领”分区，都在 Broker Master 节 点上。

RocketMQ 没有首领分区一说，所以打上了引号。

3、Kafka Consumer 使用 poll 的方式拉取消息；RocketMQ Consumer 提供 poll 的方式的同时，封装了一 个 push 的方式。 

RocketMQ 的 push 的方式，也是基于 poll 的方式的封装。

… 当然还有其它 …

3、Kafka的应用场景有那些？

图片

1）消息队列 

比起大多数的消息系统来说，Kafka 有更好的吞吐量，内置的分区，冗余及容错性，这让 Kafka 成为了一个很好的 大规模消息处理应用的解决方案。消息系统一般吞吐量相对较低，但是需要更小的端到端延时，并常常依赖于 Kafka 提供的强大的持久性保障。在这个领域，Kafka 足以媲美传统消息系统，如 ActiveMQ 或 RabbitMQ 。 

2）行为跟踪 Kafka 的另一个应用场景，是跟踪用户浏览页面、搜索及其他行为，以发布订阅的模式实时记录到对应的 Topic 里。那么这些结果被订阅者拿到后，就可以做进一步的实时处理，或实时监控，或放到 Hadoop / 离线数据仓库里 处理。

3）元信息监控 作为操作记录的监控模块来使用，即汇集记录一些操作信息，可以理解为运维性质的数据监控吧。

4）日志收集 

日志收集方面，其实开源产品有很多，包括 Scribe、Apache Flume 。很多人使用 Kafka 代替日志聚合（log aggregation）。日志聚合一般来说是从服务器上收集日志文件，然后放到一个集中的位置（文件服务器或 HDFS）进行处理。 然而， Kafka 忽略掉文件的细节，将其更清晰地抽象成一个个日志或事件的消息流。这就让 Kafka 处理过程延迟更 低，更容易支持多数据源和分布式数据处理。比起以日志为中心的系统比如 Scribe 或者 Flume 来说，Kafka 提供 同样高效的性能和因为复制导致的更高的耐用性保证，以及更低的端到端延迟。

5）流处理 这个场景可能比较多，也很好理解。保存收集流数据，以提供之后对接的 Storm 或其他流式计算框架进行处理。 很多用户会将那些从原始 Topic 来的数据进行阶段性处理，汇总，扩充或者以其他的方式转换到新的 Topic 下再继 续后面的处理。 例如一个文章推荐的处理流程，可能是先从 RSS 数据源中抓取文章的内容，然后将其丢入一个叫做“文章”的 Topic 中。后续操作可能是需要对这个内容进行清理，比如回复正常数据或者删除重复数据，后再将内容匹配的结果返 还给用户。这就在一个独立的 Topic 之外，产生了一系列的实时数据处理的流程。Strom 和 Samza 是非常著名的 实现这种类型数据转换的框架。

6）事件源 

事件源，是一种应用程序设计的方式。该方式的状态转移被记录为按时间顺序排序的记录序列。Kafka 可以存储大 量的日志数据，这使得它成为一个对这种方式的应用来说绝佳的后台。比如动态汇总（News feed）。

7）持久性日志（Commit Log） 

Kafka 可以为一种外部的持久性日志的分布式系统提供服务。这种日志可以在节点间备份数据，并为故障节点数据 回复提供一种重新同步的机制。Kafka 中日志压缩功能为这种用法提供了条件。在这种用法中，Kafka 类似于 Apache BookKeeper 项目。

4、mybatis中当实体类中的属性名和表中的字段名不一样，怎么办？

第一种， 通过在查询的 SQL 语句中定义字段名的别名，让字段名的别名和实体类的属性名一致。代码如下：

<select id="selectOrder" parameterType="Integer" resultType="Order">     SELECT order_id AS id, order_no AS orderno, order_price AS price    FROM orders         WHERE order_id = #{id} </select>

这里，还有几点建议： 

1、数据库的关键字，统一使用大写，例如： SELECT 、 AS 、 FROM 、 WHERE 。 

2、每 5 个查询字段换一行，保持整齐。 

3、 , 的后面，和 = 的前后，需要有空格，更加清晰。 

4、 SELECT 、 FROM 、 WHERE 等，单独一行，高端大气。

第二种，是第一种的特殊情况。大多数场景下，数据库字段名和实体类中的属性名差，主要是前者为下划线风格， 后者为驼峰风格。在这种情况下，可以直接配置如下，实现自动的下划线转驼峰的功能。

<setting name="logImpl" value="LOG4J"/>    <setting name="mapUnderscoreToCamelCase" value="true" /></settings>

😈 也就说，约定大于配置。非常推荐！

第三种，通过 <resultMap> 来映射字段名和实体类属性名的一一对应的关系。代码如下：

<resultMap type="me.gacl.domain.Order" id=”OrderResultMap”>     <!–- 用 id 属性来映射主键字段 -–>     <id property="id" column="order_id">     <!–- 用 result 属性来映射非主键字段，property 为实体类属性名，column 为数据表中的属性 -–>     <result property="orderNo" column ="order_no" />     <result property="price" column="order_price" /></resultMap>
<select id="getOrder" parameterType="Integer" resultMap="OrderResultMap">         SELECT *          FROM orders          WHERE order_id = #{id} </select>

此处 SELECT * 仅仅作为示例只用，实际场景下，千万千万千万不要这么干。用多少字段，查询多少字段。 相比第一种，第三种的重用性会一些。

5、Mybatis 动态 SQL 是做什么的？都有哪些动态 SQL ？能简述一 下动态 SQL 的执行原理吗？

Mybatis 动态 SQL ，可以让我们在 XML 映射文件内，以 XML 标签的形式编写动态 SQL ，完成逻辑判断和动 态拼接 SQL 的功能。 

Mybatis 提供了 9 种动态 SQL 标签： <if /> 、 <choose /> 、 <when /> 、 <otherwise /> 、 <trim /> 、 <where /> 、 <set /> 、 <foreach /> 、 <bind /> 。 

其执行原理为，使用 OGNL 的表达式，从 SQL 参数对象中计算表达式的值，根据表达式的值动态拼接 SQL ，以此来完成动态 SQL 的功能。

6、MySQL 中 varchar 与 char 的区别？varchar(50) 中的 50 代表的涵义？

1、varchar 与 char 的区别，char 是一种固定长度的类型，varchar 则是一种可变长度的类型。 

2、varchar(50) 中 50 的涵义多存放 50 个字符。varchar(50) 和 (200) 存储 hello 所占空间一样，

但后者在排序时会消耗更多内存，因为 ORDER BY col 采用 fixed_length 计算 col 长度(memory引擎也一 样) 。

所以，实际场景下，选择合适的 varchar 长度还是有必要的。

7、一张表，里面有 ID 自增主键，当 insert 了 17 条记录之后，删除了第 15,16,17 条记录，再把 MySQL 重启， 再 insert 一条记录，这条记录的 ID 是 18 还是 15？

一般情况下，我们创建的表的类型是 InnoDB ，如果新增一条记录（不重启 MySQL 的情况下），这条记录的 ID 是18 ；但是如果重启 MySQL 的话，这条记录的 ID 是 15 。因为 InnoDB 表只把自增主键的大 ID 记录 到内存中，所以重启数据库或者对表 OPTIMIZE 操作，都会使大 ID 丢失。 

但是，如果我们使用表的类型是 MyISAM ，那么这条记录的 ID 就是 18 。因为 MyISAM 表会把自增主键的 大 ID 记录到数据文件里面，重启 MYSQL 后，自增主键的大 ID 也不会丢失。

最后，还可以跟面试官装个 x ，生产数据，不建议进行物理删除记录。

8、为什么 SELECT COUNT(*) FROM table 在 InnoDB 比 MyISAM 慢？

对于 SELECT COUNT(*) FROM table 语句，在没有 WHERE 条件的情况下，InnoDB 比 MyISAM 可能会慢很 多，尤其在大表的情况下。因为，InnoDB 是去实时统计结果，会全表扫描；而 MyISAM 内部维持了一个计数器， 预存了结果，所以直接返回即可。