如何基于事件流去构建业务系统

本文的思路来源于https://queue.acm.org/detail.cfm?id=3321612

随着产品复杂度的提升和微服务架构的流行，一个业务系统背后的数据存储系统也越来越复杂。

以微信公众号为例：

• 当你在回复框输入文字时，后台会根据你的关键词响应合适的内容。这个就是全文搜索引擎，将一系列文本内容拆解为一个个关键词，然后根据关键词，找到关键词对应的内容；
• 作为公众号的运营者，会经常去查看后台的阅读量、关注人数等数据，这些数据的计算依赖于微信的数据仓库系统。数据仓库是很多企业用来进行商业分析的后台系统，其核心是列式存储。

除此以外

• 一些大号背后可能还会存在风控系统，去实时监控参与优惠活动的羊毛党，为了识别用户的风险指数，开发者会使用类似于Pub/Sub的消息系统去实时存储用户的行为数据，供流处理系统分析；
• 像最近的京东618等大促活动，为了避免突然而来的流量对数据库造成影响，开发者会使用缓存系统，提高一些read-only的请求的回复效果。

在业务系统拥有这么多数据存储系统的情况下，更改其中一个数据存储系统的记录，都需要保证其它的数据存储系统的记录也同时发生更改。任意一个数据存储系统得更改都影响到其它的数据存储系统，业务系统背后要是有五个服务，那意味着要更改五次，还得保证每一次更改都能解决可能出现任何的问题：

• 软件、硬件突然发生故障（例如进行到一半时数据写入）；
• 程序突然发生崩溃（例如执行到一半的操作）；
• 系统之间突然发生网络中断，意外地切断了数据存储系统与应用的连接，或数据存储系统之间的连接。

等等。随着业务增长，这个系统得复杂到什么程度。

使用事务?

长久以来，传统的关系型数据库都是事务来解决操作数据时可能出现的任何问题，概括的来讲就是所谓的ACID：原子性 （Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。

因此在一个庞大的业务系统中，也需要事务去保证对业务系统其中任何一个数据存储系统的更改都会如实的反映在业务系统其它的数据存储系统之上，即分布式事务。业界有两种主流的分布式事务解决方案：

• 使用一个单一的支持事务的分布式OLTP数据库去存储业务系统所有数据；这类的代表是Google's Cloud Spanner、TiDB等New SQL数据库，可扩展、高容错且支持分布式事务。但并不是所有业务都天然适合OLTP关系型数据库，像缓存这种业务使用类似Redis的NoSQL数据更为合适
• 使用各种各样的分布式事务协议去协调各个数据存储系统的事务；这类的协议基本上都是以XA模型、两阶段提交为核心。不过这类的分布式事务协议都有着或多或少的缺点，例如XA事务不支持乐观锁和死锁检测机制。更别提还有很多系统不支持分布式事务协议。

基于event-log搭建系统

有一个简单办法解决这个问题:

当一个数据存储系统发生变更时，先发送一条event到update log，然后其余的数据存储系统再去解析这个update log。因为log是有序的，所以类似于下图中的搜索引擎和数据库只要按照log上event的顺序,以相同的顺序更改本地的数据记录,就可以保证所有的数据存储系统上的数据记录是一致的。

基于event-log的架构保证了

• 当订阅这个log的数据存储系统产生问题时，订阅者只需要重放这个log的event，即可恢复数据。
• 所有的订阅这个log的数据存储系统看到的event顺序都是一样的，因此在并发写入的情况下，不同的数据存储系统的数据也不会出现不一致的情况。

这个架构被称为Online Event Processing，缩写为OLEP。

Log抽象

在OLEP中，最核心部分的莫过于Log。那么这个Log应该具有什么样的特征，或者说这个Log背后的系统应该要满足什么样的特性？

• 持久化：要保证数据不能因为服务器宕机等原因导致丢失，因此数据要持久化到磁盘中，同一个数据要备份到不同机器上。
• 只增不减：新的event只能添加到log的结尾，而不修改已记录到log上的event。当然，也允许系统对Log上过旧的event记录进行删除。
• 顺序读：所有读取这个log的订阅者只能按照log上记录的event顺序进行读取。这意味着每一个event都应该具有一个顺序id。
• 可分区：单独的一个Log是不可能支持对数据的高吞吐，因此Log可以使用多个分区存储event，分区之间的event不一定有序，但是分区内部的event保证有序。

除此以外，作为OLEP系统的订阅者，还应该需要：

• 维护一个日志消费状态，以保证不遗漏数据。
• 读取Log的程序必须要是单线程的，以保证读取的Log是有序的。

满足这些特性的系统，开源的有Apache Kafka、Pulser等等，具体不再详述。

缺点

OLEP并不能说全无缺点。OLEP相比于传统的关系型数据库，它把关系型数据库内部的Log具象到了外部，因此相比于关系型数据对事务实现的完整性，只能说OLEP是一个最终一致性的系统。

在OLEP系统中，如果有使用者同时读取两个不同的数据存储系统，有可能会出现读数据不一致的情况，即隔离性（Isolation）是没有实现的。

小结

在一个拥有庞大的数据存储系统的业务中，要保证它们的数据一致性是一件很痛苦的事，OLEP提供了一种相对高效和简洁的方式去维护各个系统之间的数据一致性。

相比于关系型数据库使用Log在内部实现事务，OLEP将Log提到了应用级别去处理系统之间的事务。通过Log这个中间媒介，OLEP系统拥有接近线性的可扩展性，减低了数据存储系统之间的复杂度，也保持了不错的性能。

因此，在一个拥有许多个数据存储系统的业务系统中，值得尝试OLEP的处理方式。