在事件源中处理大量事件
具有事件源的CQR看起来非常适合作为我们的一个系统的架构，目前我们只担心一件小事：处理大量事件，并因此处理大型事件商店。
我们当前的系统每天接收大约一百万个事件（目前与事件源无关），如果我们将它们存储在更长的时间内，我们的事件存储可能会变得相当大，但是如果我们经常转储/清除滚动快照，我们可能会失去事件源的一大优势：关于系统历史和重播的信息。
在CQRS架构中处理这个问题的常见方法是什么？这到底是个问题吗？我们只是在事件存储中投入更多硬件，还是我们可以在架构设计级别做些什么？
共有2个答案
看看你的“活动流集”。是否有流的生命周期，它们往往会出现，在相对较短的时间内发生变异，然后在达到最终状态时死亡？如果是这样，这些流可以移动到更便宜的存储（备份）。您需要它们的唯一原因是为了重播，因此您可能希望让它们仍然可以访问（尽管响应速度较慢）或保留一个压缩副本以供重播。无论如何，一定要质疑是否有流可以移出事件存储或至少移出活动流集。
另一种选择是跨多个物理事件存储区对流进行分区。也许有一个地理边界可以使用，或者可能有一些东西自然地将它们分割开来（你所在的领域通常会提供提示）。这是一种你需要反思优点和缺点的事情。
这种技术并不局限于事件源。它同样适用于基于状态的模型（毕竟只是数据）。
我认为最常见的方法是使用快照和持久读取模型。也就是说，除非需要构建新的读取模型或更改现有读取模型的工作方式，否则实际上不会经常重播事件。通过存储域对象的快照，可以避免重播长时间的事件流。
有人可能会争辩说，存储快照和持久读取模型与在没有事件源的情况下执行CQRS没有太大不同。但是，如果您在读取模型中犯了错误，或者需要获取新信息，或者有其他严格的审计要求，旧事件就在那里。
在我们的应用程序中，我们有许多业务价值较低的事件，我们计划在执行期间大量清除事件，以便事件日志保持较小。但我认为对于某些对象，我们仍然会回到快照和持久化模型。
-
我们需要在constructor中对于事件与对应的handler函数进行绑定. 大多数时候我们在发出DOM事件的组件内部写我们的handler函数. 在下面的例子中,我们在组件内部创建了一个click handler, 因为我们想所有的Swithcer Component当被点击时,做出同样的响应. class Switcher extends React.Component { render
-
我不喜欢流口水。我正在尝试使用Drools Fusion编写一个简单的复杂事件处理（CEP）应用程序。 我的要求是 我有一个简单的Event类，如下所示： 规则文件如下： 为了进行测试，我将向工作内存中注入4个事件，分别是e1、e2、e3、e4，时间线分别为0m、4m、10m、12m。 Jave类文件 我希望e1通过规则，因为它没有前面的事件。我还预计e3将通过，因为前面的比赛还有6分钟。 但是，
-
事件处理概述 事件处理是对象化编程的一个很重要的环节，没有了事件处理，程序就会变得很死，缺乏灵活性。事件处理的过程可以这样表示：发生事件 - 启动事件处理程序 - 事件处理程序作出反应。其中，要使事件处理程序能够启动，必须先告诉对象，如果发生了什么事情，要启动什么处理程序，否则这个流程就不能进行下去。事件的处理程序可以是任意 JavaScript 语句，但是我们一般用特定的自定义函数（functi
-
Mpx在事件处理上基于原生小程序，支持原生小程序的全部事件处理技术规范，在此基础上新增了事件处理内联传参的增强机制。 原生小程序事件处理详情请参考这里 增强的内联传参能力对于传递参数的个数和类型没有特殊限制，可以传递各种字面量，可以传递组件数据，甚至可以传递for中的item和index， 当内联事件处理器中需要访问原始事件对象时，可以传递$event特殊关键字作为参数，在事件处理器的对应参数位置
-
Rax 元素的事件处理和 HTML 的 DOM 元素类似，但在语法上有一些区别： 事件采用驼峰式命名。 传入函数作为事件处理器而不是字符串。 例如，在 HTML 中为 DOM 元素绑定事件的写法为： <button onclick="activateLasers()">激活按钮</button> <scripts> var activateLasers = function() { al
-
事件绑定 通过ev-*属性，可以在dom上绑定事件 例如： <button ev-click={function() { alert('点击了按钮') }}>点击按钮</button> 绑定方法 大多数情况下，事件处理函数都比较复杂，直接写在模板中不太优雅。 一般通过将事件处理传入模板的render方法，来进行绑定 例如： <button ev-click={onClick.bind(self)