两千多，其它配置高，肯定有地方阉割的。

不过我觉得拍照还能看，如果手不抖的话更好

@Xbluer 首先用 get 确实是不对。不过有点不能理解怎么用 get 就能删除了，删除不得有权限有登陆吗，这个应该还暴露了权限验证问题？

@DOLLOR 不至于，我用 jq 的时候都是 js 混用的，都是操作 dom

这些都是面向对象的概念，还有些是各语言互相抄特性和语法糖

消费观以及虚荣心攀比吧，这种高端奢侈品品牌溢价高，对于我这种实用主义的穷人来说，没有花不完的钱是不会买这么贵的包包给自己的，当然，不可否认大部分贵的东西有贵的道理，我大学五十买了个二手耐克包，毕业后还背了好几年，确实背着比较舒服。

大部分人有虚荣心，个人可能是偏见觉得女性更多，当然了，我老家的农村人所谓面子也是虚荣心，买假的更甚。

我喜欢把屏幕亮度调到合适，个人眼睛受不了屏幕亮一点

看见 vscode 默认的那黑色我就头疼，同事好像都是用黑色，不过我写 java 的用的 light

低度，我觉得回归原始生活有可能自愈🐶

@SoloCompany mac 应该更安全点，https 还可以中间代理。我没研究错的话，mac 还可以实现限制签名不能重复使用

@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，数据库优化查询优化之类的

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

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