封神之路

/** * 全局捕获异常 */ @ControllerAdvice(basePackages = "com.xx.api.impl") public class GlobalExceptionHandler { @ExceptionHandler(RuntimeException.class) @ResponseBody public Map<String, Object> errorResult() { Map<String, Object> e

1.什么是羊群效应？ 当jvm释放锁的时候，会唤醒正在等待的jvm 从新进入到获取锁的状态。 如果正在阻塞的等待获取锁的jvm，如果有几十个或者几百个、上千个的情况下 ZkServer端唤醒所有正在等待的jvm，从新进入到获取锁的状态，唤醒的成本是非常高 有可能会造成我们ZkServer端阻塞。 2.业务超时，一直不释放锁如何处理？ 1.可以采用续命设计 业务如果超时（），续命多次（3次）如果还是没有释放锁的情况下，则认为超时。 2.续命多次依旧超时应该 主动释放锁； 事务回滚； 主动停止阻塞的线程； 移

1.传统任务调度存在的缺陷 业务逻辑与定时任务逻辑放入在同一个Jar包中，如果定时任务逻辑挂了也会影响到业务逻辑； 如果服务器集群的情况下，可能存在定时任务逻辑会重复触发执行； 定时任务执行非常消耗cpu的资源，可能会影响到业务线程的执行 2.如何在集群中，保证我们的定时任务只会触发一次 将业务逻辑和定时任务逻辑完全分开部署，实现解耦、只对业务逻辑实现集群，不对我们的定时任务逻辑集群；—定时任务单机部署版本 问题：如果宕机，如何保证高可用？ 对我们Jar包加上一个开关，项目启动的时候读取该

一.分布式锁有那些应用场景 1. 集群环境中保证定时任务执行的幂等性问题 基于zk案例 幂等性：执行结果保证唯一不能够重复。 当我们定时任务服务集群的情况下，有可能会同时重复执行定时任务。 解决思路： 多个jvm集群的定时任务 在触发的时候，获取分布式锁 如果能够获取到分布式锁的jvm，就能够执行定时任务，没有获取到 分布式锁的jvm就不能够执行定时任务。 2. 用户下单库存超卖的问题，防止超卖 Redis解决 二、Synchronized锁与分布式锁区别 Synchronized锁适合于单个jvm中

同一个项目 一个jar包 单个数据源 发生异常，下单、派单 都会回滚。 多个数据源 注意： 发生异常 只会回滚 下单操作，派单操作是单独的事物管理器，不会回滚 分布式事务产生的背景 在单体的项目中，多个不同业务逻辑都是在同一个数据源中实现事务管理，是不存在分布式事务的问题，因为同一数据源的情况下都是采用事务管理器，相当于每个事务管理器对应一个数据源 在单体的项目中，有多个不同的数据源，每个数据源中都有自己独立的事务管理器，互不影响，那么这时候也会存在多数据源事务管理：解决方案jta+ Atomikos

1.RPC接口http请求 客户端向服务器端发送http请求，http请求基于请求与响应的，如果服务器端没有及时的响应请求给客户端的情况下，有可能会造成客户端会一直阻塞等待。 客户端调用服务器端接口的时候，会设置一个超时时间5s-10s 30s 如果服务器端处理客户端业务逻辑非常耗时的情况下，应该改成mq异步执行。 2.接口超时与接口调用不通区别？ 接口响应超时：服务器端实际上已经接受到客户端请求，服务器端没有及时响应请求给客户端 java.net.SocketTimeoutException: Read