@james122333 #48 我也没说过流行就是真理，只是 spring 的缺点也和这个人所谓的性能没有任何关系，稍微了解一点 spring 的人也知道 spring 只是一个容器和规范，除了 MVC 之外几乎全部是依赖第三方开源的支持，spring 自己除了 mvc 和 bean 管理，其他全都是定义的扩展让各种框架和三方库去集成进项目而已，spring 一个基本既没有实现线程池也没有实现连接池的东西，基本代码都跑在 tomcat 工作线程里的东西，除了依赖比较多的反射实现注解，有什么讨论性能并且和 NIO 拿来 PK 的必要？ spring 再有缺点，和他说的东西也没什么关系吧？
更别说现在 GraalVM 支持预编译但是又不能用反射了这件事多被诟病，反射切面只是设计方式，人们用它只是方便，spring 也没强迫你用

@statumer #41 你这种人确实真心让人懒得理你，spring 作为一个容器，确实大大的影响了 JVM 性能，你自己看看你自己前面说的都是什么东西吧，你说 Spring 阻碍了 DDD 还算你懂点东西，Spring 影响了 java 性能那你真是天才，我寻思是 Spring 提的 JDBC 和 J2EE 规范是吧？ Spring 确实不是 One True God ，但是在你看来 Spring 就是 Java 的 original sin ，建议你大力推广下别的框架来拯救 Java 生态，让那 60%+的全世界 javaer 认清 Spring 的丑恶嘴脸

@statumer #35 啊确实，根据 idea 的统计，用 java 的里面基本还是 spring boot 和 tomcat 称王，说明全世界的 javaer 基本都是你嘴巴里不懂 NIO 的 spring boy
https://www.jetbrains.com/zh-cn/lp/devecosystem-2021/java/
java 厉害，但是 java 里最流行的框架 spring 不行，你不觉得你精神分裂吗？
不知道你用的什么完美语言，竟然都让你用出优越感了，我有点想学习下新语言了

@billlee #19 叕叕叕看到有人吹 NIO 了，NIO 固然厉害，但是建议楼主了解 NIO 原理和 netty 就行了，至于说 JDBC 因为同步阻塞不用的更是有点牛，大部分复杂点的业务都是要大量 sql 的，你不会把依赖上下文的 sql 写回调里或者手动 block 吧，不会有人喜欢这么写业务逻辑吧，不会吧不会吧。spring 自己都推不动 spring boy 用 spring reactive ，咋办呢？

请问一下，这是一个封装了 redis 集群常用 lua 脚本的项目吗

先找个 dubbo 或者 springcloud 项目的公司加入去搞一下，这块没项目经验很难进去

拆不一定要拆服务，就算是单体应用，只要业务、包、模块，这些东西划分的好，完全没必要拆。你要想拆是解决什么问题，一般主要解决的都是某个业务水平扩容与单体应用水平扩容的矛盾，基于其他目的来拆，都是耍流氓

@dongfuye1 #26 所以我想表达的是，你需要从新造一遍 MQ 中间件的轮子啊。。。。。。。。

@dongfuye1 #15 所以我其实好奇哈，事务性消息之所以叫做半消息，就是因为它具有消息该有的特性，那你的 dtm 在通知下游微服务 2 的时候，能保证最终一致性吗？重试策略和拉取策略是什么？
并且解耦方面也存在问题，就比如比较常见的电商场景，加入支付成功操作要扣减库存和减少优惠券，我定义了 TranIn1 和 TranIn2 ，这个时候我又要给用户加积分了，我是不是要在 TranOut 端定义 TranIn3 ？另一个问题就是，你如何保证这种广播式事务的情况下，dtm 的“推”性能？
上面这些问题也都是消息队列中间件解决了的问题，dtm 是否都需要从新解决一次

这个和 RocketMQ 支持的事务消息有什么区别吗

@undermask #21 这就是信息密度的区别，也是象形字和罗马字的区别，英文的词语含义更准确，但是你
1. 不知道这句话含义，
2. 词汇量没有到确信自己认识大部分单词
的情况下这句话的每个单词其实你都不知道是什么意思。
尤其是一些包含专业词汇的文章，更是如此

1. 并不是主动，master 只负责往 binlog 写日志，slave 去订阅日志，有没有 slave 订阅和 slave 有没用成功与 master 无关
2. 不能，本质上 slave 只是拿到 binlog 去原模原样执行一次
3. 这个可以，前提是主库一直开启着 binlog ，从库 change master 的时候是可以指定 binlog 文件的
4. 同 3
5. 同 4
在线同步百度下文章

默认不太可能，得改 BIOS 首选 USB
U 盘都可以，移动硬盘肯定也可以

非母语的除非你英语十分专业，否则阅读的不可能顺利
而且中文的信息密度是大于英文的，所以两者的阅读习惯也不一样
比如
研表究明，汉字的序顺并不定一能影阅响读

@seasonsolt #74 和你方案一样的就是高质量回答是吧，我比较好奇，你们这种做法
1. 如果用户重复支付了，会在用户端看到自己支付了多笔并且有几笔正在退款的信息吗？
2. 如果退款某笔失败了，你们是无限轮询还是手工处理，如果退款出现延时，难道用户就没有意见不会投诉吗？
3. 对账的话，如果跨清算时间退款了，对账复杂度也会比较高吧
一个用户 id+订单 id 加分布式锁的问题，对吞吐的影响真的有那么大？

update 之前的时候加个分布式锁，获取到锁之后进去再 check 下状态是否是 1 ，是 1 直接报已在支付中了，否则 sql 带上 where flag=0 去更新下，根据更新成功行数判断是否需要发第三方支付
虽然你是同订单，其实并不存在高并发只存在并发，但是数据库锁最好少用，一个是得依赖唯一索引，另一个就是真高并发来了，数据库绝对会频繁报死锁
这种场景一般都是设计 2 张表，一张商品订单表，一张支付订单表，商品订单表改状态支付中直接就改了，扔个 mq 给支付订单表去生成支付订单，然后支付订单这里根据商品订单分布式锁做幂等就行了

重试配置好，直接 try 下一台机器就行了，当次请求的延迟可能会高一点
要么就检测实例 down 了就发 eureka 接口手动下线

不带分片 key ，当然扫全表了。
要么先查出来分片 key ，用分片 key 挨个查。
要么再搞个数仓，去数仓查
要么异构索引表