标签: event-driven

最近我遇到了一个很棒的perl模块"AnyEvent",它允许用户进行异步/事件驱动的编程.

创建了以下代码片段,工作正常.我遇到的问题是,在打开并关闭许多套接字后,它很快耗尽了所有客户端端口("netstat -ant"显示20,000多个套接字处于TIME_WAIT状态).

$hdl = new AnyEvent::Handle (
  connect => [$ip, $port],
  on_connect=> sub {
      my ($handle, $host, $port, $tmp) = @_;
      #print "connect routine for $handle->{ue}\r\n";
      #update states.
  },
  on_read => sub {
      my $hdl = $_[0];
      #read data
      #send response.
  });

我想知道是否可以使用IO :: Socket :: INET创建TCP套接字,然后在AnyEvent :: Handle中使用新创建的套接字:

my $sock = IO::Socket::INET->new( Proto    => 'tcp',
                             PeerAddr => $ue->{vars}->{ip},
                             PeerPort => $ue->{vars}->{dstPort},
                             ReusePort => 1,
            KeepAlive => 1
) || die "failed to setup outsock $@\n";
$hdl = new …

我正在为我们的新后端项目考虑一些框架/编程方法。它涉及一个 BackendForFrontend 实现，它聚合下游服务。为简单起见，这些是它经过的步骤：

1. 请求进入网络服务器
2. 网络服务器发出下游请求
3. 下游请求返回结果
4. 网络服务器返回请求

事件驱动编程如何比“常规”线程每请求处理更好？一些网站试图解释，通常归结为这样的：

第二种解决方案是非阻塞调用。调用者没有等待答案，而是继续执行，但提供了一个回调，一旦数据到达就会执行。

我不明白的是：我们需要一个线程/处理程序来等待这些数据，对吗？很高兴事件处理程序可以继续，但我们仍然需要（在本例中）每个请求的线程/处理程序等待每个下游请求，对吗？

考虑这个例子：下游请求需要 n 秒才能返回。在这 n 秒内，r 个请求进来。在 thread-per-request 中，我们需要 r 个线程：每个请求一个。经过 n 秒后，第一个线程完成处理并可用于新请求。

在实现事件驱动设计时，我们需要 r+1 个线程：一个事件循环和 r 个处理程序。每个处理程序接受一个请求，执行它，并在完成后调用回调。

那么这如何改进呢？

我正在完成Bjarne Stroustrup的C++编程语言中的一些练习.我对第12章末尾的问题11感到困惑:

(*5)设计并实现用于编写事件驱动模拟的库.提示:<task.h>....类任务的对象应该能够保存其状态并恢复该状态,以便它可以作为协程运行.可以将特定任务定义为从任务派生的类的对象.由任务执行的程序可以被定义为虚拟功能.......应该有一个实现虚拟时间概念的调度程序.......任务需要沟通.为此设计一个类队列....

我不确定这究竟是什么要求.任务是一个单独的线程吗？(据我所知,没有系统调用就不可能创建新的线程,因为这是一本关于C++的书,我不相信这是意图.)没有中断,如何启动和停止运行功能？我假设这将涉及忙等待(也就是说,连续循环并检查条件),虽然我看不出如何将其应用于可能不会终止一段时间的函数(例如,如果它包含无限循环) .

编辑:请参阅下面的帖子了解更多信息.

我在微服务和事件来源方面还是个新手，我试图找出一种在AWS上部署整个系统的方法。

据我所知，有两种方法可以实现事件驱动的体系结构：

• 使用AWS Kinesis数据流
• 使用AWS SNS + SQS

因此，我的基本策略是将每个命令转换为存储在DynamoDB中的事件，并利用DynamoDB流将新事件通知其他微服务。但是如何？我应该使用前两个解决方案中的哪一个？

第一个优点是：

• 消息排序
• 至少一次交货

但是缺点非常成问题：

• 没有内置的自动缩放功能（您可以使用触发器来实现）
• 没有消息可见性功能（显然是要求确认）
• 没有主题订阅
• 非常严格的读取事务：您可以使用我在这里阅读的内容使用多个分片来改进它，您必须具有数量不明确的，具有不同调用优先级的lamda，并且必须具有明确的策略，以避免在同一微服务的多个实例之间进行重复处理。

第二个优点是：

• 完全管理
• TPS很高
• 主题订阅
• 邮件可见性功能

缺点：

• SQS消息是尽力而为的排序，仍然不知道它们的含义。它说：“标准队列会尽最大努力保持消息的顺序，但是可能会不按顺序地传递消息的多个副本”。这是否意味着给n条消息的副本，与其他消息的副本相比，第一个副本按顺序交付，而其他副本按无序交付？还是“不止一个”可以是“全部”？

非常感谢您的各种建议！

我们的团队开始实施事件驱动设计。我们现在正在确定记录这些事件的模式的最佳工具和实践是什么。

用于此用例的常用工具有哪些？

任何链接或建议表示赞赏。

我正在编写看起来像这样的代码:

function someFunction()
{
    doStuffWithCallback(function(success)
    {
        if(success)
        {
            ...
            // do stuff here
            ...
        }
        else
            someFunction();
    });
}

基本上,继续尝试"doStuffWithCallback"直到回调接收到绿灯.通常,这将通过循环完成,但是如何在事件驱动模型中执行此操作而不会在从未达到成功的情况下导致无限递归？(success可能依赖于外部服务器之类的东西,所以如果它们失效,它将一直是假的).

代码的结构不能改变太多; 由于我正在使用的API,我必须使用回调来完成我想要的.

有没有办法在不将父级保存在对象属性中的情况下找到小部件的父级（特别是按钮）？

but = Button(main_window, text = "close window!")
but.bind("<Button-1>", btn_handler)

def btn_handler(e):
    e.parent().destroy() # I need something like this!
    # e.parent() ==>> main_window
    # without writing class and defining self.parent ...

我在互联网上搜索了几个小时，但没有找到正确的答案。

在我的 Angular UI 中，我从 API 网关调用了一个端点，例如：

this.http.post(`/order`).subscribe(order => addNewOrderToList(order));

根据微服务的最佳实践，/order处理程序应该发布一个由一个或多个微服务使用的事件，而不是使用同步 REST 相互调用。因此，我编写了以下处理程序：

@RequestMapping
public Future<Order> addOrder() {
  CompletableFuture<Order> future = new CompletableFuture<>();
  // publish event
  // ...
  // wait for final event raised by a service.
  future.complete(createdOrder);
  return future;
}

从 UI 的角度来看，在我的端点返回新订单之前，用户不是不会看到新订单吗？我觉得即使后端是异步的，UI 仍然是同步的。在这种情况下，改进 UI 的最佳做法是什么？

问题介绍： 在使用MediatorLiveDataandroid自带的android jetpack的时候，我发现自己经常从各个源调用同一个函数。例如，这可能是因为，每当更新一个来源时，我都必须检查它是否有影响，或者另一个来源是否更重要。代码示例（Kotlin，但不重要）：

val isHovered = MutableLiveData<Boolean>()
val isSelected = MutableLiveData<Boolean>()

val color = MediatorLiveData<Int>().apply { 
    addSource(isHovered) { updateColor() }
    addSource(isSelected) { updateColor() }
}

fun updateColor() {
    if (isHovered.value == true)
        color.value = Color.GREEN
    else if (isSelected.value == true)
        color.value = Color.RED
    else
        color.value = Color.GRAY
}

悬停时项目为绿色，选中时为红色，未悬停时为红色，否则为灰色。当 isSelected 变为 true 时，在将颜色更改为红色之前，我还需要检查它是否处于悬停状态。此外，当 isHovering 更改为 false 时，我需要在将颜色更改为灰色之前检查它是否被选中。所以最简单的是一个函数，它考虑了所有变量并相应地设置颜色。

我的问题： 当 MediatorLiveData 从非活动状态变为活动状态时，因为视图移到了前台updateColor，对于每个更改的源，可能会多次调用该函数。这是不必要的，因为每次调用都已经考虑了所有变量。由于这个函数可能非常复杂并且可能有很多来源，有没有办法避免针对源 LiveDatas 的相同状态多次调用它？

我正在尝试一些新概念，事件溯源、微服务以及所有这些范式。

假设我们有以下结构，它代表了基本的事件驱动架构

UI -> API -> EVENTS BROKER ->> MICROSERVICES

我们从客户端（UI）向服务器（API）发出请求，执行一个命令，该命令抛出一个事件，该事件被发布到事件代理中，然后订阅该特定事件的每个服务将启动一个进程，对吗？但是如果我还想实现事件溯源怎么办，看起来可能是这样的，对吗？

UI -> API -> EVENTS BROKER ->> MICROSERVICES
          -> EVENTS STORE

对于这个例子，假设我有一个聚合，它被称为Products“如果在我将事件保存在事件存储中之后，我的业务逻辑说它不应该被允许，因为我现在不允许，也许我们只在特定日期接受新产品”一个月内，但现在我已经存储了该事件

问题本身是，在这种情况下我应该什么时候将事件保存到 EVENT STORE 中？