网易云音乐评论模块高并发下的设计思考

主要讨论的功能 (基于高流量高并发的场景)

• 评论资源
• 评论总数的更新
• 评论点赞
• 精彩评论的读取

评论表设计(简约版)

这是资源通用的表设计

高并发下的问题

1. 热点数据并发量极高
2. 评论的新增，更新CommentResource的评论总数，存在并发问题
3. 评论的点赞数也是同样的问题

四大业务模块详解

1. 评论发表，如下图
   
   通过异步化的操作，来解决行锁竞争给核心资源MYSQL带来压力，保证系统平稳平滑。
   在异步化的场景下，同时带来的问题
   1、评论的有序性质: 评论的发布本周没有逻辑上的有序，最终展示通过发表时间排序即可
   2、消息的幂等性处理: 系统网络的波动，非幂等性会带来一次评论产生多条评论的问题(消息中间件保证消息的可靠，需要有消息的重复来牺牲)
   3、消息延迟: 有消息队列存在，必定会存在消息一点的延迟。通常来说秒级别的延迟，对于用户来说是可接受的范围。同样在客户端上，可对用户进行提前露出的功能，发完，客户端直接先展示

2、计数问题：评论的添加与资源上评论数的新增
解决方案: 通过将发表评论和更新评论数放在一个事务中，保证这两步的原子性。

3、评论点赞功能
1. 评论点赞同样适用异步化消息去实现。最主要的，此时消息是需要有序性的。kafka根据特定的key（如用户id），进行同分片的分发保证消息的有序性
2. 消息消费端，同样进行单线程消费
3. 点赞次数限制，客户端进行点赞次数的限制

4、精彩评论的读取（采用多级缓存、资源动静分离）