我在弹幕推送系统中为什么用RocketMQ?
为什么选择消息队列
在学校的软件实验室接过一个项目，是一个商业性的视频弹幕系统，对性能有一定的要求，我负责做视频上传存储、点赞关注和弹幕推送等功能。
因为考虑到大存储量和用户量，选择了FastDFS分布式文件存储，并且技术设计上配合前端采用分片上传、使用Redis来断点续传和秒传。
关注和弹幕推送选择了消息队列来实现，主要考虑有以下几点：
- 消息队列的发布-订阅模式。如果是传统的队列模式，一个队列中，一个生产者对应一个消费者，但是如果一个生产者对应多个消费者（就像关注功能，一个被关注者对应多个关注者），可能要复制队列，这对资源是一种损耗。所以为了更好地实现关注功能，是选择消息队列的一个重要原因，因为消息队列的机制，在RocketMQ中有"主题"的概念，生产者可以将消息推送到这个主题中，多个消费者可以订阅这个主题进行消费。
- 消息队列的异步和削峰。最为明显的是弹幕推送功能，比如我们点开一个视频，系统会将关于这个视频的所有弹幕，推送给所有正在观看的用户，而发送一条弹幕后，首先会请求服务器存入数据库中，又会从数据库中查询出所有的弹幕，推送给所有用户。一次前端请求，对于后端数据库是两次的IO处理，如果是大用户量，后端承受的压力更大。所以采用消息队列，我们一可以异步（不至于发生阻塞让用户长时间等待）、二又可以削峰（消息队列尽可能来处理，可以处理得慢一点，但是不能把服务器打挂）。
- 消息队列的解耦。消息队列主要用于消息的传输和通信，比如关注功能会用到这个用户的信息，弹幕推送也会用到用户的消息，未来可能还会开发视频推送功能，也会用到消息。如果我们把这些功能都写到一个模块中，增加和减少功能，代码都要改不少处。所以我们可以用消息队列把消息模块解耦出来，比如关注完，将信息存入消息队列后就直接返回，不管弹幕推送和视频推送怎样处理，这是"下游"的事儿。
...大约 3 分钟