您好,欢迎来到12图资源库!分享精神,快乐你我!我们只是素材的搬运工!!
  • 首 页
  • 当前位置:首页 > 开发 > WEB开发 >
    微效劳音讯代理选型:Redis、Kafka、RabbitMQ
    时间:2021-08-30 12:10 来源:网络整理 作者:网络 浏览:收藏 挑错 推荐 打印

    微效劳音讯代理选型:Redis、Kafka、RabbitMQ

    在为微效劳运用异步通讯时,通常运用音讯代理。代理确保不同微效劳之间的通讯牢靠波动,音讯在系统内失掉管理和监控,并且音讯不会丧失。您可以从几个音讯代理中选择,它们的规模和数据功用各不相反。这篇博文将比较三个最受欢迎的代理brokers:RabbitMQ、 Kafka 和 Redis 。

    但首先,让我们了解一下微效劳通讯。

    微效劳通讯:同步和异步

    微效劳之间有两种常见的通讯方式:同步和异步。在同步通讯中,调用方在发送下一条音讯之前等候照应,它作为HTTP之上的REST协议运转。相反,在异步通讯中,音讯是在不等候照应的状况下发送的。这适用于散布式系统,通常需求音讯代理来管理音讯。

    您选择的通讯类型应思索不同的参数,如如何结构微效劳、设置什么基础设备、延迟、规模、依赖性和通讯目的。异步通讯的树立能够愈加复杂,并且需求向堆栈中添加更多的组件,但是将异步通讯誉于微效劳的优点大于缺陷。

    异步通讯优势

    首先也是最重要的是,异步通讯从定义上讲是无阻塞的。它还支持比同步操作更好的扩展。第三,在微效劳崩溃的状况下,异步通讯机制提供了各种恢复技术,通常更好地处置与崩溃相关的错误。此外,当运用代理而不是REST协议时,接纳通讯的效劳虚际上不需求相互了解。甚至可以在旧效劳运转很长时间后引入新效劳,即更好的解耦效劳。

    最后,在选择异步操作时,您可以提高未来创立中心发现、监视、负载平衡甚至策略实施器的才能。这将为您的代码和系统构建提供灵敏性、可伸缩性和更多功用。

    选择正确的音讯代理

    异步通讯通常经过音讯代理停止管理。还有其他办法,比如aysncio,但它们更为稀缺和有限。

    在选择执行异步操作的代理时,应思索以下几点:

    1. Broker Scale–系统中每秒发送的音讯数。

    2. 数据耐久性–恢复音讯的才能。

    3. 消费者才能–brokers能否可以管理一对一和/或一对多消费者。

    一对一:

    微效劳音讯代理选型:Redis、Kafka、RabbitMQ

    一对多:

    微效劳音讯代理选型:Redis、Kafka、RabbitMQ

    我们查看了最新和最好的效劳,以找出这三个类别中哪家提供商最强。

    比较不同的音讯代理 RabbitMQ(AMQP)

    规模:依据配置和资源,这里的大约速度约为每秒50K味精。

    耐久化:支持耐久性和暂时性音讯。

    一对一vs一对多消费者:两者皆有。

    RabbitMQ于2007年发布,是首批创立的通用音讯代理之一。它是一个开源软件,经过完成初级音讯队列协议(AMQP),经过点对点和发布子办法来传递音讯。它旨在支持复杂的路由逻辑。

    有一些托管效劳允许您将其用作SaaS,但它不是本机主要云提供商堆栈的一部分。RabbitMQ支持一切主要言语,包括Python、Java、.NET、PHP、Ruby、JavaScript、Go、Swift等。

    在耐久形式下能够会出现一些功用成绩。

    Kafka

    规模:每秒最多可发送数百万条音讯。

    耐久化:是的。

    一对一vs一对多消费者:只要一对多(乍一看似乎很奇异,对吧?!)。

    Kafka由Linkedin于2011年创立,用于处置高吞吐量、低延迟的处置。作为一个散布式流媒体平台,Kafka复制了发布-订阅效劳。它提供数据耐久性并存储记载流,使其可以交流高质量的音讯。

    Kafka在Azure、AWS和Confluent上管理SaaS。他们都是Kafka方案的发明者和主要贡献者。Kafka支持一切主要言语,包括Python、Java、C/C++、Clojure、.NET、PHP、Ruby、JavaScript、Go、Swift等。

    Redis

    规模:每秒最多可发送一百万条音讯。

    耐久化:基本上不是——它是内存中的数据存储。

    一对一vs一对多消费者:两者皆有。

    Redis与其他音讯代理稍有不同。Redis的中心是内存中的数据存储,可以用作高功用键值存储或音讯代理。另一个区别是Redis没有耐久性,而是将其内存转储到磁盘/DB中。它也十分适宜实时数据处置。

    最后,Redis不是一对一和一对多。但是,自从Redis 5.0推出pub-sub以来,功用失掉了提升,一对多成为了一种理想选择。

    每个用例的音讯代理

    我们引见了RabbitMQ、卡夫卡和Redis的一些特性。这三种植物都属于这一类,但如上所述,它们的运作方式一模一样。下面是我们依据不同的用例为正确的MessageBroker提供的建议。

    短音讯:Redis

    Redis的内存数据库简直完全适宜于不需求耐久性的短音讯用例。由于它提供了极快的效劳和内存功用,Redis是短保留音讯的完美选择,在短保留音讯中,耐久性并不重要,您可以容忍一些损失。随着Redis streams在5.0中的发布,它也是一对多用例的候选者,这是由于限制和旧的发布订阅功用而相对需求的。

    少量数据:Kafka

    Kafka是一个高吞吐量的散布式队列,用于长时间存储少量数据。Kafka十分适宜于需求耐久性的一对多用例。

    复杂路由:RabbitMQ

    RabbitMQ是一个较老但成熟的代理,具有许多支持复杂路由的特性和功用。当所需速率不高(超过数万msg/秒)时,它甚至支持复杂的路由通讯。

    思索你的软件栈

    当然,最后要思索的是您以后的软件堆栈。假设您正在寻觅一个相对复杂的集成进程,并且不希望在堆栈中维护不同的代理,那么您能够更倾向于运用堆栈曾经支持的代理。

    例如,假设您在RabbitMQ之上的系统中运用芹菜作为义务队列,您将有动力运用RabbitMQ或Redis,而不是Kafka,后者不受支持,需求一些重写。

    【编辑引荐】

    浅谈前端开发学习与开展

    VUE技术栈精讲

    云原生技术促进产业数字化转型

    2021年批发行业的四大中心技术基础设备趋向

    PyFlink 开发环境利器:Zeppelin Notebook

    (责任编辑:admin)