mercurius 最近的时间轴更新
mercurius

mercurius

V2EX 第 387814 号会员,加入于 2019-02-27 18:50:29 +08:00
今日活跃度排名 21535
mercurius 最近回复了
88 天前
回复了 mercurius 创建的主题 程序员 求助一个高并发的数据校验与保存问题
@k9982874 是的,11 楼的答案是之前没想到的新思路,完全可行且不复杂,正是我想要的那种

感谢上述各位的讨论与回复 _(:з」∠)_
88 天前
回复了 mercurius 创建的主题 程序员 求助一个高并发的数据校验与保存问题
@546L5LiK6ZOt 是的,最纯粹的做法就是唯一索引,只是原先表的业务逻辑不支持……不过确实新增一个中间表就能解决,并且比起各种加锁要简单得多,操作只需要批量插入和删除,性能也只是多一两次 SQL 操作。非常感谢,这是新思路!

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

@xwayway 这种操作是会同步返回结果的,从同步改成异步,这逻辑变化有点大了
88 天前
回复了 mercurius 创建的主题 程序员 求助一个高并发的数据校验与保存问题
@alexleee 锁店铺粒度大但只锁一个,锁 sku 粒度小但需要连续锁多个(假设按最差的情况为 200 ),我还没实际遇过连续锁这么多次只为单个商品的创建,总觉得不太对劲,这性能正常吗……

@leonshaw 对,我那个方案其实就相当于等效的加锁操作,但不确定这种单次操作中,包含了几十甚至上百次 redis 请求的性能如何
88 天前
回复了 mercurius 创建的主题 程序员 求助一个高并发的数据校验与保存问题
@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 的一种实现
关于   ·   帮助文档   ·   博客   ·   nftychat   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2211 人在线   最高记录 5634   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 19ms · UTC 16:04 · PVG 00:04 · LAX 09:04 · JFK 12:04
Developed with CodeLauncher
♥ Do have faith in what you're doing.