1.3.2 传统事务处理

IT互联网企业往往会用不同的应用程序处理各种业务，如内部使用的企业资源规划（ERP）系统、客户关系管理（CRM）系统、面向客户的Web应用程序。这些系统一般都会分层设计：计算层就是应用程序本身，用于数据计算和处理；存储层往往是传统关系型数据库，用于数据存储，如图1-5所示。

图1-5 传统事务处理系统架构

可以发现，这里的应用程序在处理数据的模式上有共同之处：接收的数据是持续生成的事件，如用户的点击行为、客户提交的订单或操作人员发出的请求。在处理事件时，应用程序需要先读取远程数据库的状态，然后按照处理逻辑得到结果，将响应返给用户并更新数据库状态。一般来说，一个数据库系统可以服务多个应用程序，它们有时会访问相同的数据库或表。

这就是传统的事务处理架构。系统处理的连续不断的事件其实就是一个数据流，而对于每个事件，系统都在收到之后进行相应的处理，这也是符合流处理的原则的。因此可以说，传统的事务处理就是最基本的流处理架构。

对于各种事件请求，事务处理的方式能够保证实时响应，好处是一目了然的。但是，这样的架构对表和数据库的设计要求很高；当数据规模越来越庞大、系统越来越复杂时，可能需要对表进行重构，而且一次联表查询也会花费大量的时间，甚至不能及时得到返回结果。于是，作为程序员，就只好将更多的精力放在表的设计和重构，以及SQL的调优上，而无法专注于业务逻辑的实现，这种工作费力费时，却无法直接体现在产品上。

那有没有更合理、高效的处理架构呢？