面试常用知识点7 【MyBatis】【RabbitMQ】【Kafka】【Zookeeper】
MyBatis：
Mybatis的主要作用是快速实现对关系型数据库中的数据进行访问的框架。
什么是Mybatis？
- Mybatis是一个ORM（对象关系映射）框架，它内部封装了JDBC，开发时只需要关注SQL语句本 身，不需要花费精力去处理加载驱动、创建连接、创建statement等繁杂的过程。程序员直接编写原生态sql，可以严格控制sql执行性能，灵活度高。
- MyBatis 可以使用 XML 或注解来配置和映射原生信息，将 POJO映射成数据库中的记录，避免了几 乎所有的 JDBC 代码和手动设置参数以及获取结果集。
- 通过xml 文件或注解的方式将要执行的各种 statement 配置起来，并通过java对象和 statement中 sql的动态参数进行映射生成最终执行的sql语句，最后由mybatis框架执行sql并将结果映射为java对象并返回。（从执行sql到返回result的过程）。
Mybatis是如何使用的 (MyBatis 的编程步骤)?
1）根据mybatis的全局配置文件构建对应的SqlSessionFactory；
2）通过SqlSessionFactory创建对应的SqlSession；
3）通过SqlSession进行接下来的与数据库具体的操作动作；
4）调用 session.commit()提交事务;
5）调用 session.close()关闭会话;
6）SqlSession就是和数据库的一次对话，使用完之后需要关闭。
Mybaits的优点：
- 基于SQL语句编程，相当灵活，不会对应用程序或者数据库的现有设计造成任何影响
- SQL写在XML 里，解除sql与程序代码的耦合，便于统一管理
- 提供XML标签，支持编写动态SQL语句，并可重用
- 与JDBC相比，减少了50%以上的代码量，消除了JDBC大量冗余的代码，不需要手动开关连接；
- 很好的与各种数据库兼容（因为MyBatis使用JDBC来连接数据库，所以只要JDBC支持的数据库 MyBatis都支持）。
- 能够与Spring很好的集成；
- 提供映射标签，支持对象与数据库的ORM字段关系映射；
- 提供对象关系映射标签，支持对象关系组件维护。
ORM是什么
ORM（Object Relational Mapping），对象关系映射，是一种为了解决关系型数据库数据与简单Java对 象（POJO）的映射关系的技术。简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系型数据库中。
MyBatis的底层实现原理
Mybatis的底层原理是涉及到动态代理的
分为几个大块：
- 解析Mapper（configuration）
- 动态代理（MapperProxyFactory）
- 封装JDBC（SqlSession）
补充:
什么是动态代理?
- 动态代理就是，在程序运行期，创建目标对象的代理对象，并对目标对象中的方法进行功能性增强的一种技术。在生成代理对象的过程中，目标对象不变，代理对象中的方法是目标对象方法的增强方法。可以理解为运行期间，对象中方法的动态拦截，在拦截方法的前后执行功能操作。
MyBatis 中 #{}和 ${}的区别是什么？
在Mybatis中，配置SQL语句时，参数可以使用#{}或${}格式的占位符。
-
使用
#{}格式的占位符时，Mybatis在处理时会使用预编译的做法，所以，在编写SQL语句时不必关心数据类型的问题（例如字符串值不需要添加单引号），也不存在SQL注入的风险！这种占位符只能用于表示某个值，而不能表示SQL语句片段！ -
当使用
${}格式的占位符时，Mybatis在处理时会先将参数值代入到SQL语句中，然后再执行编译相关过程，所以需要关心某些值的数据类型问题（例如涉及字符串值时，需要在编写SQL语句时添加一对单引号框住字符串），并且，存在SQL注入的风险！其优点是可以表示SQL语句中的任何片段！
在一般情况下，应该尽可能的使用#{}格式的占位符，并不推荐使用${}格式的占位符，即使它可以实现“泛用”的效果！在一些特殊的情况下，如果一定要使用${}格式的占位符，必须考虑SQL注入的风险，应该使用正则表达式或其它做法避免出现SQL注入问题！
补充：
在使用 #{}时，MyBatis 会将 SQL 中的 #{}替换成“?”，配合 PreparedStatement 的 set 方法赋值，这样可以有效的防止 SQL 注入，保证程序的运行安全。
在 mybatis 中,ResultType 和 ResultMap 的区别是什么?
- 如果数据库结果集中的列名和要封装实体的属性名完全一致的话用 resultType 属性
- 如果数据库结果集中的列名和要封装实体的属性名有不一致的情况用 resultMap 属性，通过 resultMap 手动建立对象关系映射，resultMap 要配置一下表和类的一一对应关系，所以说就算你的字段名和你的实体类的属性名不一样也没关系，都会给你映射出来
Mybatis 动态 sql 是做什么的？都有哪些动态 sql？简述一下动态 sql 的执行原理？
- Mybatis 动态 sql 可以让我们在 Xml 映射文件内，以标签的形式编写动态 sql，完成逻辑判断和动态拼接 sql 的功能。
- Mybatis 提供了 9 种动态 sql 标签：
- trim
- choose
- when
- otherwise
- bind。
- 其执行原理为，使用 OGNL 从 sql 参数对象中计算表达式的值，根据表达式的值动态拼
接 sql，以此来完成动态 sql 的功能。
MyBatis 有几种分页方式？
分页方式：逻辑分页和物理分页。
- 逻辑分页： 使用 MyBatis 自带的 RowBounds 进行分页，它是一次性查询很多数据，然后在数据中再进行检索。
- 物理分页：自己手写 SQL 分页或使用分页插件 PageHelper，去数据库查询指定条数的分页数据的形式。
RowBounds 是一次性查询全部结果吗？为什么？
RowBounds 表面是在“所有”数据中检索数据，其实并非是一次性查询出所有数据，因为 MyBatis 是对 jdbc 的封装，在 jdbc 驱动中有一个 Fetch Size 的配置，它规定了每次最多从数据库查询多少条数据，假如你要查询更多数据，它会在你执行 next()的时候，去查询更多的数据。就好比你去自动取款机取 10000 元，但取款机每次最多能取 2500 元，所以你要取 4 次才能把钱取完。只是对于 jdbc 来说，当你调用 next()的时候会自动帮你完成查询工作。这样做的好处可以有效的防止内存溢出。
MyBatis 逻辑分页和物理分页的区别是什么？
- 逻辑分页是一次性查询很多数据，然后再在结果中检索分页的数据。这样做弊端是需要消耗大量的内存、有内存溢出的风险、对数据库压力较大。
- 物理分页是从数据库查询指定条数的数据，弥补了一次性全部查出的所有数据的种种缺点，比如需要大量的内存，对数据库查询压力较大等问题。
MyBatis 是否支持延迟加载？延迟加载的原理是什么？
MyBatis 支持延迟加载，设置 lazyLoadingEnabled=true 即可。
延迟加载的原理的是调用的时候触发加载，而不是在初始化的时候就加载信息。
比如调用 a. getB(). getName()，这个时候发现 a. getB() 的值为 null，此时会单独触发事先保存好的关联 B 对象的 SQL，先查询出来 B，然后再调用 a. setB(b)，而这时候再调用 a. getB(). getName() 就有值了，这就是延迟加载的基本原理。
说一下 MyBatis 的一级缓存和二级缓存？
Mybatis有2种缓存机制，分别称之一级缓存和二级缓存。
两者均是基于 PerpetualCache 的 HashMap 本地缓存。
一级缓存：
- 一级缓存是基于
SqlSession的缓存，也称之为“会话缓存”，仅当是同一个会话、同一个Mapper、同一个抽象方法（同一个SQL语句）、同样的参数值时有效 - 一级缓存在集成框架的应用中默认是开启的，且整个过程不由人为控制（如果是自行得到
SqlSession后的操作，可自行清理一级缓存）。 - 当 Session flush 或 close 之后，该 Session 中的所有 Cache 就将清空。
二级缓存：
- 存储作用域为 Mapper 级别的
- 默认不打开二级缓存，如果多个SQLSession之间需要共享缓存，则需要使用到二级缓存，并且二级缓存可自定义存储源，如 Ehcache。
- 二级缓存默认是全局开启的，它是基于namespace的，所以也称之为“namespace缓存”，需要在配置SQL语句的XML中添加
节点上配置useCache="true"，则对应的节点的查询结果将被二级缓存处理，并且，此查询返回的结果的类型必须是实现了Serializable接口的，如果使用了 - 开启二级缓存数据查询流程：二级缓存 -> 一级缓存 -> 数据库。
由于Mybatis的缓存清理机制过于死板，所以，一般在开发实践中并不怎么使用！更多的是使用其它的缓存工具并自行制定缓存策略。
补充：
- 缓存：通常是一个临时存储的数据，在未来的某个时间点可能会被删除，通常，存储缓存数据的位置通常是读写效率较高的，相比其它“非缓存”的数据有更高的处理效率。由于缓存的数据通常并不是必须的，则需要额外消耗一定的存储空间，同时由于从缓存获取数据的效率更高，所以是一种牺牲空间、换取时间的做法！另外，你必须知道，从数据库读取数据的效率是非常低下的！
- 缓存更新机制：当某一个作用域(一级缓存 Session/二级缓存 Mapper)进行了C/U/D 操作后，默认该作用域下所有 select 中的缓存将被 clear。换言之，无论是一级缓存还是二级缓存，只要数据发生了写操作（增、删、改），缓存数据都将被自动清理。
MyBatis 和 hibernate 的区别有哪些？
- 灵活性：MyBatis 更加灵活，自己可以写 SQL 语句，使用起来比较方便。
- 可移植性：MyBatis 有很多自己写的SQL，因为每个数据库的 SQL 可以不相同，所以可移植性比较差。
- 学习和使用门槛：MyBatis 入门比较简单，使用门槛也更低。
- 二级缓存：hibernate 拥有更好的二级缓存，它的二级缓存可以自行更换为第三方的二级缓存。
MyBatis 有哪些执行器（Executor）？
MyBatis 有三种基本的Executor执行器：
- SimpleExecutor：每执行一次 update 或 select 就开启一个 Statement 对象，用完立刻关闭Statement 对象；
- ReuseExecutor：执行 update 或 select，以 SQL 作为 key 查找Statement 对象，存在就使用，不存在就创建，用完后不关闭 Statement 对象，而是放置于 Map内供下一次使用。简言之，就是重复使用 Statement 对象；
- BatchExecutor：执行 update（没有select，jdbc 批处理不支持 select），将所有 SQL都添加到批处理中（addBatch()），等待统一执行（executeBatch()），它缓存了多个 Statement 对象，每个Statement 对象都是 addBatch()完毕后，等待逐一执行 executeBatch()批处理，与 jdbc 批处理相同。
MyBatis 分页插件的实现原理是什么？
分页插件的基本原理是使用 MyBatis 提供的插件接口，实现自定义插件。在插件的拦截方法内拦截待执行的 SQL，然后重写 SQL，根据 dialect 方言，添加对应的物理分页语句和物理分页参数。
MyBatis 如何编写一个自定义插件？
自定义插件实现原理：
MyBatis 自定义插件针对 MyBatis 四大对象（Executor、StatementHandler、ParameterHandler、ResultSetHandler）进行拦截：
- Executor：拦截内部执行器，它负责调用 StatementHandler 操作数据库，并把结果集通过 ResultSetHandler 进行自动映射，另外它还处理了二级缓存的操作；
- StatementHandler：拦截 SQL 语法构建的处理，它是 MyBatis 直接和数据库执行 SQL 脚本的对象，另外它也实现了 MyBatis 的一级缓存；
- ParameterHandler：拦截参数的处理；
- ResultSetHandler：拦截结果集的处理。
自定义插件实现关键：
MyBatis 插件要实现 Interceptor 接口，接口包含的方法，如下：
public interface Interceptor {
Object intercept(Invocation invocation) throws Throwable;
Object plugin(Object target);
void setProperties(Properties properties);
}
- setProperties 方法是在 MyBatis 进行配置插件的时候可以配置自定义相关属性，即：接口实现对象的参数配置；
- plugin 方法是插件用于封装目标对象的，通过该方法我们可以返回目标对象本身，也可以返回一个它的代理，可以决定是否要进行拦截进而决定要返回一个什么样的目标对象，官方提供了示例：return Plugin. wrap(target, this)；
- intercept 方法就是要进行拦截的时候要执行的方法。
RabbitMQ
什么是消息队列
消息（Message）是指在应用之间传送的数据，消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。
消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，有消息系统来确保信息的可靠专递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。
何时使用消息队列
消息队列是一种应用间的异步协作机制，那什么时候需要使用MQ呢？
以常见的订单系统为例子，用户点击【下单】按钮后的业务逻辑包括：扣减库存、生成相应的单据、发红包、发短信通知‘在业务发展初期这些逻辑可能放在一起同步执行，随着业务订单量增长，需要提升系统服务的性能，这时候可以将一些不需要立即生效的操作拆分出来异步执行，，比如发红包、发短信通知等。这种场景就可以用MQ，在下单的主流程（比如扣减库存、生成相应的单据）完成之后发送一条消息到MQ让主流程快速完结，而由另外的单独线程拉取MQ的消息（或者由MQ推送消息），当发现MQ中有发红包或者发短信之类的消息，执行相应的业务逻辑。
以上是用于业务解耦的情况，其他常见场景包括最终一致性、广播、错峰流控等等。
什么是RabbitMQ
RabbitMQ是一个由Erlang语言开发的AMQP的开源实现。
AMQP：Advanced Meassage Queue，高级消息队列协议。它是应用层协议的一个开放标准，为面向消息的中间设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件限制。
RabbitMQ最初起源于金融系统，用于分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗
具体特点：
1、可靠性（Reliablitity）
RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。
2、灵活的路由（Flexible Routing）
在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。
3、消息集群（Clustering）
多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。
4、高可用（Highly Available Queues）
队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。
5、多种协议（Multi-protocol）
RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等等。
6、多语言客户端（Many Clients）
RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。
7、管理界面（Management UI）
RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。
8、跟踪机制（Tracing）
如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。
9、插件机制（Plugin System）
RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。
RabbitMQ 的使用场景有哪些？
- 抢购活动，削峰填谷，防止系统崩塌。
- 延迟信息处理，比如 10 分钟之后给下单未付款的用户发送邮件提醒。
- 解耦系统，对于新增的功能可以单独写模块扩展，比如用户确认评价之后，新增了给用户返积分的功能，这个时候不用在业务代码里添加新增积分的功能，只需要把新增积分的接口订阅确认评价的消息队列即可，后面再添加任何功能只需要订阅对应的消息队列即可。
RabbitMQ 有哪些重要的角色？
RabbitMQ 中重要的角色有：生产者、消费者和代理。
- 生产者：消息的创建者，负责创建和推送数据到消息服务器；
- 消费者：消息的接收方，用于处理数据和确认消息；
- 代理：就是 RabbitMQ 本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。
RabbitMQ 有哪些重要的组件？
- ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用。
- Channel（信道）：消息推送使用的通道。
- Exchange（交换器）：用于接受、分配消息。
- Queue（队列）：用于存储生产者的消息。
- RoutingKey（路由键）：用于把生成者的数据分配到交换器上。
- BindingKey（绑定键）：用于把交换器的消息绑定到队列上。
RabbitMQ 中 vhost 的作用是什么？
vhost：每个 RabbitMQ 都能创建很多 vhost，我们称之为虚拟主机。每个虚拟主机其实都是 mini 版的RabbitMQ，它拥有自己的队列，交换器和绑定，拥有自己的权限机制。
RabbitMQ 的消息是怎么发送的？
- 首先客户端必须连接到 RabbitMQ 服务器才能发布和消费消息
- 客户端和 rabbit server 之间会创建一个 tcp 连接
- 一旦 tcp 打开并通过了认证（认证就是你发送给 rabbit 服务器的用户名和密码），你的客户端和 RabbitMQ 就创建了一条 amqp 信道（channel）
- 信道是创建在“真实” tcp 上的虚拟连接，amqp 命令都是通过信道发送出去的，每个信道都会有一个唯一的 id，不论是发布消息，订阅队列都是通过这个信道完成的。
RabbitMQ 怎么保证消息的稳定性？
- 提供了事务的功能。
- 通过将 channel 设置为 confirm（确认）模式。
RabbitMQ 怎么避免消息丢失？
- 把消息持久化磁盘，保证服务器重启消息不丢失。
- 每个集群中至少有一个物理磁盘，保证消息落入磁盘。
要保证消息持久化成功的条件有哪些？
- 声明队列必须设置持久化 durable 设置为 true.
- 消息推送投递模式必须设置持久化，deliveryMode 设置为 2（持久）。
- 消息已经到达持久化交换器。
- 消息已经到达持久化队列。
以上四个条件都满足才能保证消息持久化成功。
RabbitMQ 持久化有什么缺点？
持久化的缺点就是降低了服务器的吞吐量，因为使用的是磁盘而非内存存储，从而降低了吞吐量。
可尽量使用 ssd 硬盘来缓解吞吐量的问题。
RabbitMQ 有几种广播类型？
- direct（默认方式）：最基础最简单的模式，发送方把消息发送给订阅方，如果有多个订阅者，默认采取轮询的方式进行消息发送。
- headers：与 direct 类似，只是性能很差，此类型几乎用不到。
- fanout：分发模式，把消费分发给所有订阅者。
- topic：匹配订阅模式，使用正则匹配到消息队列，能匹配到的都能接收到。
RabbitMQ 怎么实现延迟消息队列？
延迟队列的实现有两种方式：
- 通过消息过期后进入死信交换器，再由交换器转发到延迟消费队列，实现延迟功能；
- 使用 RabbitMQ-delayed-message-exchange 插件实现延迟功能。
RabbitMQ 集群有什么用？
集群主要有以下两个用途：
- 高可用：某个服务器出现问题，整个 RabbitMQ 还可以继续使用；
- 高容量：集群可以承载更多的消息量。
RabbitMQ 节点的类型有哪些？
- 磁盘节点：消息会存储到磁盘。
- 内存节点：消息都存储在内存中，重启服务器消息丢失，性能高于磁盘类型。
RabbitMQ 集群搭建需要注意哪些问题？
- 各节点之间使用“–link”连接，此属性不能忽略。
- 各节点使用的 erlang cookie 值必须相同，此值相当于“秘钥”的功能，用于各节点的认证。
- 整个集群中必须包含一个磁盘节点。
RabbitMQ 每个节点是其他节点的完整拷贝吗？为什么？
不是，原因有以下两个：
- 存储空间的考虑：如果每个节点都拥有所有队列的完全拷贝，这样新增节点不但没有新增存储空间，反而增加了更多的冗余数据；
- 性能的考虑：如果每条消息都需要完整拷贝到每一个集群节点，那新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。
RabbitMQ 集群中唯一一个磁盘节点崩溃了会发生什么情况？
如果唯一磁盘的磁盘节点崩溃了，不能进行以下操作：
- 不能创建队列
- 不能创建交换器
- 不能创建绑定
- 不能添加用户
- 不能更改权限
- 不能添加和删除集群节点
唯一磁盘节点崩溃了，集群是可以保持运行的，但你不能更改任何东西。
RabbitMQ 对集群节点停止顺序有要求吗？
RabbitMQ 对集群的停止的顺序是有要求的，应该先关闭内存节点，最后再关闭磁盘节点。
如果顺序恰好相反的话，可能会造成消息的丢失。
Kafka
kafka 可以脱离 zookeeper 单独使用吗？为什么？
kafka 不能脱离 zookeeper 单独使用，因为 kafka 使用 zookeeper 管理和协调 kafka 的节点服务器。
kafka 有几种数据保留的策略？
kafka 有两种数据保存策略：按照过期时间保留和按照存储的消息大小保留。
kafka 同时设置了 7 天和 10G 清除数据，到第五天的时候消息达到了 10G，这个时候 kafka 将如何处理？
这个时候 kafka 会执行数据清除工作，时间和大小不论那个满足条件，都会清空数据。
什么情况会导致 kafka 运行变慢？
- cpu 性能瓶颈
- 磁盘读写瓶颈
- 网络瓶颈
使用 kafka 集群需要注意什么？
- 集群的数量不是越多越好，最好不要超过 7 个，因为节点越多，消息复制需要的时间就越长，整个群组的吞吐量就越低。
- 集群数量最好是单数，因为超过一半故障集群就不能用了，设置为单数容错率更高。
Zookeeper
zookeeper 是什么？
- zookeeper 是一个分布式的，开放源码的分布式应用程序协调服务
- 是 google chubby 的开源实现
- 是 hadoop 和 hbase 的重要组件
- 它是一个为分布式应用提供一致性服务的软件
- 提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
zookeeper 都有哪些功能？
- 集群管理：监控节点存活状态、运行请求等。
- 主节点选举：主节点挂掉了之后可以从备用的节点开始新一轮选主，主节点选举说的就是这个选举的过程，使用 zookeeper 可以协助完成这个过程。
- 分布式锁：zookeeper 提供两种锁：
- 独占锁,即一次只能有一个线程使用资源
- 共享锁是读锁共享，读写互斥，即可以有多线线程同时读同一个资源，如果要使用写锁也只能有一个线程使用。zookeeper可以对分布式锁进行控制。
- 命名服务：在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。
zookeeper 有几种部署模式？
zookeeper 有三种部署模式：
- 单机部署：一台集群上运行；
- 集群部署：多台集群运行；
- 伪集群部署：一台集群启动多个 zookeeper 实例运行。
zookeeper 怎么保证主从节点的状态同步？
- zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。
- 实现这个机制的协议叫做 zab 协议。
- zab 协议有两种模式，分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，zab 就进入了恢复模式，当领导者被选举出来，且大多数 server 完成了和 leader 的状态同步以后，恢复模式就结束了。
- 状态同步保证了 leader 和 server 具有相同的系统状态。
集群中为什么要有主节点？
在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，所以就需要主节点。
集群中有 3 台服务器，其中一个节点宕机，这个时候 zookeeper 还可以使用吗？
可以继续使用，单数服务器只要没超过一半的服务器宕机就可以继续使用。
说一下 zookeeper 的通知机制？
客户端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些客户端会收到 zookeeper 的通知，然后客户端可以根据 znode 变化来做出业务上的改变。