第一次面试
技术给业务赋能
1、分布式事务六种解决方案?
https://www.cnblogs.com/mayundalao/p/11798502.html
一、两阶段提交(2PC)
二、补偿事务(TCC)
TCC 其实就是采用的补偿机制,其核心思想是:针对每个操作,都要注册一个与其对应的确认和补偿(撤销)操作。它分为三个阶段:
-
Try 阶段主要是对业务系统做检测及资源预留
-
Confirm 阶段主要是对业务系统做确认提交,Try阶段执行成功并开始执行 Confirm阶段时,默认 Confirm阶段是不会出错的。即:只要Try成功,Confirm一定成功。
-
Cancel 阶段主要是在业务执行错误,需要回滚的状态下执行的业务取消,预留资源释放。
三、本地消息表(异步确保)
本地消息表与业务数据表处于同一个数据库中,这样就能利用本地事务来保证在对这两个表的操作满足事务特性,并且使用了消息队列来保证最终一致性。
四、MQ 事务消息
2、分布式锁实现?
基于数据库实现分布式锁;
基于缓存(Redis等)实现分布式锁;
try{
lock = redisTemplate.opsForValue().setIfAbsent(lockKey, LOCK);
logger.info("cancelCouponCode是否获取到锁:"+lock);
if (lock) {
// TODO
redisTemplate.expire(lockKey,1, TimeUnit.MINUTES); //成功设置过期时间
return res;
}else {
logger.info("cancelCouponCode没有获取到锁,不执行任务!");
}
}finally{
if(lock){
redisTemplate.delete(lockKey);
logger.info("cancelCouponCode任务结束,释放锁!");
}else{
logger.info("cancelCouponCode没有获取到锁,无需释放锁!");
}
}
基于Zookeeper实现分布式锁;
3、两个文件100G文件A、B,内存只有5G,如何从A、B两个文件中找出相同的链接。
两个文件分成20份,将每次读取的数据放入hashMap,通过hashmap中的数据量取得相同数据。
4、线程池的4种实现方式? 7个关键字?4种拒绝策略?
https://blog.csdn.net/u012248896/article/details/109502044
// 创建单个线程
Executors.newSingleThreadExecutor();
// 创建固定数量的线程
Executors.newFixedThreadPool(3);
// 可动态调整,随着请求的增多线程也随之创建
Executors.newCachedThreadPool();
// 用来调度即将执行的任务的线程池
Executors.newScheduledThreadPool();
阿里的Java开发手册中强制规定不允许使用Executors方式来创建,而建议使用ThreadPoolExecutor的方式
corePoolSize 核心线程数,一直存活,即使线程数小于核心线程数且线程数有空闲,线程池也会创建新的线程。
maximumPoolSize 最大线程数,当线程数大于核心线程数并且任务队列已经满了的时候,线程池会创建新的线程,当线程数大于最大线程数并且任务队列已经满了,会抛出异常。
keepAliveTime 线程空闲时间,当线程的空闲时间达到keepAliveTime时,线程会退出,直到线程数等于核心线程数,可以设置参数allowCoreThreadTimeout=true,则会直到线程数为0。
TimeUnit unit 超时时间单位。
BlockingQueue workQueue 阻塞队列,任务队列的容量。
ThreadFactory threadFactory 线程工厂,基本不用设置(默认使用Executors.defaultThreadFactory())
RejectedExecutionHandler handler 拒绝策略,任务拒绝处理器。
四种策略分为是:
AbortPolicy() 线程池满了,如果还有线程想加入,不处理这个请求,抛出异常。
CallerRunsPolicy() 哪来的回哪去,不执行
DiscardPolicy() 队列满了,丢掉任务,不会抛出异常。
DiscardOldestPolicy() 队列满了,尝试去和最早的竞争,不会抛出异常。
redis发布订阅、主从复制、哨兵模式?
https://www.cnblogs.com/itzhouq/p/redis5.html
CAP和BASE?(分布式需要保证)
BASE 是基本可用(Basically Available)、软状态(Soft State)和最终一致性(Eventually Consistent)三个短语的缩写。
BASE 理论是对 CAP 中一致性和可用性权衡的结果,它的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。
基本可用
从99.9% 和99.99%,经济性去考虑。
指分布式系统在出现故障的时候,保证核心可用,允许损失部分可用性。
例如,电商在做促销时,为了保证购物系统的稳定性,部分消费者可能会被引导到一个降级的页面。
软状态
指允许系统中的数据存在中间状态,并认为该中间状态不会影响系统整体可用性,即允许系统不同节点的数据副本之间进行同步的过程存在时延。
最终一致性
最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能达到一致的状态。
ACID 要求强一致性,通常运用在传统的数据库系统上。而 BASE 要求最终一致性,通过牺牲强一致性来达到可用性,通常运用在大型分布式系统中。
在实际的分布式场景中,不同业务单元和组件对一致性的要求是不同的,因此 ACID 和 BASE 往往会结合在一起使用。
N次面试后问的问题
首先,简单介绍下项目,然后问了dubbo调用方式,redis 锁,数据拷贝,多线程相关的,有没有了解一些热门的技术,怎么去学习技术,大数据量如何保证架构正常。