-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
152d77b
commit 7d7c000
Showing
1 changed file
with
34 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
--- | ||
date: 2023-12-2 | ||
category: | ||
- 项目设计 | ||
tag: | ||
- MQ | ||
- 技术选型 | ||
--- | ||
|
||
# 我在弹幕推送系统中为什么用RocketMQ? | ||
|
||
## 为什么选择消息队列 | ||
|
||
在学校的软件实验室接过一个项目,是一个商业性的视频弹幕系统,对性能有一定的要求,我负责做视频上传存储、点赞关注和弹幕推送等功能。 | ||
|
||
因为考虑到大存储量和用户量,选择了FastDFS分布式文件存储,并且技术设计上配合前端采用分片上传、使用Redis来断点续传和秒传。 | ||
|
||
关注和弹幕推送选择了消息队列来实现,主要考虑有以下几点: | ||
|
||
- 消息队列的发布-订阅模式。如果是传统的队列模式,一个队列中,一个生产者对应一个消费者,但是如果一个生产者对应多个消费者(就像关注功能,一个被关注者对应多个关注者),可能要复制队列,这对资源是一种损耗。所以为了更好地实现关注功能,是选择消息队列的一个重要原因,因为消息队列的机制,在RocketMQ中有"主题"的概念,生产者可以将消息推送到这个主题中,多个消费者可以订阅这个主题进行消费。 | ||
- 消息队列的异步和削峰。最为明显的是弹幕推送功能,比如我们点开一个视频,系统会将关于这个视频的所有弹幕,推送给所有正在观看的用户,而发送一条弹幕后,首先会请求服务器存入数据库中,又会从数据库中查询出所有的弹幕,推送给所有用户。一次前端请求,对于后端数据库是两次的IO处理,如果是大用户量,后端承受的压力更大。所以采用消息队列,我们一可以异步(不至于发生阻塞让用户长时间等待)、二又可以削峰(消息队列尽可能来处理,可以处理得慢一点,但是不能把服务器打挂)。 | ||
- 消息队列的解耦。消息队列主要用于消息的传输和通信,比如关注功能会用到这个用户的信息,弹幕推送也会用到用户的消息,未来可能还会开发视频推送功能,也会用到消息。如果我们把这些功能都写到一个模块中,增加和减少功能,代码都要改不少处。所以我们可以用消息队列把消息模块解耦出来,比如关注完,将信息存入消息队列后就直接返回,不管弹幕推送和视频推送怎样处理,这是"下游"的事儿。 | ||
|
||
这是为什么采用消息队列的思考。主流的消息队列有很多,比如RabbitMQ、RocketMQ、Kafka等,为什么我用了RocketMQ呢? | ||
|
||
## 为什么选择RocketMQ | ||
|
||
我最看中的一点是RocketMQ是从阿里内部开源的产品,也是Apache的顶级开源项目。历经淘宝、天猫双十一流量高峰的考验,可靠性也很强,所以商业化、高并发、互联网、金融的项目,用RocketMQ是完全可以的。 | ||
|
||
RabbitMQ的性能也还行(但是吞吐量比RocketMQ和Kafka低一个数量级),但是RabbitMQ是基于Erlang开发的,不利于做二次开发和维护,但是Erlang语言本身有并发的优势,如果数据量不大,小公司可以优先采用RabbitMQ。 | ||
|
||
Kafka更适合大数据领域的实时计算和日志采集,但是有一点劣势是消息可能会重复消费。 | ||
|
||
|