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

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

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

构建事件处理程序逻辑

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

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

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

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