虽然我也在场内，但是劝人炒 A 股还是算了，毕竟“无论你上辈子造了什么孽，只要你玩 A 股就一笔勾销了”。
在国内股市出现实质性改革之前，建议别碰，还是多研究点国外的基金吧

我还以为只有我嗝屁了，原来大家都差不多🙈

DDIA

@besscroft #11 深圳这边，领失业金期间是每月会免费帮交医保，还会打 2000 多块到卡上，不知道其他城市是怎么样的，感觉应该大差不差……不过有个很重要的前提，失业原因必须是公司辞你，而不是自愿离职

我看法跟 29 楼一样，如果想转码，你的难点是如何找到第一份工作，因为简历基本都是靠学历专业 + 工作年限来筛掉第一波人，后面才是看你技能树以及做过的项目如何……

最后这个图，看来是望京 soho 程序员了

深圳

租房（含水电等费用）：2500
吃饭（含水果零食费用）：1300
交通：280
话费：40
游戏：90
其他：300

总计：4510

这个月月底搬到公司附近，租房和交通能省个七八百

@luoleng #71 我觉得我需要把这张图放上来 

@laozhoubuluo #10 很遗憾，因为实际请求耗时并不恒定，所以这个补偿的差值很难把控，若是能确定差值的话，直接调整令牌恢复速度就可以实现了

@rockyliang #9
@z1829909 #11
实际业务是有高并发场景的，不能阻塞其他的请求任务，不然很容易堆积，同时还有性能问题，所以是做成了内部校验条件不满足就跳过去的情况

好吧，看大家的意见都差不多，基本是没必要在这边也搞个限流，侧重点应该放在重试而不是限流。

看样子是我自顾自陷入死胡同了，总想着待在坑里应该怎么优化，而没想过应该从坑里跳出来…… orz

多谢大家的回复

从你给的 explain 图来看，走的是 [idx_orders_create_time] 索引，假设这个索引只有 create_time 这一个字段，这意味着它在底层查询实际上是这样的：

从创建时间开始降序查询，每条数据都去回表，查询是否满足条件为 [ WHERE user_id = 10 AND order_status IN ('PROCESSED') AND status = 'pending_orders' AND shop_id IN ('123456')] 的数据，捞够 20 条才停止。

某种意义上来说，跟全表扫描差不多……

@quicksand #13 这种无差别开火的面试官，一般只会问常见的八股文，像老掉牙 hashmap 什么的，其他的对方可能自己都不知道。当然这种面试体验会很差，让人感觉自己像个问答机器，还有如果遇到刻意往刁钻问 + pua 的，那就没办法了

感觉面试基本是简历上精心准备几个亮点，再根据亮点涉及到的知识去深入，最后在面试时尽量把话题往这方面引，漫无目的去背八股文，永远背不完的……

@stillsilly #259 救命，不要给我看拼音变量名……

@k9982874 是的，11 楼的答案是之前没想到的新思路，完全可行且不复杂，正是我想要的那种

感谢上述各位的讨论与回复 _(:з」∠)_

@546L5LiK6ZOt 是的，最纯粹的做法就是唯一索引，只是原先表的业务逻辑不支持……不过确实新增一个中间表就能解决，并且比起各种加锁要简单得多，操作只需要批量插入和删除，性能也只是多一两次 SQL 操作。非常感谢，这是新思路！

@k9982874 背景就是 sku 只能是商家自定义的，要原模原样，不能再在上面改东西……

@xwayway 这种操作是会同步返回结果的，从同步改成异步，这逻辑变化有点大了

@alexleee 锁店铺粒度大但只锁一个，锁 sku 粒度小但需要连续锁多个（假设按最差的情况为 200 ），我还没实际遇过连续锁这么多次只为单个商品的创建，总觉得不太对劲，这性能正常吗……

@leonshaw 对，我那个方案其实就相当于等效的加锁操作，但不确定这种单次操作中，包含了几十甚至上百次 redis 请求的性能如何

@546L5LiK6ZOt 有考虑过，但要解决该问题，锁只能加在店铺维度，粒度有点大

@hhjswf 用爬虫爬别人商品，然后批量创建到自己店铺，那个内部服务直接用多线程打过来时发现的问题……

@Chad0000 但检测数据库那里只是一条 SQL ，而这里校验时连续调用 200 次 RSet.add ，这个性能会不会有点夸张？我对这块没啥概念……

@alexleee 有考虑过，但这个锁是 SKU 维度，那加锁次数是跟 SKU 数量一致的，而商品与 SKU 是一对多的整体关系，不能说一个个 SKU 单独校验和保存，所以单个商品可能加上几十甚至上百个锁……

@kwh 自增是商品通过校验，还是 SKU 通过校验？它们是一个整体的，并且是一对多的关系……MySQL 行锁应该不行吧，问题不是保存操作，而是校验操作那里的高并发