请问一下，这是一个封装了 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 挨个查。
要么再搞个数仓，去数仓查
要么异构索引表

@RotJun #5 他这个这么便宜是什么原理

@Chinsung #10 commit;
这种最明显，别的都有点玄学

个人感觉 begin;
insert……

这种都是要看取舍的。
首先，你描述的这种情况，并不是死锁，因为并没有互相等待对方持有的资源。watchdog 不释放，唯一的情况也就是其他后续的线程一直去争抢和尝试获取这个锁，但是这里 redisson 还有优化，用了 redis 的订阅机制来解决，后续到达的线程都会直接挂起自己等待订阅机制来唤醒。
如果死循环的话，上游或者下游一般总有一个会触发超时机制，无非是时间可能会比想象的要长非常多罢了。
宕机的话，redisson 续约的线程也会宕机，就不会触发续约，其他机器就能拿到这个锁，所以也不存在问题。
说到底，你是用这个机制的本意就是希望“锁不要在任务没有执行完之前就释放”，然后反而又要求“万一永远执行不完，还是要释放掉”。最终的考虑就是在这 2 种情况间，哪种情况出现的后果更麻烦，你就选择解决对应问题的方案