@Mitt 是不冲突，一个更像是分发内容给第三方，一个是登陆，但我发现有些人给的接口应该用的不对，不应该用 bearer token，而且也只用了 token，没有 nonce 的限制

@zoharSoul 就是用 app_secret 给时间戳+appid+nonce 签名这种

那就在职找一下工作呀

其实我比较喜欢风量较小的内机，这样就比较安静，而外机主要看安装的怎样，没安装好声音超级响

其实我个人觉得黑美人还挺好吃的，口感也不错，甜的和麒麟瓜不一样

这个还是初级的八股文，要是细节起来，比如上次就不是有人发帖问 Integer 比较的，哈哈..上至各类中间件源码及使用，下至语言细节都有问的

忽略我之前说的哈，是我之前学习时没搞明白并且也忘了。现在在这里补充一下我今天看的，当作在这做个笔记，如果打扰到楼主，感到抱歉~

首先我把标题改一下，楼主问的也挺好的，就是问 事务消息这种形式和在本地事务中耦合发送普通消息的差异。

在本地事务中耦合发送普通消息时，就是楼主一开始问的“在事务中投递消息，如果投递消息失败则回滚”，这个是没有问题的，最多是可能需要尝试发几次，本地事务很好回滚，这个没啥问题。 而“事务消息”，如果预发送和本地事务都执行成功了，那提交消息这一步到最后一定需要执行成功，没有回滚这一说。

而在本地事务中投递消息，会有什么问题呢，以下摘自 https://blog.csdn.net/zxjoke/article/details/105260252

// 开始事务
try {
// 1.执行数据库操作
// 2.发送 mq 消息
// 3.提交事务
}catch (Exception e){
// 4.回滚事务
}

上面代码看起来确实没什么问题，消息发送失败，回滚事务。
但是实际上第二步有可能存在消息已经发送到 MQ 服务端，但是由于网络问题未及时收到 MQ 的响应消息，从而导致消息发送端认为消息消息发送失败。
这就会导致订单事务回滚了，但是手续费系统却能消费消息，两边数据库又不一致了。
熟悉 MQ 的同学，可能会想到，消息发送失败，可以重试啊。
是的，我们可以增加重试次数，重新发送消息。但是这里我们需要注意，由于消息发送耦合在事务中，过多的重试会拉长数据库事务执行时间，事务处理时间过长，导致事务中锁的持有时间变长，影响整体的数据库吞吐量。
实际业务中，不太建议将消息发送耦合在数据库事务中。

@SilenceLL 你 4 楼说的不行，不应该将发送消息的代码放入到数据库事务中，否则在重试发送消息的过程中过多的重试会拉长数据库事务执行时间。

至于 5 楼说的和发普通消息没区别了，具体事务消息对此有何优点，我也没找到，网上很少有说回滚本地事务操作这块的内容的

会编写 shell 脚本写到 linux 那一行，git 后面取而代之你可以写 git flow
然后 mysql 后面补充一下熟练编写 sql，数据库优化查询优化之类的

无论如何都是要等本地事务执行成功后再尝试提交消息（事务消息在本地事务执行前只是半提交），如果提交消息的代码穿插在本地事务中间，就会出现一楼说的消息提交后本地事务又失败了怎么办。提交消息成功没有回滚这个说法，事务消息那个回滚是因为消息中间间支持了半提交的消息。

如果你用普通消息，本地事务执行完后最后发送消息失败，需要重试发送，或者对已经执行成功的本地事务进行处理。事务消息那是另外一种做法

薪水怎样？以及能分享你怎么转岗的吗

@WhaleFallrya 嗯。可能吧，我之前在西北那边遇到一个律师，他是三十多从农场出来上大学读的法律，然后做律师，现在四十多快五十吧，做了十来年，现在是律师事务所的二把手

你把 git 一样可以做 svn 用，就开几条版本分支，比如 master test dev1.0 dev2.0，所有人基于一个远程分支直接 push 又不是不可以

不如考个司法考试做律师呢，不过好像开始有限制了

看过好多 170 不到的男生，女朋友有 165，甚至女生比男生高，真的羡慕啊……

@est 太大了，拖不了几次，得是 4.0000001🐶

我想了下，觉得全量没毛病的，其实全量也是更新一个区间的数据，具体多少就是拖拽了多少个位置，性能上问题也不是很大，限制一下一次最多能拖多长就行

放一个事务里没有你说的原子性问题。

你从 1 拖到 100 拖到很长了，大量数据要求拖拽排序的业务场景很难想象是什么，像信息流之类的不如给个权重设置。

有请后面大佬给出方案

@yeqizhang 眼熟