我在弹幕推送系统中为什么用RocketMQ?

为什么选择消息队列

在学校的软件实验室接过一个项目，是一个商业性的视频弹幕系统，对性能有一定的要求，我负责做视频上传存储、点赞关注和弹幕推送等功能。

因为考虑到大存储量和用户量，选择了FastDFS分布式文件存储，并且技术设计上配合前端采用分片上传、使用Redis来断点续传和秒传。

关注和弹幕推送选择了消息队列来实现，主要考虑有以下几点：

• 消息队列的发布-订阅模式。如果是传统的队列模式，一个队列中，一个生产者对应一个消费者，但是如果一个生产者对应多个消费者（就像关注功能，一个被关注者对应多个关注者），可能要复制队列，这对资源是一种损耗。所以为了更好地实现关注功能，是选择消息队列的一个重要原因，因为消息队列的机制，在RocketMQ中有"主题"的概念，生产者可以将消息推送到这个主题中，多个消费者可以订阅这个主题进行消费。
• 消息队列的异步和削峰。最为明显的是弹幕推送功能，比如我们点开一个视频，系统会将关于这个视频的所有弹幕，推送给所有正在观看的用户，而发送一条弹幕后，首先会请求服务器存入数据库中，又会从数据库中查询出所有的弹幕，推送给所有用户。一次前端请求，对于后端数据库是两次的IO处理，如果是大用户量，后端承受的压力更大。所以采用消息队列，我们一可以异步（不至于发生阻塞让用户长时间等待）、二又可以削峰（消息队列尽可能来处理，可以处理得慢一点，但是不能把服务器打挂）。
• 消息队列的解耦。消息队列主要用于消息的传输和通信，比如关注功能会用到这个用户的信息，弹幕推送也会用到用户的消息，未来可能还会开发视频推送功能，也会用到消息。如果我们把这些功能都写到一个模块中，增加和减少功能，代码都要改不少处。所以我们可以用消息队列把消息模块解耦出来，比如关注完，将信息存入消息队列后就直接返回，不管弹幕推送和视频推送怎样处理，这是"下游"的事儿。

这是为什么采用消息队列的思考。主流的消息队列有很多，比如RabbitMQ、RocketMQ、Kafka等，为什么我用了RocketMQ呢？

为什么选择RocketMQ

我最看中的一点是RocketMQ是从阿里内部开源的产品，也是Apache的顶级开源项目。历经淘宝、天猫双十一流量高峰的考验，可靠性也很强，所以商业化、高并发、互联网、金融的项目，用RocketMQ是完全可以的。

RabbitMQ的性能也还行（但是吞吐量比RocketMQ和Kafka低一个数量级），但是RabbitMQ是基于Erlang开发的，不利于做二次开发和维护，但是Erlang语言本身有并发的优势，如果数据量不大，小公司可以优先采用RabbitMQ。

Kafka更适合大数据领域的实时计算和日志采集，但是有一点劣势是消息可能会重复消费。