菜单

Juning
发布于 2021-04-09 / 961 阅读
2
0

面试题

一、RabbitMQ如何保证消息不丢失?
1、针对生产者:使用confirm异步回调机制,失败时通过消息ID将Redis里面的消息取出重新发送,成功删除Redis里面的消息
2、针对RabbitMQ:启用消息持久化,设计集群镜像模式、启用消息补偿机制
3、针对消费者:采用ACK确认机制

二、遇到数据库死锁怎么解决?
怎么解决?
1、等待事务超时,主动回滚
2、进行死锁检查,主动回滚某条事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;--查看正在被锁的事务

怎么避免?
1、合理使用锁
2、避免大事务,可以拆分成多个小事务,大事务耗时长,与其它事务发生冲突的概率大
3、多个事务操作相同的一些资源尽量保持顺序一致
4、更新语句尽量只更新必要的字段
预防大于处理

三、使用阿里Canal有没有遇到过什么问题?
有!
1、cannal是通过读取mysql的binlog日志实现将数据同步到elasticsearch中,可是binlog不记录自增ID导致mysql执行新增操作时,同步到elasticsearch中的数据缺少主键ID,用分布式ID解决
2、canal server 和canal client 不在同一个子网就不能访问到canal server,路由转发解决
3、若是存在记录不全,定时器补

四、说说Spring Security OAuth2 生成 token 的执行流程
1、调用 ClientDetailsService 类的 loadClientByClientId 方法, 获取客户端信息装载到 ClientDetails 对象中
2、调用 OAuth2RequestFactory 类生成 TokenRequest 对象
3、调用 TokenGranter, 利用 TokenRequest 产生两个对象 OAuth2Request 和 Authentication
4、将 OAuth2Request 和 Authorization 两个对象组合起来形成一个 OAuth2Authorization 对象
5、将第上一步 的对象会传递到 AuthorizationServerTokenServices 的实现类DefaultTokenServices 中,最终会生成一个OAuth2AccessToken

五、websocket优化问题
1、采用分布式架构
2、消息合并,减小网络小包推送,同一秒内的多条消息合并成1条推送,减小内核压力
3、先编码,后推送
4、用户session采用多个ConcurrentHashMap存储

六、分布式事务的解决
内部:
1、ita+atomic适用传统项目
2、基于MQ补偿解决分布式事务,例如RabbitMQ
3、RocketMQ自带事务消息
4、基于LCN解决,原理:代理我们自己数据源重写方法来实现假关闭,传递消息全局ID
5、基于Seata解决分布式事务问题,原理同LCN。区别:LCN易造成死锁,Seata使用日志逆向生成sql实现回滚
外部:
采用类似支付宝异步回调+主动查询

七、Sharding-JDBC 执行原理
执行流程: SQL 解析 => 查询优化 => SQL路由 => SQL改写 => SQL执行 => 结果归并
这里主要是SQL路由,若条件中携带分片所以用的分片信息则根据分片指定路由,若没有则采用广播的形式

八、高并发解决方案
1、微服务网关和nginx对接口限流、保护、白名单、黑名单
2、redis缓存减轻热数据导致的压力,集群部署,读写分离,提高吞吐量
3、采用MQ异步处理或者多线程提高程序运行速度
4、jvm性能调优和tomcat参数调整提高吞吐量
5、mysql服务器性能优化,读写分离、分表分库提高吞吐量

九、数据库优化
1、开启慢查询定位。
2、sql语法优化避免not null,in,inner join关联三个表等关键字。
3、数据量大避免使用1 = 1。
4、设置索引。
5、使用union代替临时表。
6、避免sql处理逻辑,代码来处理更快。
7、分表分库,字段大使用分表。
8、读写分离。
9、热点数据使用缓存处理

十、并发安全
1、高并发中如何保证脏读数据
答:只有全局变量存在线程安全,多线程共享同一个全局变量会出现线程安全问题
使用Syn(自动)或lock(手动),并发包cas无锁机制保证线程问题
2、Syn(自动)或lock(手动) 区别
3、乐观锁和悲观锁区别
答:乐观锁速度快,不会阻塞,适用于多读的应用类型,这样可以提高吞吐量

十一、ConcurrentHashMap
ConcurrentHashMap是J.U.C(java.util.concurrent包)的重要成员,它是HashMap的一个线程安全的、支持高效并发的版本。在默认理想状态下,ConcurrentHashMap可以支持16个线程执行并发写操作及任意数量线程的读操作。简单的讲就是ConcurrentHashMap默认分为16个桶,通过hash命中个其中一个进行操作
1.7和1.8的区别:
1.8放弃了Segment节点的设计,改为node + cas + synchronized保证安全

十二、ES的倒排索引
每个文档对应一个ID,经过分词,每个关键词记录关键词出现的在文档的评率次数等,倒排索引就是通过匹配关键词来找到对应的文档

正排是在文档中匹配关键词,所以倒排索引速度快

十三、线程池原理
1.提前预热创建线程,保证一直运行
2.执行任务交给队列实现存放(生产者)
3.正在运行线程不断从队列获取任务(消费者)没有任务是堵塞

十四、MySQL索引原理

十五、MySQL索引的类型
1、fulltext:全文索引
2、hash
3、BTREE:B树
4、RTREE:R树

十六、Spring Cloud用了哪些组件
1、Eureka:服务注册于发现。
2、Feign:基于动态代理机制,根据注解和选择的机器,拼接请求 url 地址,发起请求。
3、Ribbon:实现负载均衡,从一个服务的多台机器中选择一台。
4、Hystrix:提供线程池,不同的服务走不同的线程池,实现了不同服务调用的隔离,避免了服务雪崩的问题。
5、getaway:网关管理,由 Zuul 网关转发请求给对应的服务。
6、config


评论