库存分段提高秒杀并发度
做的黑马点评的项目,面试时被问到在使用分布式锁解决超卖的情况下如何提高并发?回答将库存分段,比如100个库存,分别存在5redis节点上,每个节点上存储20个。但面试官问如果有一个节点上库存卖光,但总库存还有,怎么保证能卖就卖?当时回答的是提供一个协调者,监控每个redis节点上的剩余库存量,然后通过协调者进行转发。但是面试官对这个答案不太满意,说协调者仍然是串行的并且秒杀是很快的,如果通过一次协调者转发的话会有延迟并且脏读的问题。请问各位大佬这个分段库存在实际的应用场景中到底该怎么设计?#秒杀项目##蚂蚁##面经##redis##java##阿里#
全部评论
实际场景就是不会用分段库存。简单点就redis硬抗7、8w秒杀的请求,超过容量的就限流掉,给用户一个兜底。但是redis容易丢数据(实际上也没那么容易丢,5个9),所以用mysql来抗写,redis抗读,这时候会去魔改mysql内核,让mysql能够支持5w的写请求
草了,刚面试那个面试官也说的分段,给我说晕了

m
m
m
m
m
m
m

点评是真火呀
m
m
m
m
m
m
m
m
相关推荐
06-14 13:13
门头沟学院 Java 程序员牛肉:其实你这个问题千言万语是一句话:如何保证Redis跟数据库的一致性嘛。
各大公司都是有那种对账的。数据一致性校验平台这种中间件来去确保二者之间数据的一致性。
你可以这样理解,就是我们在这个平台上面呢会基于代码呢去实现一个规则,就是说我去监听数据库的binlog日志,然后会对binlog日志进行实时解析,跟目标数据源进行对比,以此呢来判断数据是否一致。
那放到你这个场景里面呢,就是说每当一个用户的优惠券落库的时候呢,那它会产生对应的log日志,我们就把这个日志捞出来,从log日志里面取出信息拼接Redis的对应key,查一遍Redis。
如果radius里面有数据,那就说明c口跟log的数据是一致的,如果没有就说明他们两个有一端不可信嘛,那你就选择可信的一端,对另外一端进行数据补偿就好。
点赞 评论 收藏
分享