DynamicDataSourceContextHolder push 完之后要手动 poll 的，最好使用注解自动就做掉了免得自己忘了造成线程污染

fluentbit + ELK, 这个是最流行的商业级方案，小项目就存文件算了吧，切好片做好格式等日志规范是最实用的，出于学习目的就上 loki

@bill110100 orm 的全称是 Object/Relational Mapping ，比较典型的特征就是你只管操作对象框架会帮你把对象的变更映射到数据库，mybatis 本身只是存放 sql 不存在有时候连表对应的对象可能都不会存在，mybatis plus 才是 orm ，而如果要说到更纯正的 orm 还要用到 Active Record 模式，像 python 中的 SQLAlchemy 、c#的 Entity Framework 都是比较纯正的 orm 。

这个场景反射就是最简单的方案。

1.agent + 字节码改写 这个组合几乎可以做任何事情，但引入 agent 其实是个成本很高的事情还是要慎重；
2.静态代理 对方法有入侵；
3.定义一个函数把 main 传进去；
4.字节码改写有三个时机，编译期织入、装载期织入、运行期织入，完全可以像 lombok 那样做一个编译期织入的注解，关键词 AbstractProcessor ；

所以有了 fastutil 这个库。。话说 java 自己的 Valhalla 项目正在做泛型特化以后你就可以用 List<int>了。

配置一堆层是指 mapper 、dao?
纯用 mybatis 的人不多了，现在基本上都是用 mybatis plus ，单表增删改查用 baseMapper 复杂的才会用 xml ，这玩意你就理解成是个专门存放 sql 的地方，古早时期 sql 都是混在 java 代码里面的，后来发现维护太麻烦了（比较重要的原因是当时没有多行字符串这个语法糖）就想把 sql 和代码区分开，mybatis 选取了当时流行的 xml 格式使用 ognl 作为动态能力的补充，确实解决了代码和 sql 分离这件事情，只是到了现在 xml 人人喊打，ognl 表达式也略显笨重所以质疑声此起彼伏，但叫归叫其它能取代它且稳定好用的框架暂时还没出现。
歪楼：mybatis 不是 orm ，java 的 orm 月经帖太多了，目前的几款 orm 如 mybatis plus 、jpa 、hibernate 都有各自的问题，我对此比较悲观除非有 C#那种强大的语法糖，一款非常好用且完备的 orm 在 java 里可能很难诞生了

所以说 goto 部分场景下还是有价值的。
针对这个场景用流也是个不错的方案。

无非就是顺序消息存在的必要性，答案是有必要。只是说不能一股脑地把问题都丢给中间件以为就万事大吉了，10TPS 有 10TPS 的处理方式，1kTPS 有 1kTPS 的，10wTPS 也有 10wTPS 的，就事论事选择最适合业务的。

瞄了眼源码，除非改源码实现不了。

第一 MP 功能确实不够强大，其实对于 excludeProperty 本来应该是提供 @JsonIgnore 、 @JsonIgnoreParentProperties 这样单独的注解去实现的，同时还要留给外界一些扩展点类似 jackson 的 BeanSerializerModifier 去做自定义。
第二虽然知道很多小项目怎么写都可以顺手就行，但是 DO 一把梭随便继承这种坏习惯能避免还是尽量避免，至于为啥不用继承这几乎是一种共识了，耦合度 继承 > 接口 > 组合。

都会进入内核态，只是 synchronized 的重量级锁底层是插入了 monitorenter 和 monitorexit 两个指令，以最流行的 JVM HotSpot 为例其底层使用了 mutex （ linux 下）这个非常重的锁，而对于 AQS 使用的 LockSupport 的 park 和 unpark ，其底层会使用操作系统提供的原语，如 pthread_cond_wait （对于 POSIX 线程库）或 Windows 上的 WaitForSingleObject 等来实现线程的挂起，再使用 pthread_cond_signal （对于 POSIX 线程库）或 Windows 上的 SetEvent 等来实现线程的唤醒，这些操作系统原语通常是高效的，允许线程在等待期间几乎不占用 CPU 资源，从而有效地实现了非阻塞的线程等待和唤醒。

不过 1.8 以后性能大差不差了（很多东西也互相借鉴其实逻辑上已经高度相似），只是 AQS 系列的锁更灵活 api 更好用，如果只有上锁解锁随便用哪个。

如果参数是已经计算好的变量判断不判断其实都还好，如果占位符的参数还涉及到比较吃 cpu 的计算最好还是判断下能节省点 cpu 。

mq or 定时任务

@sl450282169 正解

看看 SOFA Boot ，本质上就是自定义 classloader 这条路。

ShardingSphere-JDBC 是客户端分表，一般用分库分表基本上用它的比较多（对程序员更可见也不依赖中间件），ShardingSphere-Proxy 是代理层中间件和 dbProxy 比较类似，允许定义全局表、分片表、序列这些，但如 3 楼所说这些大概率都是些中间产物，未来真正的分布式数据库会淘汰掉它们，当然从学习和实现业务的角度来说学一学倒也无妨。
ps: 很多大数据量的表的产生来自于最早的设计问题，一般适合分库分表的都是些流水表

有没有比较便宜的推荐，自己的快到期了。

@mmdsun 真这么简单早升级完了，光 JPMS 和反射的限制就够喝一壶的，更别提原有的 java agent 可能都要失效了，我手上的项目 100 多个应用，2000 多个 pod ，要真到 21 没个两年下不来。

生产还是 java8 ，太难升了，比如你依赖的单点登录的 client 是 1.8 吧不支持 11 你怎么推动别人改造
可以看看这篇 为什么很多公司选择不升级 JDK 版本，仍然使用 JDK8 ？ - 君莫惘的回答 - 知乎
https://www.zhihu.com/question/325293339/answer/1150270157