我正在使用javaeventing编写一个偶数驱动的shell来访问数据库.所以,我的用例是:

1. 在命令行中打开shell.
2. 现在,shell连接到数据库并侦听进来的命令.
3. 当它获得一个命令时,它会执行它并返回所需的输出.

现在,我怎么能避免while(!exit){ //do stuff }这种循环呢？如何正确使用Java事件？

直截了当的方式可以是:

while(!exit)
{
   exit = myClass.execute("command"); //when command is exit, return true.
}

但是,我正在寻找java事件是否可以提供更好的解决方案.

UPDATE1:

这是我想要实现的:

1我的应用程序是一个shell(如mongodb shell)来试用一个键值数据库.
2简单的代码:

init(); //Initialize the connection with database
while(!exit)
{  
    //exit = myClass.execute("put(5)"); //This returns false  
    exit = myClass.execute("exit"); //returns true, i.e. the user wants to exit the shell
}

现在,在这里我没有看到java事件的使用,我解决了我的问题,请你告诉我,如何在这里看到java事件？我希望用户触发事件.

这是一篇很好的文章,描述了它是什么ES以及如何处理它.

那里的一切都很好,但一个图像困扰着我.这里是

据我所知,在基于事件的分布式系统中,我们只能实现最终的一致性.无论如何......我们如何确保我们不会预订更多座位？如果有许多并发请求,这尤其是一个问题.

可能会发生n个聚合使用相同数量的预留席位填充,并且所有这些聚合实例都允许预留.

我们有7个微服务通过eventbus进行通信.我们有一个实时的交易顺序:

服务1-> service2-> service3(依此类推.)直到交易被视为已完成

我们必须确保所有交易都发生.

当然,我们可以在任何时候出现失败.因此,我们正在考虑将机制设备重播为"半成品"交易.

这变得棘手.我们考虑的两种方式:

1. 拥有另一个服务(主管服务),它将在我们的实时序列中记录每个部分,并且在交易未完成时(时间超时)足够聪明,以了解我们如何从左点继续

   缺点:一个中央服务上有很多"智能"逻辑

2. 每个服务都有重试机制,而每个服务都有自己的服务,并重播它自己直到成功或被解雇

   缺点:每个服务上有很多重试重复代码

你有什么专家的想法？

谢谢

我正在设计一个事件驱动系统，该系统将由至少两个由两个不同外包公司组成的团队构建。

我们已经在内部设计了所有内容，但是现在我正在为开发团队创建文档。

对于HTTP，我使用的是OpenAPI。

是否有任何工具或语言来描述事件和处理流？

创建此类文档有哪些好的做法？

关于维基百科中的示例:http: //en.wikipedia.org/wiki/Coroutine

var q := new queue

coroutine produce
    loop
        while q is not full
            create some new items
            add the items to q
        yield to consume

coroutine consume
    loop
        while q is not empty
            remove some items from q
            use the items
        yield

我只是想知道基于传统事件的方法可以处理这种使用模式,为什么需要使用协同程序？

最近,我开始学习Node.js的,对自己的无阻塞IO和令人难以置信的速度见长的V8之上的JavaScript库.

据我了解,节点不等待IO的响应,但运行的事件循环(类似于游戏循环),保持检查未完成的操作,并继续/尽快IO响应完成它们.节点性能与Apache的HTTPD与节点是显著更快,同时使用更少的内存.

现在,如果你了解了Apache,你了解它每个用户使用1个线程,这理应减缓下来显著,这是出现在我的问题,其中:

如果将线程与事件循环内部节点进行比较,则会开始看到相似之处:两者都是等待资源响应的未完成进程的抽象,都检查操作是否定期进行,然后不占用CPU占用了一段时间(至少我认为一个好的阻塞API在重新检查之前会休眠几毫秒).

现在哪个突出的,关键的差异让线程变得更糟？

我一直在使用Spring一段时间才意识到我在应用程序中收到的所有传入请求都不是基于HTTP的.有些请求是基于电子邮件的,需要基于电子邮件的响应,其他请求是基于套接字的(在我的NOSQL存储中值发生变化时接收通知).所有这些,尽管使用或多或少相同的MVC基础设施.

因此,我认为可能重新构建应用程序,以消除控制器和HTTP基础结构之间的耦合将有所帮助.

调度程序不应再直接调用控制器方法,而是提取请求参数,并使用它们创建抽象消息(或事件),然后将其放在消息总线上.另一方面,每个控制器将为不同的事件订阅其动作(Action类的实例 - Command模式的实现).

由于我对Spring Integration,JMS和其他类似的东西都很陌生,所以我不知道选择哪种消息传递技术.此外,我很确定已经开发出这样的架构.也许,我甚至可能没有走上正轨.

我接受有关如何进行的各种建议.

基于演员的范式非常酷.它有效扩展的能力使其成为必须评估任何并发系统的范例.我已经做了一些关于它的阅读,并且对核心意图有了一个不错的想法:用消息和多个"参与者"驱动昂贵的操作,以最大限度地减少因请求/响应交互而导致的等待,从而提高系统的吞吐量.但是,我没有充分了解人们与演员使用的设计模式.我正在寻找基于演员的系统的设计模式.

演员设计模式的一个常见示例是一个系统,其中有一个主协调员角色和一群童工角色.他们掌握将昂贵的操作映射到较小的块,将较小的块作为消息发送给一堆工作者,等待来自它们的响应,然后将它们全部减少到结果.在这种模式的一些复杂的例子中,工作者通知主人他们已经准备好做更多的工作,并且主人的路线更多地按需工作.这确保了适当的工作平衡,并且在工作规模变化很大时非常有用.

我搜索了更多基于演员的模式的文献,除了上面的例子之外找不到任何其他例子.我还没有通过Akka Actors项目样本,但任何指针都非常有用.

我正在将应用程序从c#移动到node.js. 我是一个来自.net背景的node.js新手.我希望将域驱动的设计模式合并到应用程序中.发展使我有了有限的背景和微观服务的概念.我想使用aws作为我的云提供商,但在确定应该使用哪个工具来处理命令和事件处理时遇到问题？Azure有服务总线,似乎对此非常有用.

是否有相当于aws的服务总线,还是我应该使用SQS？

问题

我想了解我需要如何设计微服务的消息传递以使其仍然具有弹性和可扩展性。

目标

• 微服务允许弹性数量的实例根据当前负载自动伸缩。这个特性不应该被Kafka限制。
• 我们需要保证至少一次交付
• 我们需要保证涉及同一实体的事件的传递顺序

运行示例

• 简单地说，假设有 2 个微服务 A 和 B；
• A1、A2为微服务A的实例；微服务B的B1和B2实例
• A1 和 A2 发布描述 A 实体上的 CRUD 操作的事件，例如实体被创建、更新、删除。

问题：

• a) 涉及同一实体的事件可能会被并行处理并且可能会出现乱序，对吗？
• b) 这将导致 B 的实例并行处理请求。限制因素是生产者如何定义 p（分区数量）。如果有 5 个分区，但我需要 8 个消费者来应对负载，那么它将无法工作，因为 3 个消费者不会收到事件。我理解正确吗？这将 IMO 无法用于可能想要进一步扩展的弹性微服务。

设计二

• A1 在a.entity.created.{entityId}导致许多不同主题的主题下发布事件。
• 每个分区大小设置为 1。
• B1 和 B2a.entity.created.*使用通配符作为消费者组订阅主题b-consumers。这导致 B 的实例之间的负载分布。

问题：

• c) 同一实体的事件应该保证按顺序传递，因为只有一个分区，对吗？
• d) …