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

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

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

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

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

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

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

上面这个 1 年或不到 1 年一跳，还需要看是不是连续几年都这样，如果不是连续的应该还好

当然，上面只是我个人看法，感觉如果自身技术够硬，这些也不算事……

@KedaArray 1 年或者不到 1 年一跳。
待没多久就换一家公司，代表着不稳定，从招聘和培训的成本考虑，一般会 pass 掉

大概总结了下，问题点是频繁跳槽和降薪

1 、频繁跳槽算是个简历雷点
2 、降薪后，若不跳槽就可能长时间处于该价位，基本只能靠下次跳槽来突破

至于接不接受这份工作，在自身没有经济压力的背景下，可以先思考下性价比，即从薪资、工作强度、工作时长、公司氛围、技术架构等方面，跟上家公司做一个对比，等对比完了后抿心自问，自己内心有没疙瘩，基本结果就出来了

顺带再问一下，对于空窗期，大家是怎么看的？

我在网上找了很多关于空窗期的帖子，目前有个模糊的观点，就是对于国内而言，空窗期要尽量控制在 3 个月内，因为很多 HR 在筛选简历时会过滤掉空窗期长的，认为空窗期越长，代表越不稳定，越不容易受控和压榨？

在目前这个恶劣的大环境下，感觉空窗期几个月的比比皆是，现在还会将其视作雷点吗？

@aw2350 坐标深圳，至少 4k 往上，不过并不是我面临这个抉择，只是对这块没啥认知，所以想问下大家的看法。

目前看是骑驴找马者居多，先上车再到车上跳，但频繁跳槽 + 降薪，下份想再往上跳不会更难吗？

我理解是频繁跳槽的容易在简历时就被筛，降薪再往上要则容易被卡涨薪幅度。

还是说这两点对于在职来说根本不算事，找不到就继续找，反正是在职的，只要有一家找到就行？

https://s2.loli.net/2023/02/20/nj27OqbSkJmsVAi.png
应该就跟 3 楼说的一样，因为是 Backward index scan 所以找到第一个不满足条件的不是 25 ，而是 10 （个人猜测因为是倒序的，所以这里的间隙锁应该为 (10,5] ，前开后闭区间），把排序去掉后间隙锁就是 (20,25] 了
Backward index scan 是 MySQL8.0 后才出现的，可以用 5.7 版本试试会不会一样的结果

Feign 底层实际上是 HTTP 请求的封装实现
RPC 本质上不算是协议，而是一种调用方式，并且 HTTP 协议只是 RPC 的一种实现

从群里看到截图后摸过来了，果然截图是断章取义

https://i.v2ex.co/504J5BO2.png 我怀疑你在钓鱼