问题标签 [nservicebus-distributor]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
nservicebus - NServiceBus Distributor - 如何拆分应用程序
我们有 1 个服务,它从数据库中选择 som id,然后按顺序使用一些业务逻辑处理它们。我们希望横向扩展并并行执行的处理,而不创建大量内部线程。
我的问题是:
如果我想使用 Distributor 进行横向扩展,我应该如何以及如何做到这一点?
解决方案1: 服务拆分为2:
- 原始服务被修改为仅从数据库中选择 id,然后将它们发送给工作人员。这将是分发器 (RunDistributorWithNoWorkerOnItsEndpoint)。
- 一个新的服务,它将保存业务逻辑并作为工作人员处理每个传入的 id。如果我想要更多的工人,我只需多次启动相同的过程。
方案2: 服务拆分为3:
- 原来的服务被修改为只从数据库中选择id,然后发送给distributor。
- 一个新的服务,分发器 (RunDistributorWithNoWorkerOnItsEndpoint),它只处理工作人员的负载平衡。
- 一个新的服务,worker(s),它将保存业务逻辑并处理每个传入的 id。
方案3: 服务拆分为2:
- 原来的服务被修改为只从数据库中选择id然后发送。作为发件人运行。
- 一个新的服务,它将保存业务逻辑并充当工作者和分发者,处理每个传入的 id 或分发它们。
解决方案 1 对我来说很有意义,但使用它意味着分销商会以某种方式承担 2 个责任:
- 选择标识。
- 将 ID 分发给工作人员。
但是当我查看 NSB 文档中的 ScaleOut 示例时,我不确定这是否可能,甚至可能是反模式。
在再次阅读文档和 ScaleOut 示例之后,我认为我应该采用解决方案 3,但我还不太确定。
我试图通过与 NSB 分销商进行横向扩展来解决管道问题,我更愿意自己进行托管,而不是使用 NServiceBus.Host.exe,但这不是严格的要求。
编辑: 我最终使用了解决方案 3,因为如果您使用默认队列命名,它的优势(在我看来)配置队列的任务比解决方案 2 中的小。
亲切的问候
nservicebus - NServiceBus 和 DTC 的
我在 NServiceBus 中使用 Distributor,但我对 DTC 的问题一无所知。在跨进程做事情之前,我只使用过一次 DTC,也许两次,而不是很多,所以我对整个 DTC 概念非常陌生。
我问的原因是我希望 NSB 能够检测到处理程序中的任何异常,因此通过不从队列中删除消息来对错误做出反应。因此不需要 DTC。这当然意味着处理程序中的任何数据库或外部服务访问都需要程序员执行她/他自己的回滚等。因此,DTC 似乎确实是最好的方法。所以我完全支持 DTC(如果我理解正确的话),因为从我的角度来看,它们确保消息永远不会从队列中丢失,并且只要处理程序正确实施并且让其他外部服务参与 DTC,消息处理就永远不会损坏.
但我不确定,特别是因为服务器维护团队中一位受人尊敬的人使用了“DTC's will cause you a world of pain!”这句话。当我提出由他在数据库服务器上激活 DTC 的想法时...
对 DTC 和 NSB 有很好理解的人可以帮我澄清一下我是否完全不了解我对 DTC 的理解,以及我是否完全错过了 DTC 的一些大陷阱?
亲切的问候
msmq - NServiceBus 工作人员端点
我目前正在评估 NSB 中的分发服务器,并注意到当我在自己的机器上运行分发服务器和几个工作人员时,每个工作人员的队列名称都会附加一个 Guid。
根据 Udi,主人本人 :),在这篇文章中:Distributor and worker end point queue in same machine
原因是 NSB 假设您在测试设置中运行。
问题:
但是如果我在 1 台单独的机器上运行 4 名工人会发生什么?该机器上的队列名称是否会再次附加一个 Guid或者工作人员是否能够仅仅因为分发器在远程机器上而共享同一个队列?
这个问题很重要,因为我确实希望在一台远程机器上有多个工作人员,并且每次机器启动时生成新的队列名称对于维护目的来说不是一个好主意。
亲切的问候
nservicebus - NServiceBus Distributor 吞吐量许可证限制或 MSMQ 性能地狱?
昨天,在与分销商进行了一些非常有希望的测试后,我申请了额外的预算来购买 NSB(36-80 核)的许可证。
应该提到的是,我们目前正在使用分销商来解决管道问题,而不是真正的商业活动,但这将在以后出现。
今天我非常熟练的同事也开始使用公共汽车,只是由于他的项目性质,他的性能要求比我高得多。所以他的测试需要比分销商目前给我的平均 30-50 msg pr 秒多得多。
无论我们尝试做什么:
- 更多的工人。
- 工作人员的更多线程。
- 分配器上的更多线程。
- 启用/禁用 DTC
- 以上所有内容都在概念设置的基本证明中,其中包含仅带有 id 的消息。我们无法获得超过 100 条 msg 分布式公关。其次是工人。
这非常糟糕,因为我已经申请了更多的预算资金,如果我们不能很快获得更好的性能,我们必须放弃这个项目,我们将面临一些严重的麻烦:S。
问题:
我们当前使用的开发人员许可证是否存在导致此限制的限制,或者 MSMQ 是否存在严重的性能问题,例如此处所述: http: //ayende.com/blog/4251/what-am-i-缺少-msmq-perf-问题。
我在 nservicebus 自己的网站上阅读了很多关于许可证的内容,但没有明确说明对开发人员许可证的限制。
希望有人可以帮助我:)。
[更新]
我回到基础并尝试用 NSB 自己的代码示例ScaleOut重现问题,只需发送 10000 条消息,看看工人/分销商会如何反应。所以我启动了分发器和 2 个工作人员(每个工作人员有 100 个线程)并猜测问题再次出现。
- 幸运的是,这表明我们没有完全错误地配置我们的 Distributor/Worker 设置。
- 不幸的是,这意味着我们仍然存在与 Distributor 的性能问题。
然后我想知道这是否真的是这样,并开始运行一些简单的线程,使用 Distributor 和 Workers 调整测试。经过一些尝试,我在示例中获得了高达 400-500 msg pr sec 的吞吐量。这是我发现的:
观察/解决方案:
- Distributor 需要更多的线程,而不仅仅是 1,但不能太多。现在我正在运行 2 个线程。我启动的工人。
- 如果我运行 20 或 100 个线程,Workers 通常会具有相同的性能。因此,我没有增加线程数量,而是增加了工作人员的数量,这起到了作用。
- 如果分发器或工作器上的线程数过多,它们似乎会遇到MSMQ 事务战斗,它们会相互阻塞,从而使系统突然阻塞。我可以使用 ScaleOut 示例和我自己的代码轻松重现阻塞,但是 TX 之战只是基于我阅读的文章的疯狂猜测,我不知道这就是正在发生的事情。
后续问题:
- 现在要做什么?我们应该用其他东西替换 MSMQ 还是这个问题是 NSB 内部的问题,可以在以后的版本中优化/修复?
- 这是 Distributor 的预期工作方式,这意味着我们唯一的解决方案是解雇更多的工人吗?
- 同一端点上的多个工作人员,但与分发器运行的机器不同,是否不会导致工作人员之间可能再次导致 MSMQ TX 战斗的竞争消费者情况?
- 示例和我们自己的代码之间有一个重要区别,我们禁用了 Raven 订阅存储,并且纯粹在 MSMQ 上运行,但据我所知,分销商不使用 Raven db 进行存储。我错了,这可能是一个获得一些表现的地方吗?
我现在正在做一些分布式测试,看看是否存在在同一台机器上启动多个工作人员的问题,但不是与分发服务器相同的机器。我希望这是可能的,而不必为每个工人设置单独的队列,因为我们已经为工人订购了额外的服务器并且没有更多的预算。
到目前为止,我有点失望,因为我不能简单地增加一个工作线程的数量,然后只从一个工作人员开始,然后扩展到更多机器,每台机器都有 1 个工作人员。现在我被迫在一台机器上有多个工人:/。
如果关于我缺少的经销商/工人有任何小问题,请分享,因为这让我发疯:/。
[更新 2]
如果我在 Visual Studio 外部使用 NServiceBus.Integration NServiceBus.Distributor/Worker 运行 ScaleOut 示例,并且只有 1 个工作人员,我可以获得 4-500 msg/sec 的吞吐量。
这很好,但它不能解释我在我们自己的设置中做错了什么,我们是自我托管的。看看我们的配置并告诉我是否有问题:
经销商:
工人:
我们在这里做错了什么可能会导致性能差异吗?
亲切的问候。
nservicebus - System.Net.HttpListenerException:无法侦听前缀“xxxx”,因为它与机器上的现有注册冲突
每当部署我们的组件时,我们都会收到以下异常。有时组件本身不会启动,有时服务控制台可能会说已启动但服务不会处理任何消息。错误非常简单。还有一个 HttpListener 仍在监听前缀。
当我们进行深度分析时。
- 此问题仅在您运行 NServiceBus.Master 配置文件时发生
- 仅当您从服务控制台执行服务重新启动时才会发生此问题
- 无论你运行多少个 WorkerThread
让我们困惑的是,当我们更深入地阅读 NSB 代码时,我们发现在对象 Dispose 期间 HttpListener 是关闭的。除此之外,当您停止服务时,整个进程本身都会被杀死,因此机器上不会有任何对象来监听给定的 URL 前缀。但是,我们错了。当我们分析很多闭包时,我们发现即使在 Service-Console 认为该服务已停止之后, NServinceBus.Host 进程仍在运行。每当我们在服务控制台上停止服务时,该进程在机器上仍然处于活动状态,并且需要更长的时间才能完全关闭。因此,当我们执行重新启动时,有可能存在多个当前服务的进程实例——一个正在尝试启动,另一个仍在尝试停止。我们确认重启过程会抛出上述异常。
我们对正在关闭的进程进行了转储。我们发现,尽管服务控制台显示状态为已停止,但进程中仍有后台线程处于活动状态。Dispose 期间有很多锁/ObjWait。确保停止的服务尚未关闭 HttpListener 对象。
我们发现,HttpListener 处于活动状态并正在侦听。
问题:为什么服务控制台报告服务已停止,即使该进程在计算机上仍处于活动状态
注意:要重现此问题,您必须使用 NServiceBus.Master 配置文件将主机安装为 Windows 服务并尝试重新启动服务,您可能需要更多尝试才能解决此问题。
更新:
当我在 HttpChannelReceiver.Start() 上阅读 NSB 代码时,它会在新线程上启动侦听器。
- 此侦听器线程是前台线程。(所有其他工作线程都是 BG 线程)
- 没有停止信号进入这个前台线程
- 没有保存此线程引用的变量/字段 - 中止是不可能的。
这个监听线程只有在ServiceHost杀死当前进程的内存时才回收,直到ServicHost收集到它,这个线程才会被阻止退出当前进程。
nservicebus - 许多工人的许多分销商
我们是使用 NServiceBus 作为联合系统中的消息传递框架的许可产品。
寻找在新功能中使用它的机会 - 有没有办法构建多站点系统(横向扩展),每个站点/节点在该系统中生成消息并将消息分发给位于多个节点/站点上的工作人员?每个分销商和工人都可以托管在自己的站点(同一个 LAN)上,并且每个站点都可以随时关闭。所有的经销商和工人应该是对称的。
起初,它看起来像是一个经典的“许多生产者对许多竞争消费者”的问题。但是我找不到使用 NServiceBus 实现它的内置方法,因为据我所见,每个工人只能将健康歌曲发送给一个分销商(我可能错了)。
我遇到的另一个问题是有一个集中的 RavenDB 实例来保存分发者订阅。将 RavenDB 放在它自己的“可用性组”中需要额外的资源。有没有办法在同一个站点下托管 RavenDB 实例,在每个站点使用它的本地数据库实例时复制它们的数据?这也会将分销商的 HA 绑定到他们的订阅数据库。
阅读此讨论- http://tech.groups.yahoo.com/group/nservicebus/message/18412 似乎 NServiceBus 需要一个集群来保持已发布数据的 HA。但是为什么分发者不能等待确认消息已被工作人员成功消费和处理,并继续重试将其发布给相同或不同的工作人员?这样,即使 VM 因队列中的数据而宕机,数据也会被发送到当时可用的另一个节点。
编辑:试图在 NServiceBus 官方雅虎组提出同样的问题,但在雅虎组中不断收到 pythonError。
在此先感谢 Rami Prilutsky,dbMotion
msmq - NServiceBus - 分销商控制消息错误
我们已经购买了很多许可证,进行了很多测试并获得了很多有希望的结果,并且即将发布我们的第一个版本 :)。
但是现在我们在路上遇到了一个大颠簸,这意味着如果我们不能解释和修复它,我们可能不得不放弃公共汽车:/。
我们的 Distributor 突然有如下控制错误消息:
Google 告诉我们,这可能与一些线程问题有关,甚至可能与使用 peek/receive 实现 NSB 的方式有关。
上述异常与 GitHub 上的此文件有关:https ://github.com/NServiceBus/NServiceBus/blob/master/src/impl/unicast/transport/NServiceBus.Unicast.Transport.Transactional/TransactionalTransport.cs
有关我们实施的详细信息:
由于一些遗留问题,我们使用自定义 IManageUnitsOfWork,这意味着还没有针对数据库的 DTC。我不认为这可能是原因,但我认为值得一提。这是实现:
此外,我们有一个特殊的设置,我们在 1 个运行的服务中运行 4 个相同的 AppDomain,这意味着当我们作为分发服务器启动服务时,实际上有 4 个分发服务器在运行。但这些都是公关。定义完全相互隔离。每个 AppDomain 的 IBus 都是唯一的,这已经过测试。
我们的 Distributor 配置如下所示:
问题:
这里发生了什么?
我们是否因为使用 DTC 抑制而与 NSB 搞砸了,是否存在 MSMQ 错误或是否存在 NSB 错误?
nservicebus-distributor - NServiceBus Distributor Worker 创建一个新的工作队列
我正在使用 Distributor/Worker,但是当我重新启动应用程序时,它每次都会创建一个具有唯一 ID 的新 Worker 队列。
任何线索?以及了解更多有关分销商/工人及其配置的最佳地点。
nservicebus-distributor - 为什么 NServiceBus DistributorDataAddress 必须在 WORKER 节点的 UnicastBusConfig 上设置?
什么是 DistributorDataAddress?WorkerNode里面有什么用???
在所有缩放示例中,我都可以看到这是在 Worker 中设置的。
nservicebus - NServiceBus 4.03 Distributor 将 30 条消息放入存储队列,用于控制队列中的一条消息
当工作人员启动时,它会将消息放入控件 q,然后当我启动分发器时,它会从控件 Q 中获取消息并将30条消息放入存储 q。任何线索为什么???