面试问题_面试 [30]

文章目录

1.谈谈项目中mq的理解

mq一般都是用来异步, 解耦, 消峰用的。

异步操作, 接口是http协议的,在同步调用过程中, 如果接口响应比较慢的情况下, 会导致客户端反应超时, 比如有些业务的接口, 确实执行比较耗时, 那响应时间比较慢
的情况下, 会导致我们的客户端会同步进行阻塞等待, 这种情况下回引发客户端超时, 会使得客户端触发一些重试策略, 在重试策略的过程中, 会导致业务发生重复执行。
所以我们需要去注意一些幂等性问题。我们会把执行耗时的接口使用mq异步实现, 可以提高http协议接口的响应速度, 比如说异步发优惠券, 异步扣库存, 异步发短信。

幂等性问题:

1.基于token
2,锁机制:悲观锁,乐观锁:基于version,分布式锁
3.基于防重表
4.基于数据库唯一Id,redis set防重
5.基于全局请求唯一id

2.mq宕机消息会丢失吗

主流的mq在默认的时间段会将msg持久化到硬盘上, 宕机恢复后, 也会从硬盘恢复过来, 读到内存中

3.消息堆积问题

高并发的情况下很常见, 生产者的生产消息的速率和消费者消费的速率不匹配, 将consumer作为集群形式消费, 每个消费者为批量形式消费, 可以不断横向扩展, 对于consumer不断做集群。进行批量消费。

4.mq的集群如何解决消息顺序执行问题

一般这个问题不用去解决,但是有的场景需要解决,比如Mysql和redis数据同步的过程中, mq进行异步同步.消息的执行顺序需要解决: producer可以设置一个消息key, 相同的业务逻辑设置相同的key, 做hash算法的时候, 会存放在相同的Broker分区中, consumer会在同一个broker中消费。效率会变低, 需要进行broker横向扩展, 提高效率。

5.数据一致性问题

1.先更新缓存后更新数据库
问题:
1.更新缓存后,读取缓存
2.读取数据库的时候失败了
不可取

2.先更新数据库后更新缓存
问题:
1.数据一致性问题
2.数据更新存在时间差
3.业务方面,如果读取数据库的时候更新缓存,不停的更新缓存浪费资源
不可取

3.先删除缓存后更新数据库
问题:
1.数据不一致问题
A删缓存 B读取数据直接读取数据库旧值 B将值写入到缓存 A将值写入到数据库
解决方案：
1.延迟双删,延迟B的删除的时间大于A的写入缓存时间
不可取

4.先更新数据库后删除缓存
有问题,待解决,利用canal和mq

最终一致性是思想:双写, 延迟双删:删两次, 时间点不好控制。

6.canal运行原理

首先启动一个canal的服务器端, 订阅到mysql的master的binlog文件, 当mysql的master的binlog文件发生变化的时候, 会将binlog文件同步到canal的服务器端, 再同步到canal的客户端, cannal客户端将数据同步到redis中, 告诉数据的变化。这个过程一般都是有redis延迟的。

redis的延迟是30s左右。

7.分布式配置中心的原理

客户端会做一个心跳, 每隔一段时间去服务端请求配置文件有无发送变化, MD5的方式进行比对, 如果有发生变化的话, 服务器端的配置文件刷新到本地, 不会立刻生效,因为需要将bean对象重新再ioc容器上加载。所以会有一个客户端在类上有一个注册,就是刷新注解, 然后IOC容器会遍历bean对象,如果类上有加刷新注解的话, 会重新在IOC容器加载, 重新讲配置文件的值给Bean对象的成员属性。

8.谈谈对seata的理解

1.在微服务架构中, 由于数据库和应用服务的拆分, 导致原本一个事务单元中的DML操作变成了垮进程或者垮数据库的多个事务单元的多个DML操作, 而传统的数据库事务是无法
解决这类问题的, 所以引出了分布式事务。
2.分布式事务解决的问题是垮网络的事务的数据一致性问题, 这个数据一致性问题分为强一致性, 和弱一致性, 强一致性是全局事务的状态必须一致, 弱一致性是多个网络节点
的数据允许出现数据不一致, 但是最终必须达到数据一致性, CAP定理知道, 强一致性对于系统性能有一定的影响, 所以对于数据一致性要求不高的场景, 会采用最终一致性算法。
3.在分布式事务中, 我们可以通过XA 协议下的二阶段提交去实现强一致性, 对于弱一致性, 我们可以通过TCC 事务模型以及可靠性消息模型等方案去实现。
4.市面上很多对于这些理论实现的分布式事务的框架, 可以通过集成这些框架去实现分布式事务, seata就是一种, 它是阿里开源的分布式事务解决方案, 提供了高性能的且
简单易用的分布式事务服务, seata中封装了4种分布式事务模型, 分别是
1).AT 模式: 基本本地事务+二阶段事务协议实现的最终数据一致性方案, 是默认的模式
2).tcc模型: try, confirm, cancel：将事务的模型拆分为3个阶段, 通过事务管理器在业务逻辑层面根据每一个分支事务的执行情况, 去分别调用业务的Confirm或者cancel方法
3).saga模式: seata中提供长事务解决方案, 在saga模型中, 业务参与者都要提交本地事务, 当出现任何一个参与者提交失败的时候, 提供补偿的方案把之前成功的事务参与者进行回滚。
4).XA 模型: 强一致性解决方案, 利用数据库, 消息服务对于XA 协议的支持, 以XA协议的方式管理分布式事务的一种事务模型。
不同的业务中, 利用seata的不同模型解决不同业务的场景的不同分布式事务问题。
seata是一个一站式分布式事务解决方案。

9.fail-safe/fail-fast机制分别有什么作用?

是多线程并发处理集合的失败处理机制, fast表示快速失败, 在集合的变量过程中, 如果发现有数据被修改的话, 会抛出异常
:ConcurrentModificationException, 导致遍历是失败的。ArrayList, HashMap等, safe: 不会抛出异常, 先复制原有集合的内容, 拷贝的集合上进行遍历, 由于迭代器是对原始集合的遍历, 所以变量过程中, 对于原始集合的修改, 不会被迭代器检测到, 由于迭代是对原始集合的拷贝进行遍历的, 所以变量过程中, 对于原始集合的修改不会被迭代器检测到。CopyOnWriteArrayList, CocurrentHashMap

10.Cpu 如果太高如何解决

Cpu是整个电脑是核心计算资源, 对于一个应用来说, Cpu对应的是线程

1.Cpu的上下文切换过多, 首先Cpu只可以运行一个线程, 如果多个线程执行的话, 需要通过上下文切换的方式, 去执行调度不同的线程。上下文切换可以使得线程得到资源, 这个过程需要Cpu执行内核相关指令, 去实现状态的保存和恢复, 如果较多的上下文切换, 会占据大量的Cpu资源, java中文件IO, 网络IO, 锁等待都会造成线程阻塞, 线程阻塞会导致上下文切换。

2.Cpu资源过度消耗, 代码层面是有一部分代码过多的占用资源, 比如死循环, Cpu利用资源过多, 导致应用层的线程无法去获得Cou的调度。可以通过top命令找到Cpu利用率过高的进程, 再通过shuift+h找到进程中占用过多的线程, 如果线程是同一个的话, 就是id一直不变的话, 可以通过jstack获得线程的dump日志, 定位到线程的日志, 找到代码。如果线程不是同一个的话, 说明线程创建过多, 需要挑选几个线程ID, 通过jstack, 获取dump日志, 进行排查。

3.有可能是正常情况下, 但是由于那一时刻用户量过多导致Cpu飙高, 可以通过增加系统资源。