一谈谈对Seata的理解
分布式事务本质上要解决的就是跨网络节点的多个事务的数据一致性问题,业界内常见的解决方法有两种:
1、强一致性:
事务时刻保持一致,节点数据一致,所有的事务参与者要么全部成功,要不全部失败。
对于强一致性,可以通过基于XA协议下的二阶段提交实现
2、最终一致性:
多个网络节点的数据容许出现不一致的情况,但是在最终的某个时间点会达成数据一致性
可以通过TCC的事务模型,可靠性消费模型等方案来实现
分布式事务的解决情况:Seata
四种事务模式,AT模式、TCC模式、Sega模式、XA模式
AT模式基于本地事务和二阶段实现的事务
TCC模式,拆分三个阶段,XA事务强一致性事务
二如何在2G大小的文件找出高频top100的单词
大文件拆分成小文件,分治,堆的思想来解决
多线程并行执行,执行的效率提高
哈希取模,定义一个长度为2048的hash表数组,为了保证同一个单词放在一个里面
然后进行小顶堆的思想,进行建堆,取出top100的单词
三内存泄漏排查与解决思路
内存泄漏的产生原因:不需要对象无法回收
直接表现为:oom,频繁发生fullgc
排查与解决方案:
定位是否是内存泄漏,老年代逐步增长,FullGC卡顿
jstat命令分析
把内存dump下来,使用MAT工具然后进行分析
四生产环境变慢,如何处理
cpu过高,服务器的指令比较多,反应比较慢
jstat打印出当前线程的快照,查看日志判断具体
磁盘的IO效率,JVM的内存管理
五MyBatis配置中的#{},${}的区别
动态sql解决方式,参数传递到xml里面,防止sql注入,
最大的区别,前者是动态参数,后者的占位符,
六为啥map可以存null
二义性,并发场景避免出现存null
七消息队列的消息获取,推和拉的模式有何区别
推的模式:消费者和消息队列之间建立长连接,或者注册一个回调,当服务端数据发生变化的时候,通过建立好的长连接将数据推送到客户端,实时性高,大量堆积消费者,压力太大有可能会造成服务压力太大
拉的模式:消费者不断轮询的方式去检查数据是否发生了变化,如果有变化的话就把数据给拉回来,消费者掌控消息的数量和速度,可以避免消息在消费者的一端发生堆积,缺点是;不断轮询对消息中间件造成压力
八sql响应慢
热点数据-走索引进行判断
九kafka如何保证顺序消费
消费者的数量<partion的数量,简单计划