在使用分布式锁的时候,习惯性的尽量缩小同步代码块的范围但是如果数据库隔离级别是可重复读，这种情况下不要把分布式锁加在注解的事务方法内部。线程1开启事务A后获取分布式锁,执行业务代码后在事务内释放了分布式锁。这时候线程1开启了事务B获取到了线程1释放的分布式锁，执行查询操作时查到的数据就可能出现问题。因为此时事务A是在事务内释放了锁，事务A本身还没有完成提交。

1）Nacos里的服务要提前下线 2）K8s探针要合理配置，不然就会出现还没完全关，Pod已经被砍了 3）业务线程池、连接池、消息队列等资源得主动回收 4）一些长连接（WebSocket、Grpc、TCP）要主动关闭 5）如果有MQ消费者，还要搞定幂等性 + 消息回补机制。SpringBoot + Nacos + K8s 想做到“真·优雅停机”，不能只靠“系统自动”，而是要你作为开发者主动插手，去

数据库发展至今已经有3代了：SQL，传统关系型数据库，例如 MySQLnoSQL，例如 MongoDB,RedisnewSQL。

（3）@EnableConfigutarion:最关键的一个注解，他拥有两个子注解，其中@AutoConfigurationpackageu会将启动类所在包下的所有组件到容器中，@Import会导入一个自动配置文件选择器，他会去加载META_INF目录下的spring.factories文件，这个文件中存放很大自动配置类的全类名，这些类会根据元注解的装配条件生效，生效的类就会被实例化，加载到ioc

Nginx特点正向代理与反向代理负载均衡动静分离Nginx的优势可操作性大网络依赖小安装简单支持健康检查以及请求重发LVS 的优势抗负载能力强配置性低工作稳定无流量今天总结一下负载均衡中LVS与Nginx的区别,好几篇博文一开始就说LVS是单向的,Nginx是双向的,我个人认为这是不准确的,LVS三种模式中,虽然DR模式以及TUN模式只有请求的报文经过Director,但是NAT模式,Real S

今天我们来聊聊一个非常经典的话题：JWT和Token+Redis两种认证方案，到底哪种更好用？有些小伙伴在工作中可能会纠结于选择哪种方案，今天我就从底层原理到实际应用，给大家做一个全面的剖析。希望对你会有所帮助。通过上面的详细分析，JWT和token+redis这两种方案，各有优缺点和适用场景。没有绝对的最好方案：只有最适合具体业务场景的方案。JWT优势在无状态和扩展性：适合分布式系统和API优先

我们一起梳理下框架中的核心部分分片策略和分片算法，其内部针为我们提供了多种分片策略和分片算法，来应对不同的业务场景，本着拿来即用的原则。这次将详细介绍如何在中实战 5 种分片策略和 12 种分片算法，自定义分片算法，比较它们的应用场景以及优劣。分片策略是和的组合策略，真正用于实现数据分片操作的是分片键与相应的分片算法。在分片策略中，分片键确定了数据的拆分依据，分片算法则决定了如何对分片键值运算，将

当多个进程访问同一数据库时，其中每个进程拥有的锁都是其他进程所需的，由此造成每个进程都无法继续下去。简单的说，进程A等待进程B释放他的资源，B又等待A释放他的资源，这样就互相等待就形成死锁。通过业务系统日志快速定位到发生死锁的代码块查看InnoDB的死锁日志，找出各个事务对应的代码块通过死锁日志和业务代码推测画出死锁的事务发生场景。

分片键选择大于努力：基因分片是订单系统的最佳拍档。扩容预留空间：建议初始设计支持2年数据增长。避免过度设计：小表关联查询远比分布式Join高。效监控驱动优化：重点关注分片倾斜率>15%的库。真正的架构艺术，是在分与合之间找到平衡点。

值传递是对基本型变量而言的，传递的是该变量的一个副本，改变副本不影响原变量。引用传递一般是对于对象型变量而言的，传递的是该对象地址的一个副本，并不是原对象本身，两者指向同一片内存空间。所以对引用对象进行操作会同时改变原对象。java中不存在引用传递，只有值传递。即不存在变量a指向变量b，变量b指向对象的这种情况。StringJoiner是 Java 8 新增的一个 API，它基于 StringBu