事务数
Transaction Per Second
📌 概念释义与技术定位 (Definition & Overview)
事务数（TPS）是衡量数据库或分布式系统在单位时间内成功处理并发事务请求次数的核心性能指标，直接反映系统的吞吐能力与并发控制效率。
事务数（Transaction Per Second, TPS）定义为系统每秒内成功提交并满足原子性、一致性、隔离性、持久性（ACID）要求的事务请求数量。作为数据库与大数据领域的基准指标，它不仅是评估系统并发处理能力的量化标尺，更是衡量分布式架构下数据一致性保障机制有效性的关键参数。在从单体数据库向微服务架构演进的过程中，TPS 已成为衡量系统弹性伸缩能力与高可用设计水平的核心维度。
在现代计算架构中，事务数不仅是单一数据库的性能标尺，更是分布式系统整体吞吐能力的“瓶颈”所在。其核心价值在于量化系统在强一致性约束下的最大并发承载量，直接决定了业务在复杂数据操作场景下的响应速度与系统稳定性。随着 NoSQL 与 NewSQL 技术的普及，TPS 的评估维度已从单纯的读写速度扩展至分布式锁竞争、网络延迟容忍度及跨节点数据同步成本的综合考量，成为架构师进行容量规划与故障演练的核心依据。
⚙️ 核心架构与工作机制 (Technical Mechanism)
底层机制上，TPS 的实现依赖于事务管理器（TM）对并发请求的精细调度与资源隔离。在单机架构中，主要依靠锁机制（如行锁、表锁）与 MVCC（多版本并发控制）来协调并发访问，确保事务在提交前独占数据资源，防止脏读与幻读。而在分布式环境下，机制更为复杂，涉及两阶段提交（2PC）或基于 Paxos/Raft 的共识算法来协调跨节点事务。系统通过解析 SQL 解析器、优化器生成的执行计划，将并发事务拆解为具体的数据页操作，利用内存缓冲池减少磁盘 I/O，并通过异步日志写入（WAL）保障持久性。TPS 的瓶颈通常出现在锁等待导致的上下文切换增加、分布式网络延迟引发的共识同步超时，以及大事务导致的资源持有时间过长。
📖 权威专著深度引证与原文精粹 (Expert Book Insights)
2 本专著引用《全栈性能测试修炼宝典 JMeter实战（第2版）2021》
陈志勇 刘 潇 钱 琪
“性能测试的结果中需要每秒事务数（TPS）。 虽然JMeter默认每个请求统计成一个事务，但有时候多个操作统计成一个事务更符合测试场景，此时可以利用JMeter事务控制器来完成。”
《视听媒体微服务技术架构规范》
报批稿
“TPS 每秒事务数（Transaction Per Second）”
🚀 典型应用场景 (Industrial Applications)
金融核心交易系统（如支付结算、账户余额更新）
电商大促期间的高并发库存扣减与订单创建
实时数据仓库的 ETL 数据清洗与聚合计算
物联网（IoT）设备数据的实时写入与状态同步
⚖️ 技术优势与工程权衡 (Trade-offs & Pros/Cons)
🟢 核心优势与技术特性
- + 能够直观量化系统在高并发场景下的真实处理能力
- + 直接关联业务连续性，是保障数据一致性与系统稳定性的核心指标
- + 为系统容量规划、资源扩容及故障演练提供明确的量化基准
🔴 工程考量与潜在挑战
- - 高 TPS 往往意味着更复杂的锁竞争与网络开销，可能牺牲部分延迟表现
- - 在分布式架构下，TPS 受限于网络带宽与共识协议，存在明显的物理天花板
- - 单纯追求 TPS 可能导致长事务阻塞，引发系统雪崩效应
