8 Matching Annotations
  1. Jul 2022
    1. 事件溯源是 并行模型或追溯事件的基础。如果您想使用其中任何一种模式,您需要先使用事件溯源。事实上,这会导致很难将这些模式改造到不是使用Event Sourcing构建的系统上。因此,如果您认为系统以后有可能需要这些模式,那么现在构建事件溯源是明智的。这似乎是把这个决定留给以后重构是不明智的情况之一。

      需求设计过程中需要考虑,后期增加难度极大。

    2. 更好的方法是将策略对象挂钩到一个 时间属性中:类似于 chargingRules.get(aDate).process(anEvent). 看看 这种风格的协议调度程序。

      逻辑本身随时间变化了,需要将代码与时间绑定

    3. 事件处理数据的变化,代码的变化呢? 我们可以将这里视为三种广泛的代码更改:新功能、缺陷修复和时序逻辑。

      Event Source的挑战,除了与非事件溯源的系统交互即外部互动(含外部更新和外部查询),还包括代码的变更本身。主要设计 时序逻辑的调整、bug fix 和 新 feat 开发

    4. 构建事件处理程序逻辑

      实现事件的记录可以通过事务处理脚本,也可以通过实体类处理。前者适用于简单的逻辑场景。

    5. 应用程序状态可以存储在内存或磁盘中。由于应用程序状态完全可以从事件日志中导出,因此您可以将其缓存在您喜欢的任何地方。工作日期间使用的系统可以在一天开始时从夜间快照启动,并将当前应用程序状态保存在内存中。如果它崩溃,它会重播隔夜商店的事件。在工作日结束时,可以对状态进行新的快照。可以随时并行创建新快照,而不会关闭正在运行的应用程序。

      有了Event的记录就不用担心程序状态的丢失,可以快速恢复。

    6. Complete Rebuild:我们可以完全丢弃应用程序状态并通过在空应用程序上重新运行事件日志中的事件来重建它。 时间查询:我们可以在任何时间点确定应用程序的状态。从概念上讲,我们通过从空白状态开始并将事件重新运行到特定时间或事件来做到这一点。我们可以通过考虑多个时间线(类似于版本控制系统中的分支)来进一步实现这一点。 事件重播:如果我们发现过去的事件不正确,我们可以通过反转它和以后的事件来计算后果,然后重播新的事件和以后的事件。(或者实际上是通过丢弃应用程序状态并按顺序使用正确事件重播所有事件。)相同的技术可以处理以错误顺序接收的事件——这是与异步消息通信的系统的常见问题。

      通过对事件的记录,我们可以完全的将历史重现,也可以查询特定时间点的程序状态。历史的部分重现也可以用于debug。 典型代码就是VCS,git保留了项目开发的完整历史。

    1. 二分查找涉及的很多的边界条件,逻辑比较简单,但就是写不好。例如到底是 while(left < right) 还是 while(left <= right),到底是right = middle呢,还是要right = middle - 1呢? 大家写二分法经常写乱,主要是因为对区间的定义没有想清楚,区间的定义就是不变量。要在二分查找的过程中,保持不变量,就是在while寻找中每一次边界的处理都要坚持根据区间的定义来操作,这就是循环不变量规则。 写二分法,区间的定义一般为两种,左闭右闭即[left, right],或者左闭右开即[left, right)。

      思路简单,但是实现容易出错,需要背诵模板

    1. MyISAM相对简单所以在效率上要优于InnoDB。如果系统插入和查询操作多,不需要事务外键。选择MyISAM 如果需要频繁的更新、删除操作,或者需要事务、外键、行级锁的时候。选择InnoDB。

      MyISAM并不是一无是处,需要仔细考虑和InnoDB的差异。 #MySQL