本文共 2676 字,大约阅读时间需要 8 分钟。
Kafka(高吞吐:十万级。延迟:毫秒级别)
Kafka是LinkedIn开源的分布式发布-订阅消息系统,目前归属于Apache顶级项目。Kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量(十万级),一开始的目的就是用于日志收集和传输。0.8版本开始支持复制,不支持事务,对消息的重复、丢失、错误没有严格要求,适合产生大量数据的互联网服务的数据收集业务。
RabbitMQ(低延迟:微妙级别。万级吞吐)
RabbitMQ是使用Erlang语言开发的开源消息队列系统,基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。AMQP协议更多用在企业系统内,对数据一致性、稳定性和可靠性要求很高的场景,对性能和吞吐量(万级)的要求还在其次。
RocketMQ(十万级吞吐,毫秒)
RocketMQ是阿里开源的消息中间件,它是纯Java开发,具有高吞吐量(十万级)、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka,但并不是Kafka的一个Copy,它对消息的可靠传输及事务性做了优化,目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。
1 异步通信
有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。
2 解耦
降低工程间的强依赖程度,针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求,是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口,当应用发生变化时,可以独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。
3 冗余
有些情况下,处理数据的过程会失败。除非数据被持久化,否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。
4 扩展性
因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。
5 过载保护
在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量无法提取预知;如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。
6 可恢复性
系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。
7 顺序保证
在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。
8 缓冲
在任何重要的系统中,都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行,该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。
9 数据流处理
分布式系统产生的海量数据流,如:业务日志、监控数据、用户行为等,针对这些数据流进行实时或批量采集汇总,然后进行大数据分析是当前互联网的必备技术,通过消息队列完成此类数据收集是最好的选择。
Rabbitmq比kafka可靠,kafka更适合IO高吞吐的处理,比如ELK日志收集
适用于kafka的场景:大量的事件(10万以上/秒)、你需要以分区的,顺序的,至少传递成功一次到混杂了在线和打包消费的消费者、你希望能重读消息、你能接受目前是有限的节点级别高可用或则说你并不介意通过论坛/IRC工具得到还在幼儿阶段的软件的支持。
适用于rabbitMQ的场景较少的事件(2万以上/秒)并且需要通过复杂的路由逻辑去找到消费者、你希望消息传递是可靠的、你并不关心消息传递的顺序、你需要现在就支持集群-节点级别的高可用或则说你需要7*24小时的付费支持(当然也可以通过论坛/IRC工具)。
RabbitMQ是使用Erlang编写的消息队列,采用AMQP协议传输
特性:
信道是建立在真实的TCP连接内的虚拟连接。AMQP的命令都是通过信道发送出去的,每条信道都会被指派一个唯一ID。一个TCP连接,对应多个信道,理论上无限制,减少TCP创建和销毁的开销,实现共用TCP的效果
数据流动都是通过Channel来进行的不用tcp的原因在于:频繁的建立关闭TCP连接对于系统的性能有很大的影响。
每一个vhost可以理解为一个RabbitMQ服务器里的一个东东,同一个mq服务器里可以有很多这个东东,拥有自己的队列、交换器、绑定、权限机制,一个broker(一个mq的节点)可以有多个vhost。
1、headers交换器:允许匹配AMQP消息的header而非路由键
2、direct交换器:路由键匹配,消息就被投递到对应的队列
3、fanout交换器:会将收到的消息广播到绑定的队列上
4、topic交换器:使来自不同源头的消息能够到达同一个队列
1、推模式:通过AMQP的basic.consume命令订阅,有消息会自动接收,吞吐量高
2、拉模式:通过AMQP的bsaic.get命令
注:当队列拥有多个消费者时,队列收到的消息将以循环的方式发送给消费者。每条消息只会发送给一个订阅的消费者
开启持久化功能,需同时满足:消息投递模式选择持久化、交换器开启持久化、队列开启持久化
1、发送方确认模式:消息发送到交换器–发送完毕–>消息投递到队列或持久化到磁盘异步回调通知生产者
2、消费者确认机制:消息投递消费者-ack-删除该条消息-投递下一条
注:收到ACK前,不会把消息再次发送给该消费者,但是会把下一条消息发送给其他消费者
1、断开连接,消息重新入队,发送给下一个消费者
2、reject命令,根据参数确定消息重新入队还是丢弃
转载地址:http://dcqbb.baihongyu.com/