Questions tagged «message-queue»

有人可以在我应该考虑使用AMQP的哪种用例（例如RabbitMQ）中向我解释吗？优缺点都有什么？

45 design  message-queue 

我刚刚读了这篇文章，我很困惑。 假设有1个webapp和1个不同的应用程序充当“工作者”，它们共享同一个数据库。 哦，我说“分享” ..但是这篇文章警告了什么？： 第四，在应用程序（或服务）之间共享数据库是一件坏事。在其中放置无定形共享状态太诱人了，在您不知道它的情况下，您将拥有一个巨大的耦合怪物。 =>不同意。在某些情况下，不同的应用程序仍然是同一单元的一部分，因此，在这种情况下，“耦合问题”的概念毫无意义。 让我们继续：Web应用程序处理客户端HTTP请求，并可能随时更新某些聚合（DDD术语），从而生成相应的域事件。 工作人员的目标是通过处理所需的作业来处理那些域事件。 重点是： 事件数据应如何传递给工作人员？ 正如阅读的文章所提倡的那样，第一个解决方案是使用RabbitMQ，它是一款出色的面向消息的中间件。 工作流程将很简单： 每当Web dyno生成事件时，它都会通过RabbitMQ发布该事件，从而为工作人员提供帮助。 缺点是，如果不处理潜在的发送失败或硬件问题，则无法保证提交汇总更新和事件的发布之间的即时一致性。这是另一个主要问题。 示例：发布事件可能没有成功进行汇总更新...导致事件代表域模型的错误表示。 您可能会争辩说存在全局XA（两阶段提交），但这不是适合所有数据库或中间件的解决方案。 那么，什么是确保这种即时一致性的好的解决方案？： IMO，将事件存储在数据库中，并且与聚合更新在同一本地事务中。 将创建一个简单的异步调度程序，并负责从数据库查询当前未发布的事件，并将其发送到RabbitMQ，后者再填充工作程序。 但是，为什么还要在webapp端并需要一个额外的调度程序：为什么在这种情况下需要RabbitMQ？ 通过这种解决方案，在逻辑上似乎可以不需要RabbitMQ，尤其是因为数据库是共享的。 确实，无论如何，我们都看到即时一致性涉及从数据库进行轮询。 因此，为什么工人不直接对这次投票负责？ 因此，我想知道为什么网络上有那么多文章在推广面向消息的中间件时几乎没有批评数据库排队。 文章摘录： 简单，使用正确的工具完成工作：这种情况正在引起消息传递系统的注意。它解决了上述所有问题；不再需要轮询，高效的消息传递，无需从队列中清除已完成的消息以及没有共享状态。 和即时的一致性，被忽略了吗？ 综上所述，实际上无论情况如何，无论是否共享数据库，我们都需要数据库轮询。 我错过了一些批评观念吗？ 谢谢

33 architecture  domain-driven-design  message-queue  middleware 

为什么要对Redis进行排队？ 我的印象是Redis可以很好地实现排队系统。到目前为止，我们一直在使用MySQL数据库进行轮询或RabbitMQ。有了RabbitMQ，我们遇到了很多问题-客户端库非常差且存在漏洞，我们不想花费太多的开发人员时间来修复它们，也不希望在服务器管理控制台上遇到一些问题，等等。至少，我们没有掌握几毫秒，也没有认真提高性能，因此，只要系统的体系结构能够智能地支持队列，我们​​就可能处于良好状态。 好的，这就是背景。本质上，我有一个非常经典，简单的队列模型-几个生产者在生产工作，几个消费者在消费工作，生产者和消费者都需要能够智能地进行扩展。事实证明，天真PUBSUB是行不通的，因为我不希望所有订阅者都消费工作，我只希望一个订阅者可以接收工作。乍一看，在我看来，这BRPOPLPUSH是一个明智的设计。 我们可以使用BRPOPLPUSH吗？ 基本设计BRPOPLPUSH是您有一个工作队列和一个进度队列。当消费者收到工作时，它会自动将项目推送到进度队列中，而当工作完成时，它就是工作LREM了。如果客户死了，这可以防止工作混乱，并使监视工作变得很轻松-例如，我们可以判断是否存在导致消费者花费大量时间来执行任务的问题，此外还可以判断是否存在大量任务。 它确保 作品交付给了一位消费者 工作在进度队列中结束，因此如果消费者使用它，则不会出现黑洞 缺点 对于我来说，我发现的最好的设计实际上没有使用实际上是很奇怪的，PUBSUB因为这似乎是大多数有关Redis排队的博客所关注的内容。所以我觉得我缺少明显的东西。我看到PUBSUB不使用两次任务就使用的唯一方法是简单地推送一个通知，通知工作已经到达，然后消费者可以无阻塞地进行通知RPOPLPUSH。 一次请求一个以上的工作项目是不可能的，这似乎是一个性能问题。对于我们的情况而言，这不是一个很大的选择，但显然，该操作不是针对高吞吐量或这种情况而设计的 简而言之：我是否缺少任何愚蠢的东西？ 还添加了node.js标记，因为这是我最常使用的语言。考虑到Node的单线程和非阻塞性质，它可能会在实现方面提供一些简化，但是此外，我正在使用node-redis库，并且解决方案也应该或可以对其优点和缺点敏感。

29 node.js  message-queue  redis  pubsub  producer-consumer 

我正在尝试了解有关解决分布式队列问题的各种方式的更多信息。因此，我想知道已经有哪些产品，服务，实现和研究论文。 一个实现将面临许多挑战，并将被迫进行权衡： 它的订购顺序是否牢固？ 它有幂等的位置吗？ 我们是否可以拥有比一台计算机上容纳的队列更多的队列？ 队列中的数据量是否可以超过一台计算机上容纳的数据量？ 在可能丢失数据之前，有多少台计算机可能崩溃？ 它可以承受网裂吗？ 固定网络拆分后，能否自动协调数据？ 客户崩溃时能否保证交货？ 是否可以保证同一封邮件不会多次发送？ 节点是否可以在任何给定时间崩溃，重新启动并且不发出垃圾？ 您是否可以在不停机的情况下向正在运行的群集中添加节点或从中删除节点？ 您可以在不停机的情况下升级正在运行的群集中的节点吗？ 它可以在异构服务器上正常运行吗？ 您可以将队列“粘贴”到一组服务器吗？（例如：“这些队列仅在欧洲数据中心中被允许”） 如果可以的话，是否可以确保将数据副本至少放置在两个数据中心中？ 我不幻想任何实现都可以对所有这些说“是”。我只想了解各种实现；他们如何工作，进行了哪些权衡以及也许为什么要决定自己的特定权衡。 另外，如果上面的列表中我可能错过了任何挑战。

23 distributed-computing  message-queue 

我最近开始学习可伸缩和企业计算机体系结构的细微差别，其中的核心组件之一是消息传递队列。为了从任何编程范例中学到最多的知识，我试图实现自己的消息传递队列服务版本。 到目前为止，我的最初设计是在线程套接字侦听器上运行的，但是为了防止同一消息被两个单独的处理节点下载两次，消息队列索引寄存器在启动读取时被锁定，并在该寄存器被锁定后解锁。更新。这样，就不需要对其进行线程化，并且意味着基于正在运行消息传递队列服务的服务器的处理速度，可伸缩系统的大小存在上限。 解决此问题的方法是在多个服务器上运行消息队列服务，但这将增加两次下载同一条消息的可能性。防止发生此类问题的唯一方法是包括一个撤消回调（该撤消回调（在服务器甚至单个服务器上的线程已同步其信息并检测到此类重新发布之后）将命令处理节点停止其运行。当前作业，然后重新查询消息队列以获取下一条消息，但是同样，还会有一个上限，在该上限中，大多数正在发送的流量将是同步和吊销回调，从而导致瓶颈并减慢了信息处理的速度，因此许多处理节点将执行空操作并浪费时间。 我能想到的解决此问题的最后一种方法是，使每个消息队列服务器（以及每个服务器上的每个线程）在队列中查找的位置具有特定的偏移量，但这可能会基于类型的应用程序，特别是如果要求以特定顺序进行处理时。 因此，话虽这么说，是否有任何消息队列体系结构设计可以向我展示现有的企业级消息队列服务如何避免这些问题？

22 design  scalability  message-queue 

我有一个应用程序，在几个开发人员之间引起了相当激烈的讨论。 基本上，它分为Web层和后端层。Web层通过一个简单的Web表单收集信息，并将此数据作为JSON文档（字面上是.json文件）存储到后端使用的watch文件夹中。后端每隔几秒钟轮询一次该文件夹，拾取文件并执行其功能。 文件本身非常简单（即所有字符串数据，无嵌套），最大时约为1-2k，系统大部分时间都处于空闲状态（但在任何给定时间突发多达100条消息）。每个邮件的后端处理步骤大约需要10分钟。 当一个开发人员建议使用文件系统作为消息传递层是一个糟糕的解决方案时，这种说法就出现了，而应改为使用诸如关系数据库（MySQL），noSQL数据库（Redis）甚至是普通的REST API调用之类的东西。 应当注意，Redis用于组织中其他地方的队列消息处理。 我听到的论点如下 支持平面文件： 平面文件比任何其他解决方案都更可靠，因为仅在拾取后将文件从“监视”文件夹移至“处理”文件夹，完成后才移至“完成”文件夹。除非存在非常低级的错误，否则消息消失的风险为零，这无论如何都会破坏其他功能。 平面文件需要较少的技术知识来理解-就是cat这样。无需编写查询，也不会意外将消息从队列中弹出并永久消失。 从编程的角度来看，文件管理代码比数据库API更简单，因为它是每种语言的标准库的一部分。这降低了代码库的整体复杂性以及必须引入的第三方代码的数量。 在YAGNI原则规定，平面文件工作得很好，现在，没有表现出需要更换一个更复杂的解决方案，所以离开它。 支持数据库： 扩展数据库比充满文件的目录更容易 平面文件存在有人将“完成”文件复制回“监视”目录的风险。由于此应用程序（虚拟机管理）的性质，这可能会导致灾难性的数据丢失。 要求T / S应用程序具有更高的技术水平，这意味着未受过教育的员工不太可能仅仅通过戳东西来搞砸。 数据库连接代码，尤其是针对Redis之类的数据库连接代码，至少与标准库文件管理功能一样强大。 从开发人员的角度来看，数据库连接代码明显（如果没有功能）更简单，因为它的级别比文件操作更高。 从我的看到，两个开发人员都有很多有效的观点。 因此，在这两个人中，亲文件开发人员或亲数据库开发人员中，哪一个更符合软件工程最佳实践，为什么？

20 database  programming-practices  file-handling  message-queue 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我花了最后一周深入研究Akka文档，最终了解了什么是actor系统，以及它们解决的问题。 我对传统的JMS / AMQP消息代理的理解（和经验）是，它们存在以提供以下功能： 生产者和消费者之间的异步处理；和 消息传递保证，包括持久性，重试和回退 但是，如果没有所有必需的基础架构和运营开销，Akka是否可以提供此服务？ 在Akka中，所有Actor通信都是异步且无阻塞的。和 在Akka中，SupervisorStrategies存在完成重试，后备和升级的功能。如果也需要的话，可以将Actor配置为持久存储到几乎任何类型的商店。 因此，这让我感到奇怪：如果我的应用程序使用Akka，是否需要将JMS / AMQP代理（例如ActiveMQ，RabbitMQ，Kafka）带入图片？换句话说，是否曾经有过这样的用例，那就是基于Akka的新应用程序还需要引入新的 JMS / AMQP代理集群？为什么或者为什么不？ 唯一的论点是，也许我的Akka应用程序必须与另一个系统集成。但是在那种情况下，Akka-Camel模块使Akka可以利用Camel详尽无穷的，几乎无限的集成功能列表（TCP，FTP，ZeroMQ，这个列表不胜枚举……）。 有什么想法吗？

19 asynchronous-programming  message-queue  messaging  akka 

我正在寻求有关消息队列的建议。我们要求将“职位”发布到消息队列中。 最初的建议只是使用SQL Server实例并处理来自该实例的消息。我在互联网上阅读的所有内容都表明，将数据库用于Message Queue并不是可扩展的解决方案。因此，建议使用RabbitMQ或其他第三方的MQ。 要考虑的另一件事是“作业处理”的要求不会低于30秒，因此执行作业的过程将每30秒轮询一次数据库。在我看来，这似乎还不错，并且在不向数据库中添加大量负载的情况下可以正常工作。 我们已经在客户端上建立了一个数据库，我们可以为此使用它，因此它不会为客户端增加太多额外的支持，而如果我们添加了一个第三方MQ，则会对网络配置等提供额外的支持。考虑到有很多用户，这相当可观。 我正在考虑的另一个选项是允许用户在两​​者之间进行选择。如果他们是小用户，则可以使用Sql Server解决方案，但如果他们是大用户，则可以允许他们配置第三方MQ解决方案。 我没有出售任何解决方案，我想知道是否有人有我应该考虑或建议的东西。

17 database  message-queue 

根据Kafka网站： “ Kakfa用于构建实时数据管道和流应用程序。 ” 在广泛的互联网上搜索，我发现以下“ 流数据 ”是什么？ 流数据是通过网络从源连续地流到目的地的数据。和 流数据本质上不是原子的，这意味着流的数据流的任何部分都是有意义的和可处理的，与文件的字节相反，除非您拥有全部字节，否则它什么都没有。和 流数据可以随时启动/停止；和 消费者可以随意附加和分离数据流，并只处理他们想要的部分数据 现在，如果我上面所说的任何内容不正确，不完整或完全错误，请先纠正我！假设我或多或少都在轨道上，那么... 现在，我了解了什么是“流数据”，然后，我了解了Kafka和Kinesis在将自己称为具有流数据的应用程序的处理/中介中间件时的含义。但这激起了我的兴趣：可以/应该像传统的消息代理一样，将Kafka或Kinesis之类的“流中间件”用于非流数据吗？反之亦然：是否可以/应该使用RabbitMQ，ActiveMQ，Apollo等传统MQ来传输数据？ 让我们以一个示例为例，其中应用程序将发送其后端常量的需要处理的JSON消息，并且处理过程相当复杂（验证，数据转换，过滤，聚合等）： 情况1：消息是电影的每一帧；每个视频帧包含一个JSON消息，其中包含帧数据和一些支持的元数据 情况2：消息是时间序列数据，可能是某人的心跳随时间变化的函数。因此，发送了＃1表示我在t = 1时的心跳，消息＃2包含了我在t = 2时的心跳，依此类推。 情况3：数据是完全不同的，并且按时间或作为任何“数据流”的一部分不相关。可能随着数百名用户导航应用程序的单击按钮并采取措施而引发的审核/安全事件 根据Kafka / Kinesis的结算方式以及我对“流数据”的理解，它们似乎是案例1（连续的视频数据）和案例2（连续的时间序列数据）的明显候选者。但是，我看不出任何原因，如RabbitMQ之类的传统消息代理也无法有效地处理这两种输入。 在案例3中，仅向我们提供了一个已发生的事件，我们需要处理对该事件的反应。所以对我来说，这意味着需要像RabbitMQ这样的传统经纪人。但是，也没有理由不能让Kafka或Kinesis也不能处理事件数据。 因此，基本上，我正在寻求建立一个表述：我有具有Y特征的X数据。我应该使用像Kafka / Kinesis这样的流处理器来处理它。或者，相反，它可以帮助我确定：我拥有具有Z特征的W数据。我应该使用传统的消息代理来处理它。 因此，我想问：关于数据的哪些因素（或其他因素）有助于指导流处理器或消息代理之间的决策，因为两者都可以处理流数据，并且两者都可以处理（非流）消息数据？

13 message-queue  stream-processing  apache-kafka 

我正在做一个研究项目，正在研究处理事件驱动的微服务体系结构中的更改的选项。 因此，假设我们有一个应用程序，其中有四个不同的服务。这些服务中的每一个都有自己的数据库来存储本地数据。 在此设置中，这四个服务使用事件总线相互通信。因此，当服务中发生某些事情时，它会发布一个事件。所有对该事件感兴趣的其他服务都将以自己的方式对其进行处理。 在那种情况下，架构中的不同服务需要就这些事件（属性等）的内容订立“合同”。因此，服务对这些事件具有“松散耦合的依赖性” 我的问题是： 我们如何应对这些事件的变化？ 因此，假设服务A在应用程序中注册了新用户。因此，它发送一个“ UserRegistered”事件，服务B拾取该事件并对其进行处理，但是服务C小组的一些开发人员决定他们也需要注册用户的性别，因此该事件被更改，属性性别被添加到“ UserRegistered”事件。 我们如何确保服务B仍可以在不重新部署的情况下使用该额外属性来拾取同一事件？ 还有其他方法可以解决此问题，然后对这些事件进行版本控制吗？

9 communication  versioning  microservices  message-queue  code-contracts 

我正在为三层系统设计REST API，例如：Client application-> Front-end API cloud server-> user's home API server (Home)。 Home是家用设备，应该Front-end通过Websocket或长时间轮询来保持连接（这是我们违反REST的第一个地方，以后还会更糟）。Front-end大多数情况下会将Client请求传送到Home连接并处理一些呼叫本身。有时会Home向发送通知Client。 Front-end并Home具有基本相同的API；Client可能是Home通过LAN直接连接。在这种情况下，Home需要Client在Front-end自身上注册一些操作。 该系统中REST的优点是： REST是人类可读的； REST具有明确定义的动词（如CRUD），名词和响应代码到协议对象的映射。 它可以通过HTTP运行并传递所有可能的代理。 REST的反对意见是： 我们不仅需要一种请求-响应通信方式，还需要一种发布-订阅方式。 HTTP错误代码可能不足以处理三层通信错误。Front-end可能返回202 Accepted异步调用只是为了发现必要的Home连接断开了，应该已经连接了503; Home需要向发送邮件Client。Client将必须进行轮询Front-end或维护连接。 我们正在考虑通过Websocket上的WAMP / 高速公路来获得发布/订阅功能，这让我惊讶的是它已经看起来像消息队列。 是否值得评估一种消息队列作为传输方式？ 看起来像消息队列相反是： 我需要在消息级别上自己定义CRUD动词和错误代码。 我读到一些有关“较高的维护成本”的信息，但这意味着什么？ 这些考虑有多严重？

9 architecture  web-services  rest  message-queue  websockets