Day09-02｜3.2.2 业务处理系统的功能：从采集业务事件到输出可信结果

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

学习目标：掌握业务处理系统（TPS）的主要功能；理解数据采集、事务处理、数据维护、查询输出、控制审计和异常恢复之间的关系；能够将功能需求转化为事务、状态、数据、接口和质量属性设计。

一、TPS 的功能不是简单增删改查

业务处理系统面向组织的日常业务活动，最核心的任务是把现实中的业务事件转换为可信记录，并让这些记录继续支持查询、协同、管理和决策。很多初学者把 TPS 概括为“录入、修改、删除、查询”，但这种概括忽略了业务规则、事务边界、并发、审计和恢复。

一个完整的 TPS 通常包含业务数据采集、输入校验、事务处理、数据维护、查询与输出、控制与审计、异常处理和恢复等功能。它们既有先后关系，也会形成反馈闭环。

二、数据采集功能

数据采集是 TPS 接收业务事件的入口，来源可以是人工录入、终端设备、扫描器、传感器、外部接口、文件导入和消息队列。采集功能要明确数据来源、格式、时间、身份、上下文和业务场景。

人工录入需要界面校验、默认值、提示和重复提交防护，但前端校验不能替代服务端校验。设备采集需要处理时钟、丢包、重复、离线和设备身份；外部接口需要处理协议、签名、版本、超时和未知结果；文件导入需要处理编码、字段映射、批次、部分失败和重复导入。

采集质量可以从完整性、准确性、一致性、及时性、唯一性和可追溯性评价。一个订单缺少客户或金额，可能是完整性问题；同一个客户出现两种编号，可能是唯一性和主数据问题；设备时间错误，可能导致事件顺序错误。

采集必须保留原始事件或足够的接收记录。原始记录有助于重放、审计、故障定位和数据修复，但要注意敏感数据保护和存储成本。对于高价值事务，可以为每次请求生成全局业务号，并把它贯穿日志、数据库、消息和外部调用。

三、输入校验与业务规则

输入校验分为格式校验、范围校验、引用校验、权限校验、状态校验和业务规则校验。格式校验检查类型和结构，范围校验检查数值和长度，引用校验检查关联对象存在，权限校验检查操作者是否有权执行，状态校验检查业务对象是否允许当前动作，业务规则校验检查领域约束。

校验顺序和错误反馈应保持一致。系统可以先拒绝明显非法输入，再检查身份和业务状态，最后执行事务。错误信息应帮助用户修正，但不能泄露敏感内部信息。对批量导入，要返回行号、业务号、错误原因和可重试范围，不能只返回“导入失败”。

业务规则可能变化，适合通过规则服务、配置或版本化模型管理，但核心不变量必须由可靠的数据约束兜底。例如价格不能为负、库存不能小于零、同一票据不能重复入账，不能只依赖页面脚本或可修改配置。

四、事务处理功能

事务处理是 TPS 的核心，把经过验证的业务事件转变为状态变化、数据记录和后续副作用。一次事务通常包括读取当前状态、检查条件、计算结果、写入数据、记录审计和发布事件。

事务应围绕业务不变量设计边界。以转账为例，扣款和入账在一个本地数据库中可以采用事务；若入账在另一个系统，必须定义跨系统一致性、处理中状态、重试、补偿和对账。以订单为例，创建订单、锁定库存和支付可能不是一个物理事务，但可以通过状态机和业务流程保证最终一致。

事务处理还要考虑并发。乐观锁适合冲突较少的更新，使用版本号检测覆盖；悲观锁适合冲突频繁但会增加等待；原子操作适合简单计数和扣减；串行队列适合按资源顺序处理；分段锁或分片可以降低热点竞争。选择机制时要说明冲突概率、延迟、失败和恢复。

五、数据维护功能

数据维护包括新增、修改、删除、归档、恢复、版本和生命周期管理。业务数据通常不应随意物理删除，可能需要逻辑删除、作废、冲正、撤销或版本保留，以支持审计和历史查询。

维护功能应使用主键、唯一约束、外键、检查约束和状态规则保护数据质量。若允许多个系统直接修改同一数据，必须明确权威系统、同步方向和冲突处理。跨系统修改不能只靠“约定大家不要乱改”，需要权限、接口和审计控制。

数据生命周期包括产生、使用、共享、变更、归档和销毁。高频数据可以放在线库，历史数据分层归档；敏感数据需要分级授权、脱敏和加密；删除要符合业务、法律和备份策略。架构师要考虑在线库、缓存、搜索索引、数据仓库和备份中的副本如何同步处置。

六、查询与输出功能

TPS 的查询包括单据查询、状态查询、历史记录、统计汇总、打印、接口返回、消息通知和设备控制。查询输出要明确实时性、一致性、权限、格式和失败语义。

核心交易查询通常要求读取权威数据或可接受的最新状态，统计报表可能来自异步汇总库。若查询结果来自缓存或读副本，应明确延迟和适用范围。不同角色看到的数据也可能不同，系统要在查询层实施数据权限和字段脱敏，不能只靠前端隐藏。

输出要区分“处理结果”和“受理结果”。在线接口返回受理号，说明事务已记录但后续处理尚未完成；异步任务完成后通过状态查询、消息或回调通知。用户体验设计应把处理中、成功、失败、可重试和需人工处理区分开。

七、控制、审计与监督

TPS 必须控制业务操作的权限、职责和流程。身份认证确认“是谁”，访问控制确认“能做什么”，职责分离避免一个人独立完成高风险全流程，审计记录证明“做了什么以及结果如何”。

审计记录应包含业务号、操作人、角色、来源、时间、操作类型、对象、前后状态、结果和失败原因。重要日志要防篡改、限制访问并设置保留策略。业务审计不能只依赖服务器调试日志，因为调试日志可能轮转、丢失或缺少业务语义。

控制功能还包括批次控制、对账控制、异常告警、数据校验和人工复核。批量业务要记录批次号、记录数、成功数、失败数和处理时间；账务系统要进行交易、支付、银行和总账对账；异常要有责任人、处理状态和关闭证据。

八、异常处理与恢复

TPS 的异常包括输入错误、业务拒绝、资源不足、依赖超时、网络中断、数据库故障、消息重复和系统重启。不同异常需要不同处理，不能全部返回同一个错误码或全部自动重试。

临时网络错误可以退避重试，业务规则拒绝不应重试，未知支付结果应先查询和对账，消息消费失败可以重试并最终进入死信。恢复设计要明确是否回滚、是否补偿、是否人工介入以及如何验证恢复后的数据。

批处理应保存检查点和失败记录，支持断点续跑；联机事务要保证提交边界清晰；消息处理要以幂等键避免重复副作用；数据库恢复要结合备份、日志和业务校验。恢复完成不等于进程启动，还要确认业务数据、队列、缓存、索引和审计状态一致。

九、案例：仓储出入库系统

某仓储系统接收采购入库、销售出库和盘点数据，要求库存准确、支持扫码、断网时可暂存，月底需要生成结算数据。近期出现重复扫码导致重复入库、断网后数据冲突和盘点结果无法追溯。

采集层应为设备和操作生成唯一事件号，服务端根据事件号幂等；出入库事务校验物料、仓库、批次和权限，并使用库存版本或原子扣减避免并发覆盖；断网设备使用本地队列，恢复后按顺序上送并处理冲突，不能直接覆盖中心库存；盘点要形成批次和差异记录，保留操作人、时间、原账、实盘和调整原因。

月底结算可以采用批处理，记录检查点、成功失败数量和对账结果。库存查询与结算报表应区分实时事实和汇总数据，定义延迟和口径。通过重复扫码、断网、设备重启、网络重试、库存不足和批处理失败测试验收。

十、练习与详细答案

1. TPS 的数据采集功能为什么不能只依赖前端校验？
2. 输入校验通常包括哪些类型？
3. 数据维护为什么要考虑生命周期和版本？
4. 审计日志与普通调试日志有何区别？
5. 异常为什么不能全部自动重试？

答案：1. 请求可能绕过前端，且前端无法保证权限、并发和服务端数据状态；2. 格式、范围、引用、权限、状态和业务规则校验；3. 数据可能需要归档、恢复、追溯、作废和合规删除，直接覆盖或删除会丢失事实；4. 审计日志具有业务语义、责任主体、前后状态和防篡改要求，调试日志主要服务技术排障；5. 业务拒绝重试无效，非幂等操作重试可能产生重复副作用，未知结果还可能造成重复扣款。

案例题：某在线报名系统允许用户提交报名、缴费和取消。系统出现重复报名、缴费成功但报名状态未更新。请从 TPS 功能角度提出方案。

参考答案：采集层为报名请求生成业务号并防重复提交；报名事务使用用户、活动和名额等唯一约束及状态机；缴费接口以报名单号幂等，处理支付超时和未知结果时先查询，不直接重复扣款；支付成功与报名状态更新之间采用可靠事件、补偿和对账；取消操作校验状态和权限，并按规则释放名额；审计记录用户、设备、时间、前后状态和支付流水；测试重复提交、回调重复、网络中断、名额耗尽、节点故障和补偿恢复。

十一、论文素材与复盘

论文中可从 TPS 功能闭环展开：通过多来源采集和服务端校验保证输入质量，以事务边界、状态机、唯一约束和幂等保证业务事实，使用数据生命周期和权威数据管理保持长期一致，通过查询权限和异步通知输出结果，利用审计、对账、重试、补偿和断点恢复保障可追溯与可恢复。

今日核心记忆句：TPS 的完整功能包括采集、校验、处理、维护、查询、控制、审计和恢复；每个功能都要围绕业务事实和质量属性设计；高级答案不能只写“增删改查”，要写状态、幂等、并发、权限、审计、异常、补偿和验收场景。