事件记录

大多数系统都有某种事件日志–即系统中发生了什么以及谁做了。 有时它有双重存在-一次作为“审核日志”，一次作为事件日志，用于重播已发生的事情。

这些实际上是两个独立的概念：

• 审核日志是系统中每个动作所留下的跟踪信息，以便以后可以审核系统。 最好以某种方式保护此日志（稍后再讨论）
• 事件日志是事件源模型的关键部分，在该模型中，数据库仅存储修改，而不存储当前状态。 当前状态是在应用所有存储的修改直到当前时刻之后获得的。 这样可以查看过去任何时候的数据状态。

有很多方法可以获取该功能。 对于审核日志，有Hibernate Envers ，它将所有修改存储在单独的表中。 您还可以使用Spring方面或JPA侦听器（当发生更改时将修改存储在审计日志表中）来获得自定义解决方案。 您可以通过多种方式存储更改-作为键/值行（每个修改的字段一行）或序列化为JSON的对象。

通过始终插入新记录而不是更新或删除（以及增加版本和/或设置“当前”标志），可以实现事件源。 有一些事件来源本地数据库-Datomic和Event Store。 （注意：“事件源”不等于“仅插入”，但是方法非常相似）

它们看起来仍然很相似–都以详细的方式跟踪系统上发生的事情。 那么，审核日志可以用作事件日志，事件日志可以用作审核日志吗？ 有区别吗？

审核日志具有事件源不需要的特定功能-存储业务操作并保持安全。 当用户登录或查看给定项目时，不会发出更新（当然，可以更新last_login_time或last_seen，但这是副作用）。 但是，您仍然可能希望在审核日志中查看有关事件的详细信息–在几次尝试失败之后，谁登录，何时从哪个IP登录。 您可能还想知道谁阅读了给定的信息-如果信息很敏感 ，那么了解谁曾看过信息以及访问是否不是某种形式的“跟踪”就很重要。 在审核日志中，您还可以具有“业务事件”，而不是单个数据库操作。 例如，“结帐购物篮”涉及更新购物篮状态，降低商品的可用性，更新购买历史记录。 而且，您可能只想看“用户X在时间W检出篮子Y和物品Z”。

审核日志的另一个非常重要的功能是其完整性。 您应该以某种方式保护它们免受修改（例如，通过对它们进行数字签名）。 为什么？ 因为在某些时候，这可能是法庭上的证据（例如，在某些员工滥用您的系统之后），所以它越安全和受到保护，证据就越好。 显然，事件源不需要此功能。

事件源还有其他要求-必须存储每个字段的每个修改。 您还应该具有“快照”，这样就不会每次都重新计算“当前状态”。 事件日志不仅是侦听器，还是持久层周围的一个方面，它还是数据模型的核心。 因此从这个意义上讲，它对整个系统设计有更大的影响。 事件日志有用的另一件事是使用系统中的事件。 例如，如果您有一个索引器模块，并且想对更改进行索引，则可以“将”索引器“订阅”到事件，并且每次插入都会触发索引操作。 这不限于索引，还可以用于与外部系统（部分状态）同步状态（一部分是搜索引擎）。

但是，由于存在许多相似之处，我们不能同时使用一种通用解决方案吗？ 审计日志本身就不是一个很好的事件源工具，并且事件源模型不足以用于审计日志。

由于事件源是一种设计选择，我认为它应该起主导作用–如果您使用事件源，那么您可以为非数据修改的业务级操作（登录，视图）添加一些附加的插入内容，并具有很高的水平。表示为事件的级别操作（例如，结帐）。 您还可以获取计划的作业以对条目进行签名（这可能意味着在仅插入模型中进行更新，这很奇怪，但仍然如此）。 而且，您将获得功能全面的审核日志，并且在事件源机制上付出了一些额外的努力。

另一方法有些棘手-您仍然可以使用审核日志查看过去数据的状态，但这并不意味着您的数据模型将仅是插入的。 如果您过多地依赖于审核日志，就好像它是事件源，那么也许您首先需要事件源。 如果只是偶尔的兴趣“两天前在这里发生了什么”，那么只拥有审核日志就可以了。

这两个概念是如此重叠，以至于两者都有。 但总而言之，我会说：

• 您始终需要审核日志，而不一定需要事件源。
• 如果您决定使用事件源，请多走几步以获得正确的审核日志

但是，当然，像往常一样，这全都取决于特定的系统及其用例。

翻译自: https://www.javacodegeeks.com/2017/05/event-logs.html