本地 30%了还去上海干啥 住城中村？

xx 字幕组 [狗头]

要么去外企，要么就考公。介于现在的国际形势，外企可能有风险。所以只有考编一条路。

@zw1one 然后 1 年工作经验的时候 run 二线互联网了，薪资 double 。当然也有运气成分

别太乐观，很多公司卡简历，直接三到五年过滤，你的简历 hr 看都看不到。

也别太悲观，丰富下简历，多投一段时间，总有适合你的职位。我以前的同事，每天下班卷算法，八股文

@fml87 诶 太真实了。
每次问程序员 35 岁的问题，总有人说是月经贴、贩卖焦虑。没有人愿意正视这个问题，直到它真的发生了。

你就和室友直说 和他们住挺开心 但是觉得这样住太挤了 要找人事换宿舍 他们同学住人的是你不会说出去。

@documentzhangx66 兄弟做得太极端了，你和女友应该有更好的办法谈谈。没有人喜欢和易怒控制不住自己的人在一起的，亲人和家人也不会想。

目前不重要的存语雀，本地临时存图文用 one onte ，自己笔记存 github

确实容易陷入自我设限的陷阱中，比如觉得自己是后端，前端 /产品说的东西，就一概与我无关。
不是说要多为公司着想，主要是培养自己的思维和认知。

同理也适用某些产品。觉得自己是产品，就对技术一概不闻，觉得都是开发的事，自己不需要了解。

外包就是卖猪仔 卖到就是赚到

感慨下，真国企太香了

@zw1one 打错字。"可不是两种东西" -> "可是两种东西"

@hhjswf 国企子公司 /科技公司，和国企总部 /省公司。可不是两种东西[狗头]

### 不同用户的不同订单，是不会出现你说的问题的(你说的全局 synchronized 又是另外一个问题了)。这里我假设你要处理的问题是: 相同用户对一笔相同订单重复提交(多个用户来提交一笔订单也成立，扫码点餐)

- 场景 1: 用户用浏览器 A 登录，发起一笔支付，在支付结果返回前，再用浏览器 A 发起支付
通常用前端校验，但前端校验可绕过。后台需要用"订单号 ID"加 redis 分布式锁校验，若不能获取到锁，则代表该订单有处理中且未返回的支付请求，拒绝该次请求。

- 场景 2: 用户用浏览器 A 登录，发起一笔支付，在支付结果返回前，再用浏览器 B 发起支付
该情况前端无法校验。后台同样是 redis 锁处理。

- 场景 3: 用户用浏览器 A 登录，发起一笔支付，在支付结果返回后，再用浏览器 B 发起支付
该情况前端无法校验。后台通常在数据库表加上 data_version 字段处理，这里你用订单 flag 字段判断也可解决。

结论：
我没理解错的话，你这个问题是接口幂等问题。需要保证一个接口被多次调用(相同或不同客户端)得到的结果相同。
- 前端校验: 拦截部分客户端重复提交问题，但不能完全解决。
- redis 锁校验: 解决请求未处理完成，又出现新请求的情况。直接拒绝新请求。
- data_verison 校验(或者 flag 字段): 解决请求处理完成后，再次发起请求的情况。

### 至于异步回调，也是幂等问题。
如果你的支付申请处理好了，是不会出现两次回调的，除非第三方出问题了。
如果支付申请没处理好，出现两次回调，且订单 flag 都查到为 1 ，它们的操作都是修改订单结果为 2 ，代码运行两次是没有问题的。mysql 处理逻辑：先修改订单 flag 的事务 A 会给该条数据加写锁，事务 B 修改订单 flag 会等待获取锁。
出现这种情况把异步回调的日志记录好就行。

### 其他
- synchronized 无法处理一个应用部署多个副本的集群情况。可以按对象加锁。
- flag 字段，0 未支付，1 支付中，2 支付完成。
建议保留状态"支付中"，该状态可以表示等待第三方回调，当请求发出去，第三方出现问题(超时、宕机)没有回调的时候，便于排查问题。
- 做好上面这些。再来考虑异常退款给用户的人工操作。因为即使代码上处理了，还会有服务器宕机、第三方平台问题等情况出现。生产问题总归是少不了的 :)

老哥这么牛 好奇年包多少(不用太具体)

工作与自我学习不冲突，何况你在国企又不是在互联网。

写给 20 几岁的程序员：尽早考编上岸