https://github.com/tdebatty/java-string-similarity
推荐标准莱茵斯坦算法和余弦算法，字符串较大就用余弦，对准确率要求高就莱茵斯坦算法。
附上测试一个测试类自己修改下，用自己的实际数据多跑跑

public class SimilarityAlgorithmTest {

@Test
public void test() {
String str1 = "ares";
String str2 = "kele";

LevenshteinDistance levenshtein = LevenshteinDistance.getDefaultInstance();
System.out.println("Levenshtein distance: " + levenshtein.apply(str1, str2));
System.out.println("Levenshtein distance: " + levenshtein.apply(str2, str2));

LevenshteinDistance levenshteinWithThreshold = new LevenshteinDistance(3);
// Returns -1 since the actual distance, 4, is higher than the threshold
System.out.println("Levenshtein distance: " + levenshteinWithThreshold.apply(str1, str2));

LevenshteinDetailedDistance levenshteinDetailed = LevenshteinDetailedDistance.getDefaultInstance();
System.out.println("Levenshtein detailed distance: " + levenshteinDetailed.apply(str1, str2));
}

@Test
public void testLevenshteinDistance() {
int sLength = 13_162;
int strLength = 4_000;
String s = StringUtil.random(sLength);
String s1 = StringUtil.random(strLength) + s;
String s2 = StringUtil.random(strLength) + s;

int threshold = 4_096;
LevenshteinDistance levenshtein = new LevenshteinDistance(threshold);
long startTime = System.currentTimeMillis();
/*
threshold 为 32766 时花费 7022ms
threshold 为 16384 时花费 2164ms
threshold 为 8192 时花费 463ms
threshold 为 4096 时花费 146ms
threshold 为 2048 时花费 62ms
threshold 为 1024 时花费 41ms
threshold 为 512 时花费 29ms
*/
Integer result = levenshtein.apply(s1, s2);
System.out.println(System.currentTimeMillis() - startTime);
System.out.println("Levenshtein distance: " + result);

/*
这种是截取模式比较靠前的指定字符
threshold 为 4096 时花费 67ms
*/
levenshtein = LevenshteinDistance.getDefaultInstance();
startTime = System.currentTimeMillis();
result = levenshtein.apply(s1.substring(0, threshold), s2.substring(0, threshold));
System.out.println(System.currentTimeMillis() - startTime);
System.out.println("Levenshtein distance: " + result);
System.out.println();

result = levenshtein.apply(s1, s2);
System.out.println("Levenshtein: " + (1.0 - (double) result / (strLength + sLength)));
NormalizedLevenshtein normalizedLevenshtein = new NormalizedLevenshtein();
double similarity = normalizedLevenshtein.similarity(s1, s2);
System.out.println("NormalizedLevenshtein: " + similarity);
Jaccard jaccard = new Jaccard();
similarity = jaccard.similarity(s1, s2);
System.out.println("Jaccard: " + similarity);
Cosine cosine = new Cosine();
similarity = cosine.similarity(s1, s2);
System.out.println("Cosine: " + similarity);
QGram qGram = new QGram();
similarity = qGram.distance(s1, s2);
System.out.println("QGram: " + (1.0 - similarity / (strLength + sLength)));
}


@Test
public void testAlgorithmPerformance() {
String s1 = StringUtil.random(13_162);
String s2 = StringUtil.random(13_162);

LevenshteinDistance levenshtein = LevenshteinDistance.getDefaultInstance();
long startTime = System.currentTimeMillis();
levenshtein.apply(s1, s2);
System.out.println("LevenshteinDistance:" + (System.currentTimeMillis() - startTime));

NormalizedLevenshtein normalizedLevenshtein = new NormalizedLevenshtein();
startTime = System.currentTimeMillis();
normalizedLevenshtein.distance(s1, s2);
System.out.println("NormalizedLevenshtein: " + (System.currentTimeMillis() - startTime));

JaroWinkler jaroWinkler = new JaroWinkler();
startTime = System.currentTimeMillis();
jaroWinkler.distance(s1, s2);
System.out.println("JaroWinkler: " + (System.currentTimeMillis() - startTime));

LongestCommonSubsequence longestCommonSubsequence = new LongestCommonSubsequence();
startTime = System.currentTimeMillis();
longestCommonSubsequence.apply(s1, s2);
System.out.println("LongestCommonSubsequence: " + (System.currentTimeMillis() - startTime));

info.debatty.java.stringsimilarity.MetricLCS metricLCS = new info.debatty.java.stringsimilarity.MetricLCS();
startTime = System.currentTimeMillis();
metricLCS.distance(s1, s2);
System.out.println("MetricLCS: " + (System.currentTimeMillis() - startTime));

QGram qGram = new QGram();
startTime = System.currentTimeMillis();
qGram.distance(s1, s2);
System.out.println("QGram: " + (System.currentTimeMillis() - startTime));

Cosine cosine = new Cosine();
startTime = System.currentTimeMillis();
cosine.distance(s1, s2);
System.out.println("Cosine: " + (System.currentTimeMillis() - startTime));

Jaccard jaccard = new Jaccard();
startTime = System.currentTimeMillis();
jaccard.distance(s1, s2);
System.out.println("Jaccard: " + (System.currentTimeMillis() - startTime));
}

@Test
public void testCosine() {
String s1 = StringUtil.random(1_000_000);
String s2 = StringUtil.random(1_000_000);

Cosine cosine = new Cosine();
long startTime = System.currentTimeMillis();
cosine.distance(s1, s2);
System.out.println("Cosine: " + (System.currentTimeMillis() - startTime));
}

}

最简单的就是找文档，没文档就只能自求多福了，其实本身 dll 和 maven 依赖一样都是第三方库，但由于需求不是强所以 dll 的名单从来都没有地方管理, 我理解可以做个类似 Python requirements.txt 的东西管理起来，本来 jdk 做这个事情是最合适的，其次就是 maven 插件也可以做，但现在没有任何标准的话除了翻源码就是在测试环境多测测了（保持和生产环境一致）。

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: 很多大数据量的表的产生来自于最早的设计问题，一般适合分库分表的都是些流水表

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