关于黑马点评的一些疑问
1.为什么要用redis存储点赞,大量点赞如何优化
2.异步下单了,写入数据库失败了怎么办,一致性如何保证(看好像没有使用事务了,但有ACK以及处理pending-list)
3.判断完了一人一单和超卖,下单更新数据库时再次查询库存是否充足以及乐观锁和分布式锁是不是没有必要了
4.项目中遇到的困难(想说滚动分页查询但是源码还是有BUG的怕给自己挖坑)
5.最严重的一个问题,为什么要用mq,用线程池不是一样吗,不是分布式,生产方和消费方在自己的服务上进行消费吗?
兄弟们看下我的最新动态帮我选下offer吧,非常感谢
2.异步下单了,写入数据库失败了怎么办,一致性如何保证(看好像没有使用事务了,但有ACK以及处理pending-list)
3.判断完了一人一单和超卖,下单更新数据库时再次查询库存是否充足以及乐观锁和分布式锁是不是没有必要了
4.项目中遇到的困难(想说滚动分页查询但是源码还是有BUG的怕给自己挖坑)
5.最严重的一个问题,为什么要用mq,用线程池不是一样吗,不是分布式,生产方和消费方在自己的服务上进行消费吗?
兄弟们看下我的最新动态帮我选下offer吧,非常感谢
全部评论
个人猜想:
1、bitmap 设置用户id 偏移位为1
2、db 减库存和创建订单肯定是在事务里。但 cache 和 db 的一致用消息确认+重试+订单号唯一幂等保证。不过其实也可以不处理,对应的场景就是少卖,给用户提示没抢到就行,而且商家在提示曝光率的同时减少了优惠券的损失。
3、兜底,万一 mq 消费完没来得及回复 ack 挂掉了,下次还消费就有重复消费问题
我也被问过,1.哈希分片,2.就是事务,3.没明白你的意思 4.我被问到答的就是这个分布式锁这一块 其他的感觉没啥意思 我还被问到视频记录哪里 哪里他会问你有没有更好的方案,但是他没说
乐观锁解决超卖,分布式锁实现一人一单,查询库存充足是兜底操作吧🤔
分页查询不用MyBatis一样做😂
第一个问题redis的set可以确保一个内容的点赞收藏只会进行一次
mq是有必要的,如果使用线程池的话,那不是每来一个message都要拿一个新的线程来处理?用了mq就可以让一个线程一直等待处理获取到的message
点评项目很多方案都是假设分布式、高并发场景的
3我觉得确实没必要了
m
m
m
相关推荐
老衲法力无边:是的,借助数据库update的行锁是悲观锁,并没有用到版本号之类的机制
点赞 评论 收藏
分享
点赞 评论 收藏
分享
10-13 09:53
广东海洋大学 Java 今天卖鱼没:权限体系和用户体系差不多就这样,我感觉讲的比较清楚了,但可能有同学没接触过有些地方可能不太清楚,我后面讲一下这两块数据库表的必要关键字段设计,就能了解它们是怎么串起来了
点赞 评论 收藏
分享