Day09-03｜3.2.3 业务处理系统的特点：高并发交易背后的正确性与可恢复性

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

学习目标：掌握业务处理系统（TPS）的主要特点；理解高事务量、快速响应、数据一致、可靠可用、操作规范、审计追踪和异常恢复之间的关系；能够把这些特点转化为系统架构设计、测试指标和案例分析答案。

一、TPS 的特点决定架构重点

业务处理系统服务于日常、重复、规则明确的业务活动，因此它与分析型、决策型和办公协同系统的关注点不同。TPS 的用户可能很多，事务频率可能很高，每笔事务都可能影响库存、资金、权益或法律记录。系统不仅要“能处理”，还要保证处理结果正确、完整、可追踪，并在故障后能够恢复。

这些特点相互制约。为了提高速度而减少校验，可能损害正确性；为了提高一致性而扩大事务范围，可能降低吞吐；为了提高可用性而自动重试，可能造成重复扣款。架构师必须说明权衡，而不是只写一个孤立的技术名词。

二、事务量大和峰值明显

TPS 通常面对大量相似事务，且事务量具有时间规律。收银在营业高峰增长，选课在开放时瞬间集中，发薪和结算在固定时间批量发生，秒杀和抢票则具有突发峰值。容量设计不能使用平均流量代替峰值。

高事务量要求系统从入口到存储逐层扩展。网关需要限流和负载均衡，应用需要无状态和水平扩展，数据库需要索引、分片、读写分离或批处理，消息系统需要持久化和消费者扩展。任何一层形成瓶颈，整体吞吐都会受到限制。

峰值并不总能通过扩容解决。若业务允许，可以使用预约、排队、削峰、异步受理和分批处理把瞬时压力转为稳定速率。若核心交易不能延迟，应定义优先级和降级策略，保证核心事务不被报表、通知和推荐等非核心任务拖垮。

三、处理速度快和实时反馈

TPS 的联机用户需要及时知道操作是否成功，因此系统要控制端到端响应时间。响应时间包括排队、网络、认证、业务处理、数据库、外部依赖和返回展示。平均值不能掩盖尾延迟，应同时关注 P95、P99 和错误率。

提高响应速度可以减少无效工作、使用索引和缓存、复用连接、缩短事务、并行调用、异步处理非核心步骤。但异步会改变完成语义：用户可能只得到“已受理”，业务实际结果稍后产生。系统必须提供状态查询、通知和失败补偿，不能用快速返回掩盖未完成。

实时性还受到一致性和安全的影响。身份认证、权限检查、加密和审计都会增加开销，但不能为了追求低延迟而删除必要的控制。可按业务风险设计不同路径：查询可以使用缓存，资金操作必须访问权威事实并留下审计。

四、数据一致性和完整性

TPS 的核心特点是业务数据不能随意矛盾。库存、账户、订单、票据和号源都存在不变量。例如库存不能低于零，账户不能重复扣款，同一座位不能卖给两人，订单金额必须等于明细汇总。

数据一致性需要数据库约束、事务、并发控制、状态机和对账共同保证。数据库唯一键和检查约束是最后防线；应用层规则提供业务语义；状态机拒绝非法状态跳转；消息和补偿处理跨服务变化；对账发现和修复长期偏差。

一致性有强弱和范围。单个数据库内的关键更新可以采用原子事务；跨服务操作常采用最终一致和补偿。架构师必须标明哪些状态允许短暂不一致，最长多久恢复，谁负责补偿，用户如何看到处理中状态。

五、可靠性和可用性

TPS 不能轻易丢失业务记录。可靠性要求事务正确完成或明确失败，可用性要求用户在需要时能够访问系统。二者相关但不同：系统可能可访问却返回错误数据，也可能为了保护数据而暂时拒绝服务。

可靠设计包括持久化、事务日志、备份、复制、故障检测、自动切换、重试、幂等、补偿和恢复演练。可用性设计包括冗余、负载均衡、健康检查、限流、熔断和降级。自动切换后要验证数据是否同步，重试前要判断操作是否幂等，不能把“自动化”当作正确性的保证。

故障恢复要定义 RTO 和 RPO。RTO 是恢复服务所允许的最长时间，RPO 是故障时允许丢失的数据时间范围。不同业务的目标不同，关键支付和核心交易可能要求更严格；普通统计可以允许较长恢复和一定延迟。

六、操作规范和易用性

TPS 通常由大量业务人员或公众使用，操作过程应符合业务规范，输入提示和错误反馈应清晰，关键操作要二次确认或职责分离。系统不能只考虑开发者习惯，要考虑培训、权限、岗位轮换、移动设备和应急操作。

操作规范可以通过流程、表单、校验、状态、角色和审批实现。对于高风险操作，采用四眼原则或双人复核；对于批量操作，先预览影响范围再确认；对于撤销和冲正，保留原记录并生成反向业务事实，不直接覆盖历史。

易用性与安全性要平衡。频繁强制复杂密码可能促使用户绕过安全措施；过度简化确认可能增加误操作。架构师应根据业务风险和用户场景设计认证、授权、超时、操作确认和审计。

七、可追溯和可审计

TPS 产生的记录可能被用于财务、监管、客服和争议处理，因此需要回答谁在什么时间，以什么身份，从什么终端，对什么对象做了什么，结果如何。业务审计要与业务号和状态关联，能够重建关键事务过程。

可追溯不仅是保存日志，还包括版本、来源、前后状态、规则版本和数据血缘。订单价格由哪个规则版本计算，支付使用哪个渠道，库存由哪次操作扣减，都可能需要回放。审计数据应防篡改、分级访问并设置保留期限。

八、异常处理和恢复

TPS 的异常包括输入错误、权限不足、业务规则拒绝、资源不足、依赖超时、重复请求、消息乱序、数据库故障和数据损坏。异常分类决定是否重试、是否回滚、是否补偿以及是否通知用户。

临时网络异常可以退避重试，但要设置次数和总超时；业务规则拒绝应立即返回并提示修正；外部支付未知结果应查询和对账；消息无法处理应进入死信并告警；数据损坏应从备份和日志恢复并进行业务校验。所有自动机制都要防止故障放大。

恢复后要检查残留状态。进程启动不等于业务恢复，可能仍有未处理消息、重复锁、缓存旧值、部分账务和缺失索引。恢复流程应包括数据核对、队列处理、缓存重建、业务抽样和用户通知。

九、案例：银行柜面交易系统

某银行柜面系统处理存款、取款、转账和冲正，要求高峰期快速响应，交易必须可审计，网络异常时不能重复扣账。系统上线后出现柜员提交超时后再次操作，客户账户被重复扣款。

TPS 特点要求系统把超时与失败区分。服务端以柜员流水号和业务交易号建立幂等记录，提交后即使响应丢失，重复请求也返回原结果；处理中状态通过查询或后台确认完成；外部核心账务返回未知时，不允许直接重试扣款，应查询交易状态并进行日终对账。

系统还应记录柜员、网点、终端、时间、账户、前后余额、授权人和规则版本；对大额交易实施双人复核；使用数据库约束和事务日志保证本地一致；通过容灾、备份、切换和演练满足恢复目标。性能验收要同时看响应分位数、成功率、重复率、账务一致性和审计完整性。

十、综合练习与详细答案

1. TPS 为什么同时关注速度和正确性？
2. 为什么峰值事务量不能只靠平均流量估算？
3. TPS 的可用性和可靠性有什么区别？
4. 为什么自动重试可能造成严重问题？
5. TPS 的特点如何影响测试设计？

答案：1. 用户需要及时反馈，但交易结果又会影响资金、库存和权益，速度不能以牺牲正确为代价；2. 峰值会导致排队和资源饱和，平均值掩盖突发压力；3. 可用性关注能否访问服务，可靠性关注事务是否正确完成、数据是否不丢不重；4. 非幂等操作重试可能重复扣款、重复发货或重复创建，未知结果必须先查询和对账；5. 测试要覆盖高并发、峰值、重复、超时、故障、恢复、数据一致、审计和业务降级，而不只是成功路径。

案例题：某库存系统在大促期间响应时间达标，但出现库存负数和重复扣减。请结合 TPS 特点分析。

参考答案：系统只把响应时间作为目标，忽略了数据一致、并发控制、幂等和业务不变量；可能使用缓存库存作为最终依据，扣减操作非原子，重复请求没有业务键，失败重试没有判断原结果。应以库存不能小于零、同一订单只能成功扣减一次为核心不变量，采用原子扣减或版本控制、订单级幂等、唯一约束和明确状态机；缓存只作读优化，最终扣减访问权威数据；消息重试采用退避和去重，异常进入补偿；通过并发扣减、重复提交、超时、节点故障和对账测试验证。

十一、论文素材与复盘

论文中描述 TPS 特点时，可围绕高事务量、快速响应、数据一致、可靠可用和可追溯展开：使用无状态扩展、限流削峰、缓存和异步提高处理能力；用事务边界、唯一约束、锁、状态机和幂等保护正确性；用冗余、备份、重试、补偿和对账保证恢复；用业务号、审计和全链路监控支撑追踪；最后用峰值、故障、重复和恢复演练验收。

今日核心记忆句：TPS 的高并发不是唯一重点，正确、及时、可靠、可追溯和可恢复同样重要；架构设计必须同时保护业务不变量和用户体验；任何缓存、重试、异步和扩容方案，都要说明一致性、重复、故障和审计代价。