Day09-01｜3.2.1 业务处理系统的概念：把业务事件可靠地变成组织事实

教材定位：系统架构设计师教程（第 2 版）第 3 章“信息系统基础知识”第 3.2.1 节。

学习目标：理解业务处理系统（TPS）的定义、对象和作用；掌握事务、业务事件、状态、联机处理与批处理等概念；理解 TPS 在信息系统中的基础地位，以及架构师如何设计一致性、幂等、审计和恢复机制。

一、TPS 是信息系统的事实生产层

业务处理系统（Transaction Processing System，TPS）是面向组织日常业务活动，对业务事务进行采集、校验、处理、存储和输出的信息系统。订单、收款、发货、挂号、转账、考勤、库存出入库、机票预订，都属于典型业务事务。

TPS 的核心不是界面，而是把现实世界中的业务事件转化为可靠、可追溯、可供后续系统使用的数字事实。用户点击“提交订单”只是开始，系统还要验证身份、商品、价格、库存和支付状态，保证结果不会被重复执行或错误覆盖，并在故障后能够恢复和对账。

二、业务事务的基本特征

第一，事务具有业务意义，不是单纯的数据库 SQL。第二，事务通常需要原子性，要么整体成功，要么按规则失败或补偿。第三，事务应具备可追踪标识，便于审计、查询和对账。第四，事务会改变业务对象状态，并可能触发后续流程、消息和报表。第五，事务必须在权限、规则和数据质量约束下执行。

数据库事务的 ACID 特性为很多 TPS 提供基础，但业务事务往往跨越数据库、消息、支付和库存等多个资源，不能简单用一个本地事务覆盖。架构师要区分本地原子性和跨系统业务一致性，明确哪些操作必须同步完成，哪些可以异步处理，哪些失败需要补偿和人工介入。

事务还具有时间和顺序要求。银行转账、库存扣减和号源预约存在并发竞争；日志和审计要求保留发生时间；批量结算要求按批次和检查点恢复。系统要根据业务定义顺序、重复和迟到事件的处理策略。

三、联机事务处理与批处理

联机事务处理（OLTP）强调用户操作的即时响应和事务并发，典型场景是收银、下单、挂号和支付。设计重点包括响应时间、并发控制、锁、连接池、事务隔离、幂等、超时和用户反馈。

批处理按批次集中处理大量记录，适合工资、月结、对账、数据归档和批量通知。批处理关注吞吐、批次边界、资源窗口、断点续跑、失败重试、结果核对和作业依赖。批处理不意味着可以忽略正确性，批量操作更需要可追溯和可恢复。

很多系统采用混合模式：在线交易先记录核心事实，非核心统计和通知异步批量处理；白天实时受理，夜间批量对账；设备边缘侧实时采集，中心侧周期归档。架构师必须定义实时结果和批处理结果之间的关系，避免用户看到的状态与账务事实不一致。

四、TPS 的输入、处理和输出

TPS 输入包括用户录入、设备采集、外部接口、消息和文件。输入环节需要身份认证、格式校验、业务规则检查、重复检测和权限判断。处理环节包括状态更新、计算、事务控制、资源占用和事件产生。输出包括确认结果、业务单据、状态查询、消息、报表源数据和审计记录。

输入数据必须可识别和可验证。金额、数量、时间、客户和商品不能只靠前端校验；服务端要再次校验，并检查业务状态和授权。外部接口可能重复发送、乱序、超时或返回未知结果，TPS 要用业务号、幂等键和状态查询处理。

输出也要定义语义。“提交成功”是已受理、已持久化、已完成，还是仅进入队列？支付处理中能否当作支付成功？订单创建成功但库存暂未确认时，用户应看到什么状态？这些语义直接影响架构、前端和客服处理。

五、事务边界与一致性

事务边界应围绕业务不变量确定。业务不变量是任何时刻都必须成立的规则，例如库存不能小于零、账户余额不能被重复扣减、订单金额必须与明细汇总一致。边界太小可能无法保护不变量，边界太大则锁竞争、延迟和失败范围增加。

单体系统内可以利用数据库事务保持多个表的一致，但仍需注意外部副作用。订单写入成功后发送通知，如果通知失败不能回滚已经完成的订单，通常需要事务消息、可靠事件表或补偿任务。跨服务场景可采用最终一致、Saga、TCC、可靠消息和定期对账等方法，选择取决于业务可接受的中间状态和补偿能力。

一致性不是越强越好。支付扣款、库存扣减和账务记账可能需要强约束；推荐、统计和通知可以允许延迟。架构师应按业务优先级划分一致性等级，并把状态、超时、补偿和人工处置写清楚。

六、幂等、重复与并发

幂等表示同一业务操作执行一次或多次，结果与执行一次相同或不会产生额外错误副作用。网络重试、用户重复点击、消息重复投递和客户端超时都会导致重复请求。TPS 必须给创建、扣款、发货、退款等关键操作设计幂等键和唯一约束。

幂等键应具有业务语义和合理生命周期，不能随意使用每次请求都变化的随机值。服务端要保存请求结果或状态，重复请求返回已有结果，处理中则返回处理中。对不可幂等的外部操作，需要通过查询、对账、锁定或人工确认避免重复。

并发控制包括乐观锁、悲观锁、版本号、原子操作、串行队列和分段资源。库存、号源和账户等热点资源要关注锁粒度、等待、死锁和超卖。架构师应根据冲突概率、延迟目标、数据规模和故障恢复选择机制。

七、审计、追踪与恢复

TPS 产生的业务事实通常具有法律、财务或运营价值，需要记录操作人、来源、时间、业务号、前后状态、关键输入摘要、结果和错误。审计日志要防篡改、分级访问并有保留期限。普通调试日志不能替代业务审计。

恢复设计包括备份、日志、检查点、重试、断点续跑、回滚、补偿和对账。联机事务要关注故障时是否部分提交；批处理要保存已完成分片和失败记录；外部支付未知状态要通过查询和对账确认，不能盲目重试扣款。

八、案例：在线购票 TPS

某平台销售演出票，用户可以选座、锁座、支付和退票。热门场次出现重复售票、支付成功但座位未确认和退票状态不一致。

架构上应把座位作为有状态资源，定义可售、锁定、已售、退回和失效状态；锁座使用带过期时间的业务记录和并发控制，支付请求使用订单号幂等；支付成功但回调延迟时，订单进入处理中，由查询和对账任务确认；退票必须定义订单、支付和座位释放的状态转换，失败时进入补偿或人工队列。

数据层用唯一约束防止同一座位同场次重复出售，服务层用状态机拒绝非法跳转，消息层使用业务号去重，运营侧提供对账和人工处理。验收应覆盖重复点击、超时重试、支付回调重复、锁座过期、节点故障和退票失败。

九、练习与详细答案

1. TPS 的核心作用是什么？
2. 联机处理和批处理的主要差异是什么？
3. 为什么数据库事务不能自动解决跨系统业务一致性？
4. TPS 为什么必须设计幂等？
5. “请求进入队列”能否直接表示业务完成？

答案：1. 把业务事件可靠地转化为可追踪、可使用的业务事实；2. 联机强调即时响应和并发交互，批处理强调批量吞吐、作业依赖和断点恢复；3. 外部服务、消息和多个数据库不受同一个本地事务控制，需要最终一致、补偿、可靠消息或对账；4. 重试、重复点击和消息重复普遍存在，幂等可避免重复扣款、重复创建和错误状态；5. 不能，进入队列通常只是已受理，必须明确处理完成的定义和查询状态。

案例题：某支付系统收到客户端超时重试，出现同一订单扣款两次。请从 TPS 概念提出改进方案。

参考答案：系统把网络超时误认为业务失败，缺少订单级幂等键、支付状态机和未知结果处理；重试直接调用扣款接口，没有先查询已有支付结果。应使用订单号或支付流水号作为幂等标识，在服务端建立唯一约束和状态记录；将待支付、处理中、成功、失败和待确认状态区分；客户端重试时返回已有状态，处理中通过查询或异步通知确认；外部支付异常采用查询、对账和人工补偿，禁止无条件重复扣款；记录全链路业务号并进行重复回调、超时和故障演练。

十、论文素材与复盘

论文中可以把 TPS 写成“业务事实可靠性”主题：通过业务号和状态机定义事务生命周期，使用唯一约束、幂等、并发控制和事务边界保证核心不变量；用可靠消息、补偿、对账和人工处理解决跨系统一致性；通过审计、追踪、备份、检查点和断点恢复保证可追溯与可恢复；最后用重复请求、超时、故障和峰值测试验证。

今日核心记忆句：TPS 不是简单增删改查，而是业务事件到可信事实的转换器；联机关注响应与并发，批处理关注吞吐与恢复；事务边界围绕业务不变量确定；幂等、状态机、审计、补偿和对账是高级系统架构师必须写出的可靠性措施。