我重点解释TPS指标（因为并发⼤家都理解）。我最近处理的⼏个项⽬都是 以TPS作为衡量指标。实际原理就是系统与系统之间TPS关系问题。假设⼀个交 易链路中，A系统与B系统对接，A访问B，如果单压A的最⼤TPS是100，⽽单压 B的最⼤TPS是50，那么压测整个链路过程中，⼀定超不过50，并且，还有可能 导致A或B宕机。这个原理是⾮常简单的，就好像⽔⻰头，前⾯的⽔⻰头⼤，后⾯ 的下⽔道太窄，那么必然导致请求积压，如果没有很好的超时处理的话，A和B都 有可能发⽣宕机的问题。 所以，如果分布式系统（或者外部调⽤系统），逐个压测的过程中，⼀定要 确保Consumer端的处理能⼒⼀定要⼤于Provider端，否则就会出现严重问题。 说⼀个真是案例，邮储说他会以TPS 500（说实话，我觉得邮储的这个限流 控制做的真棒，说给保险公司分多少流量，就以TPS能控制，我觉得还是很强 的）的流量给保险公司分流量。项⽬组以300并发的⽅式进⾏压测，测试到 600TPS。我觉得测试结果的重点不是在于300并发，⽽是在于600TPS，最后项 ⽬组不断提⾼并发度，测试到系统最⼤tps为928TPS。那么这就达到了压测的⽬ 的。邮储作为上游500tps，⽽下游系统928tps，必然承接得住邮储的业务。 关于⼀般情况下多少TPS可能满⾜⽇常电商交易。我现在的经验来看，我觉 得200tps是⾜够⼤的⼀个处理速度，⼀般电商促销活动顶多是70-80tps，超过 100的都少，所以系统如果能达到200tps真是⼀个⽐较⾼的数值了。⽽想邮储这 种特别⼤的tps的真的是⾮常罕⻅的
