各种队列应用场景架构设计理论篇

RabbitMQ
是使用Erlang编写的一个开源的消息队列&＃xff0c;本身支持很多的协议&＃xff1a;AMQP&＃xff0c;XMPP, SMTP, STOMP&＃xff0c;也正是如此&＃xff0c;使的它变的非常重量级&＃xff0c;更适合于企业级的开发。同时实现了一个经纪人(Broker)构架&＃xff0c;这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)&＃xff0c;负载均衡(Load balance)或者数据持久化都有很好的支持。

Redis
是一个Key-Value的NoSQL数据库&＃xff0c;开发维护很活跃&＃xff0c;虽然它是一个Key-Value数据库存储系统&＃xff0c;但它本身支持MQ功能&＃xff0c;所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作&＃xff0c;各执行100万次&＃xff0c;每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明&＃xff1a;入队时&＃xff0c;当数据比较小时Redis的性能要高于RabbitMQ&＃xff0c;而如果数据大小超过了10K&＃xff0c;Redis则慢的无法忍受&＃xff1b;出队时&＃xff0c;无论数据大小&＃xff0c;Redis都表现出非常好的性能&＃xff0c;而RabbitMQ的出队性能则远低于Redis。

ZeroMQ
号称最快的消息队列系统&＃xff0c;尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列&＃xff0c;但是开发人员需要自己组合多种技术框架&＃xff0c;技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式&＃xff0c;你不需要安装和运行一个消息服务器或中间件&＃xff0c;因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库&＃xff0c;可以使用NuGet安装&＃xff0c;然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列&＃xff0c;也就是说如果down机&＃xff0c;数据将会丢失。其中&＃xff0c;Twitter的Storm中使用ZeroMQ作为数据流的传输。

ActiveMQ
是Apache下的一个子项目。 类似于ZeroMQ&＃xff0c;它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ&＃xff0c;它少量代码就可以高效地实现高级应用场景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C&＃43;&＃43;、Java、.Net,、Python、 Php、 Ruby等。

Jafka/Kafka
Kafka是Apache下的一个子项目&＃xff0c;是一个高性能跨语言分布式Publish/Subscribe消息队列系统&＃xff0c;而Jafka是在Kafka之上孵化而来的&＃xff0c;即Kafka的一个升级版。具有以下特性&＃xff1a;快速持久化&＃xff0c;可以在O(1)的系统开销下进行消息持久化&＃xff1b;高吞吐&＃xff0c;在一台普通的服务器上既可以达到10W/s的吞吐速率&＃xff1b;完全的分布式系统&＃xff0c;Broker、Producer、Consumer都原生自动支持分布式&＃xff0c;自动实现复杂均衡&＃xff1b;支持Hadoop数据并行加载&＃xff0c;对于像Hadoop的一样的日志数据和离线分析系统&＃xff0c;但又要求实时处理的限制&＃xff0c;这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理&＃xff0c;这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统&＃xff0c;除了性能非常好之外&＃xff0c;还是一个工作良好的分布式系统。

rabbitmq比kafka可靠&＃xff0c;kafka更适合IO高吞吐的处理&＃xff0c;比如ELK日志收集**
Kafka和RabbitMq一样是通用意图消息代理&＃xff0c;他们都是以分布式部署为目的。但是他们对消息语义模型的定义的假设是非常不同的。我对”AMQP 更成熟”这个论点是持怀疑态度的。让我们用事实说话来看看用什么解决方案来解决你的问题。
　　a) 以下场景你比较适合使用Kafka。你有大量的事件(10万以上/秒)、你需要以分区的&＃xff0c;顺序的&＃xff0c;至少传递成功一次到混杂了在线和打包消费的消费者、你希望能重读消息、你能接受目前是有限的节点级别高可用或则说你并不介意通过论坛/IRC工具得到还在幼儿阶段的软件的支持。
　　b) 以下场景你比较适合使用RabbitMQ。你有较少的事件&＃xff08;2万以上/秒&＃xff09;并且需要通过复杂的路由逻辑去找到消费者、你希望消息传递是可靠的、你并不关心消息传递的顺序、你需要现在就支持集群-节点级别的高可用或则说你需要7*24小时的付费支持&＃xff08;当然也可以通过论坛/IRC工具&＃xff09;。

redis 消息推送&＃xff08;基于分布式 pub/sub&＃xff09;多用于实时性较高的消息推送&＃xff0c;并不保证可靠。
redis 消息推送&＃xff08;基于分布式 pub/sub&＃xff09;多用于实时性较高的消息推送&＃xff0c;并不保证可靠。其他的mq和kafka保证可靠但有一些延迟&＃xff08;非实时系统没有保证延迟&＃xff09;。redis-pub/sub断电就清空&＃xff0c;而使用redis-list作为消息推送虽然有持久化&＃xff0c;但是又太弱智&＃xff0c;也并非完全可靠不会丢。另外一点&＃xff0c;redis 发布订阅除了表示不同的 topic 外&＃xff0c;并不支持分组&＃xff0c;比如kafka中发布一个东西&＃xff0c;多个订阅者可以分组&＃xff0c;同一个组里只有一个订阅者会收到该消息&＃xff0c;这样可以用作负载均衡。比如&＃xff0c;kafka 中发布&＃xff1a;topic &＃61; “发布帖子” data&＃61;”文章1” 这个消息&＃xff0c;后面有一百台服务器每台服务器都是一个订阅者&＃xff0c;都订阅了这个 topic&＃xff0c;但是他们可能分为三组&＃xff0c;A组50台&＃xff0c;用来真的做发布文章&＃xff0c;A组50台里所有 subscriber 都订阅了这个topic。由于在同一组&＃xff0c;这条消息 &＃xff08;topic&＃61;”发布帖子”, data&＃61;”文章1”&＃xff09;只会被A组里面一台当前空闲的机器收到。而B组25台服务器用于统计&＃xff0c;C组25台服务器用于存档备份&＃xff0c;每组只有一台会收到。用不同的组来决定每条消息要抄送出多少分去&＃xff0c;用同组内哪些订阅者忙&＃xff0c;哪些订阅者空闲来决定消息会被分到哪台服务器去处理&＃xff0c;生产者消费者模型嘛。redis完全没有这类机制&＃xff0c;这两点是最大的区别。

redis是内存数据库&＃xff01;redis他爹做了disque&＃xff0c;你要不要试试。mq一般都采用订阅&＃xff5e;发布模型&＃xff0c;如果你考虑性能&＃xff0c;主要关注点就放在消费模型是pull还是push。影响最大的&＃xff0c;应该是存储结构。kafka的性能要在topic数量小于64的时候&＃xff0c;才能发挥威力。partition决定的。极限情况下丢消息&＃xff0c;例如&＃xff1a;主写入消息后&＃xff0c;主机器宕机&＃xff0c;并硬盘损坏。review代码的时候发现的。rabbit不知道&＃xff0c;但是rocket的性能是&＃xff08;万条每秒&＃xff09;&＃xff0c;并且能够横向无限扩展&＃xff0c;单机topic数量在256时&＃xff0c;性能损失较小。rocket可以说是kafka的变种&＃xff0c;是阿里在充分reviewkafka代码后&＃xff0c;开发的metaQ。在不断更新&＃xff0c;修补以后&＃xff0c;阿里把metaQ3.0更名为rocket&＃xff0c;并且rocket是java写的易于维护。另外就是rocket和kafka有类似无限堆积的能力。想想&＃xff0c;断电不丢消息&＃xff0c;积压两亿条消息毫无压力&＃xff0c;niubilitykafka和rocket性能根本不是你需要考虑的问题。

在应用场景方面&＃xff0c;
RabbitMQ,遵循AMQP协议&＃xff0c;由内在高并发的erlanng语言开发&＃xff0c;用在实时的对可靠性要求比较高的消息传递上。

kafka是Linkedin于2010年12月份开源的消息发布订阅系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。

在架构模型方面&＃xff0c;
RabbitMQ遵循AMQP协议&＃xff0c;RabbitMQ的broker由Exchange,Binding,queue组成&＃xff0c;其中exchange和binding组成了消息的路由键&＃xff1b;客户端Producer通过连接channel和server进行通信&＃xff0c;Consumer从queue获取消息进行消费&＃xff08;长连接&＃xff0c;queue有消息会推送到consumer端&＃xff0c;consumer循环从输入流读取数据&＃xff09;。rabbitMQ以broker为中心&＃xff1b;有消息的确认机制。

kafka遵从一般的MQ结构&＃xff0c;producer&＃xff0c;broker&＃xff0c;consumer&＃xff0c;以consumer为中心&＃xff0c;消息的消费信息保存的客户端consumer上&＃xff0c;consumer根据消费的点&＃xff0c;从broker上批量pull数据&＃xff1b;无消息确认机制。

在吞吐量&＃xff0c;
kafka具有高的吞吐量&＃xff0c;内部采用消息的批量处理&＃xff0c;zero-copy机制&＃xff0c;数据的存储和获取是本地磁盘顺序批量操作&＃xff0c;具有O(1)的复杂度&＃xff0c;消息处理的效率很高。

rabbitMQ在吞吐量方面稍逊于kafka&＃xff0c;他们的出发点不一样&＃xff0c;rabbitMQ支持对消息的可靠的传递&＃xff0c;支持事务&＃xff0c;不支持批量的操作&＃xff1b;基于存储的可靠性的要求存储可以采用内存或者硬盘。

在可用性方面&＃xff0c;
rabbitMQ支持miror的queue&＃xff0c;主queue失效&＃xff0c;miror queue接管。

kafka的broker支持主备模式。

在集群负载均衡方面&＃xff0c;
kafka采用zookeeper对集群中的broker、consumer进行管理&＃xff0c;可以注册topic到zookeeper上&＃xff1b;通过zookeeper的协调机制&＃xff0c;producer保存对应topic的broker信息&＃xff0c;可以随机或者轮询发送到broker上&＃xff1b;并且producer可以基于语义指定分片&＃xff0c;消息发送到broker的某分片上。

rabbitMQ的负载均衡需要单独的loadbalancer进行支持。

Kafka是可靠的分布式日志存储服务。用简单的话来说&＃xff0c;你可以把Kafka当作可顺序写入的一大卷磁带&＃xff0c; 可以随时倒带&＃xff0c;快进到某个时间点重放。先说下日志的定义&＃xff1a;日志是数据库的核心&＃xff0c;是对数据库的所有变更的严格有序记录&＃xff0c;“表”是变更的结果。日志的其他名字有&＃xff1a; Changelog, Write Ahead Log, Commit Log, Redo Log, Journaling.Kafka的特征如下&＃xff1a;高写入速度&＃xff1a;Kafka能以超过1Gbps NIC的速度写这盘磁带&＃xff08;实际可以到SATA 3速度&＃xff0c;参考Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines))&＃xff0c;充分利用了磁盘的物理特性&＃xff0c;即&＃xff0c;随机写入慢&＃xff08;磁头冲停&＃xff09;&＃xff0c;顺序写入快&＃xff08;磁头悬浮&＃xff09;。高可靠性&＃xff1a; 通过zookeeper做分布式一致性&＃xff0c;同步到任意多块磁盘上&＃xff0c;故障自动切换选主&＃xff0c;自愈。高容量&＃xff1a;通过横向扩展&＃xff0c;LinkedIn每日通过Kafka存储的新增数据高达175TB&＃xff0c;8000亿条消息&＃xff0c;可无限扩容&＃xff0c;类似把两条磁带粘到一起。传统业务数据库的根本缺陷在于&＃xff1a;1. 太慢&＃xff0c;读写太昂贵&＃xff0c;无法避免的随机寻址。&＃xff08;磁盘最快5ms寻址&＃xff0c;固态又太昂贵。&＃xff09;2. 根本无法适应持续产生的数据流&＃xff0c;越用越慢。&＃xff08;索引效率问题&＃xff09;3. 无法水平scale。&＃xff08;多半是读写分离&＃xff0c;一主多备。另: NewSQL通过一致性算法&＃xff0c;有多主。&＃xff09;针对这些问题&＃xff0c;Kafka提出了一种方法: “log-centric approach&＃xff08;以日志为中心的方法&＃xff09;。”将传统数据库分为两个独立的系统&＃xff0c;即日志系统和索引系统。“持久化和索引分开&＃xff0c;日志尽可能快的落地&＃xff0c;索引按照自己的速度追赶。”在数据可靠性在得到Kafka这种快速的&＃xff0c;类似磁带顺序记录方式保障的大前提下。数据的呈现&＃xff0c;使用方式变得非常灵活&＃xff0c;可以根据需要将数据流同时送入搜索系统&＃xff0c;RDBMS系统&＃xff0c;数据仓库系统&＃xff0c; 图数据库系统&＃xff0c;日志分析等这些各种不同的数据库系统。 这些不同的系统只不过是一种对Kafka磁带数据的一种诠释&＃xff0c;一个侧面&＃xff0c;一个索引&＃xff0c;一个快照。数据丢了&＃xff0c;没关系&＃xff0c;重放一遍磁带即可&＃xff0c;更多的时候&＃xff0c;对这些各式数据库系统的维护只是需要定期做一个快照&＃xff0c;并拷贝到一个安全的对象存储(如S3) 而已。 一句话&＃xff1a;“日志都是相同的日志&＃xff0c;索引各有各的不同。”关于流计算&＃xff1a;在以流为基本抽象的存储模型下&＃xff0c;数据流和数据流之间&＃xff0c;可以多流混合处理&＃xff0c;或者流和状态&＃xff0c;状态和状态的JOIN处理&＃xff0c;这就是Kafka Stream提供的功能。 一个简单的例子是&＃xff0c;在用户触发了某个事件后&＃xff0c;和用户表混合处理&＃xff0c;产生数据增补&＃xff08;Augment)&＃xff0c;再进入数据仓库进行相关性分析&＃xff0c;一些简单的窗口统计和实时分析也很容易就能满足&＃xff0c;比如 在收到用户登录消息的时候&＃xff0c;在线人数&＃43;1&＃xff0c; 离线的时候-1&＃xff0c;反应出当前系统的在线用户总数。这方面可以参考PipelineDB https://www.pipelinedb.com/Kafka会让你重新思考系统的构建方式&＃xff0c;使以前不可能的事变为可能&＃xff0c;是一个系统中最重要的最核心的部分&＃xff0c;不夸张的说&＃xff0c;系统设计都需要围绕Kafka做。
————————————————
版权声明&＃xff1a;本文为CSDN博主「码农博士」的原创文章&＃xff0c;遵循CC 4.0 BY-SA版权协议&＃xff0c;转载请附上原文出处链接及本声明。
原文链接&＃xff1a;https://blog.csdn.net/belvine/article/details/80842240