MQ(message queue),从字面意思上看,本质是个队列,FIFO 先入先出,只不过队列中存放的内容是message 而已,还是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ 是一种非常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了 MQ 之后,消息发送上游只需要依赖 MQ,不用依赖其他服务。
MQ是一个中间人,只负责转发消息,MQ可以理解为是快递站,负责接收快递和分发快递,但是不负责处理快递。
服务器的访问量太大会导致服务器宕机,服务器宕机就不能对外提供服务,这对消费者来说是不友好的,我们可以使用降级熔断的方式来保护服务器,也可以使用MQ的方式来进行处理,可以将访问服务的用户放入到队列中,排队进行处理,这样的话服务器就能根据自身的处理能力来处理。
举个例子,双十一的时候客户疯狂下单,本身服务器的QPS是 1w/s,但是在高峰期假设有两万次的下单操作,那么服务器是处理不了的,这个时候就可以使用MQ来缓冲,处理完前面的再处理后面的,这样就能达到保护服务器的作用。
以电商系统为例,我们执行一个下单操作如下
应用中有订单系统、支付系统、库存系统、物流系统,如果订单系统藕合这三个系统,那么有任何一个系统出现了异常都会导致整个订单失败,如果使用消息队列来进行处理之后就会减少系统调用的问题,比如物流系统发生故障,需要一点时间来进行修复,那么由于消息是存储在队列中的,物流消息还没有被消费,那么等到物流系统修复之后就可以去消费未被消费的物流消息,这个过程用户是感知不到的,提高了系统的可用性。
应用中的一些操作的实时性不高,我们使用异步处理,比如聊天的消息,它不一定发送就马上收到,可能会延迟1秒收到,那么这个时候我们就可以使用消息队列来做这个消息转发。比如API的调用,A调用B,B处理的时间有点长,等B处理完就将消息发送给消息队列,这个时候A系统再去消费消息。
优点:单机吞吐量万级,时效性 ms 级,可用性高,基于主从架构实现高可用性,消息可靠性较低的概率丢失数据
缺点:官方社区现在对 ActiveMQ 5.x 维护越来越少,高吞吐量场景较少使用。
大数据的杀手锏,谈到大数据领域内的消息传输,则绕不开 Kafka,这款为大数据而生的消息中间件,以其百万级 TPS 的吞吐量名声大噪,迅速成为大数据领域的宠儿,在数据采集、传输、存储的过程中发挥着举足轻重的作用。目前已经被 LinkedIn,Uber, Twitter, Netflix 等大公司所采纳。
优点: 性能卓越,单机写入 TPS 约在百万条/秒,最大的优点,就是吞吐量高。时效性 ms 级可用性非常高,kafka 是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用,消费者采用 Pull 方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;有优秀的第三方Kafka Web 管理界面 Kafka-Manager;在日志领域比较成熟,被多家公司和多个开源项目使用;功能支持:功能较为简单,主要支持简单的 MQ 功能,在大数据领域的实时计算以及日志采集被大规模使用
缺点:Kafka 单机超过 64 个队列/分区,Load 会发生明显的飙高现象,队列越多,load 越高,发送消息响应时间变长,使用短轮询方式,实时性取决于轮询间隔时间,消费失败不支持重试;支持消息顺序,但是一台代理宕机后,就会产生消息乱序,社区更新较慢;
RocketMQ 出自阿里巴巴的开源产品,用 Java 语言实现,在设计时参考了 Kafka,并做出了自己的一些改进。被阿里巴巴广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理,binglog 分发等场景。
优点:单机吞吐量十万级,可用性非常高,分布式架构,消息可以做到 0 丢失,**MQ 功能较为完善,还是分布式的,扩展性好,**支持 10 亿级别的消息堆积,不会因为堆积导致性能下降,源码是 java 我们可以自己阅读源码,定制自己公司的 MQ
缺点:支持的客户端语言不多,目前是 java 及 c++,其中 c++不成熟;社区活跃度一般,没有在 MQ核心中去实现 JMS 等接口,有些系统要迁移需要修改大量代码
2007 年发布,是一个在 AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。
优点:由于 erlang 语言的高并发特性,性能较好;吞吐量到万级,MQ 功能比较完备,健壮、稳定、易用、跨平台、支持多种语言 如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等,支持 AJAX 文档齐全;开源提供的管理界面非常棒,用起来很好用,社区活跃度高;更新频率相当高
官网:https://www.rabbitmq.com/news.html
缺点:商业版需要收费,学习成本较高
Kafka 主要特点是基于 Pull 的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输,适合产生大量数据的互联网服务的数据收集业务。大型公司建议可以选用,如果有日志采集功能,肯定是首选 kafka 了。
天生为金融互联网领域而生,对于可靠性要求很高的场景,尤其是电商里面的订单扣款,以及业务削峰,在大量交易涌入时,后端可能无法及时处理的情况。RoketMQ 在稳定性上可能更值得信赖,这些业务场景在阿里双 11 已经经历了多次考验,如果你的业务有上述并发场景,建议可以选择 RocketMQ。
结合 erlang 语言本身的并发优势,性能好时效性微秒级,社区活跃度也比较高,管理界面用起来十分方便,如果你的数据量没有那么大,中小型公司优先选择功能比较完备的 RabbitMQ。
RabbitMQ 是一个消息中间件:它接受并转发消息。你可以把它当做一个快递站点,当你要发送一个包裹时,你把你的包裹放到快递站,快递员最终会把你的快递送到收件人那里,按照这种逻辑 RabbitMQ 是一个快递站,一个快递员帮你传递快件。RabbitMQ 与快递站的主要区别在于,它不处理快件而是接收,存储和转发消息数据。
Broker:接收和分发消息的应用,RabbitMQ Server 就是 Message Broker,每一个RabbitMQ实例就是一个Broker
Virtual host:出于多租户和安全因素设计的,把 AMQP 的基本组件划分到一个虚拟的分组中,类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时,可以划分出多个 vhost,每个用户在自己的 vhost 创建 exchange/queue 等
Connection:publisher/consumer 和 broker 之间的 TCP 连接
Channel:如果每一次访问 RabbitMQ 都建立一个 Connection,在消息量大的时候建立 TCP Connection 的开销将是巨大的,效率也较低。Channel 是在 connection 内部建立的逻辑连接,如果应用程序支持多线程,通常每个 thread 创建单独的 channel 进行通讯,AMQP method 包含了 channel id 帮助客户端和 message broker 识别 channel,所以 channel 之间是完全隔离的。Channel 作为轻量级的Connection 极大减少了操作系统建立 TCP connection的开销
Exchange:message 到达 broker 的第一站,根据分发规则,匹配查询表中的 routing key,分发消息到 queue 中去。常用的类型有:direct (point-to-point), topic (publish-subscribe) and fanout (multicast)
Queue:消息最终被送到这里等待 consumer 取走
Binding:exchange 和 queue 之间的虚拟连接,binding 中可以包含 routing key,Binding 信息被保存到 exchange 中的查询表中,用于 message 的分发依据
安装教程地址:https://www.rabbitmq.com/download.html
这里我们使用资源包的方式进行安装
服务器:Centos7
首先将对应的资源包上传到服务器
RabbitMQ是用Erlang语言开发的,所以需要先安装Erlang
rpm -ivh erlang-21.3-1.el7.x86_64.rpm
yum install socat -y
rpm -ivh rabbitmq-server-3.8.8-1.el7.noarch.rpm
# 卸载erlang
yum list | grep erlang
yum -y remove erlang-*
rm -rf /usr/lib64/erlang
# 卸载RabbitMQ
yum list | grep rabbitmq
yum -y remove rabbitmq-server.noarch
# 查看是否删除干净
rpm -qa | grep rabbitmq
rpm -qa | grep erlang
# 如果 rpm -qa | grep erlang 显示不为空
sudo yum remove erlang
sudo yum remove erlang-erts
sudo yum remove erlang-asn1
sudo yum remove erlang-os_mon
sudo yum remove erlang-xmerl
# 启动服务
service rabbitmq-server start
# 查看服务状态
service rabbitmq-server status
# 停止服务
service rabbitmq-server stop
# 重启服务
service rabbitmq-server restart
# 开启 web 管理插件
rabbitmq-plugins enable rabbitmq_management
# 启动应用
rabbitmqctl start_app
# 停止应用
rabbitmqctl stop_app
# 清除命令
rabbitmqctl reset
默认是有一个 guest 用户,密码也是 guest,不支持远程访问,只能本地访问,需要配置才能远程访问
sudo vi /etc/rabbitmq/rabbitmq.conf
# 添加或修改loopback_users配置项
[
{rabbit, [
{loopback_users, []}
]}
]
# 重启服务
sudo systemctl restart rabbitmq-server
###### 再次访问没有问题
# 创建账号
rabbitmqctl add_user admin 123
# 设置用户角色
rabbitmqctl set_user_tags admin administrator
# 设置用户权限
# 语法: set_permissions [-p ]
rabbitmqctl set_permissions -p "/" admin ".*" ".*" ".*"
### 用户 user_admin 具有/vhost1 这个 virtual host 中所有资源的配置、写、读权限
# 当前用户和角色
rabbitmqctl list_users