主要讨论的功能 (基于高流量高并发的场景)
- 评论资源
- 评论总数的更新
- 评论点赞
- 精彩评论的读取
评论表设计(简约版)
这是资源通用的表设计
高并发下的问题
- 热点数据并发量极高
- 评论的新增,更新CommentResource的评论总数,存在并发问题
- 评论的点赞数也是同样的问题
四大业务模块详解
- 评论发表,如下图
通过异步化的操作,来解决行锁竞争给核心资源MYSQL带来压力,保证系统平稳平滑。
在异步化的场景下,同时带来的问题
1、评论的有序性质: 评论的发布本周没有逻辑上的有序,最终展示通过发表时间排序即可
2、消息的幂等性处理: 系统网络的波动,非幂等性会带来一次评论产生多条评论的问题(消息中间件保证消息的可靠,需要有消息的重复来牺牲)
3、消息延迟: 有消息队列存在,必定会存在消息一点的延迟。通常来说秒级别的延迟,对于用户来说是可接受的范围。同样在客户端上,可对用户进行提前露出的功能,发完,客户端直接先展示
2、计数问题:评论的添加与资源上评论数的新增
解决方案: 通过将发表评论和更新评论数放在一个事务中,保证这两步的原子性。
3、评论点赞功能
1. 评论点赞同样适用异步化消息去实现。最主要的,此时消息是需要有序性的。kafka根据特定的key(如用户id),进行同分片的分发保证消息的有序性
2. 消息消费端,同样进行单线程消费
3. 点赞次数限制,客户端进行点赞次数的限制
4、精彩评论的读取(采用多级缓存、资源动静分离)