用通俗日常的刷闸机案例来分析性能，“这个系统撑不撑的住千人并发？”

问题：“这个系统撑不撑的住千人并发？”

地铁站能不能撑得住千人并发？到了高峰期，涌入了一千人（并发数是1000），假设目前开了1台闸机每分钟通行2人（TPS是2，这个情境下应该是每分钟处理的事务是TPM(minute)，只是考量业务的时间单位变了，但还是用习惯的TPS来指代吧），他能不能支持这个高峰期时间段的“千人并发”呢？

答案是“有可能的”，像这个场景，“只是”后面的人的响应时间会拉得非常长。最佳的用户体验排队时间是半小时内，如果超过半小时，这时候就会有人离开换别的交通工具去。对于能否支撑千人的并发，应该怎么去理解？一个系统性能的好坏不是从能不能支持或者撑得了多少个来衡量，还要结合实际业务量、TPS和响应时间。

那从实际上还该还要怎么分析，“千人并发”可能的瓶颈在哪？应该怎么去评估这个地铁系统？

需求分析，了解业务，应该要去测那些，怎么做测试计划

• 获取闸机日志，获得每天的通行人数？哪个时间段人多？高峰期会有多少人？（从日志获取基础数据） 去坐地铁会有什么步骤？
• 从哪个进地铁站口进来（用是什么端进来的）
• 进入地铁站，在闸机前还未进入，可能去洗手间？去充值交通卡？过对面马路？看到人流量大走了？并不是一定就去闸机（分析业务流转和比例）
• 进闸机口（可以看做登陆或者其他关键业务）
• 乘坐地铁（可以看做下单或者其他关键业务–暂时不加入考虑，他不是对本次主要考虑的地铁站内的“千人并发”）。
• 出闸机口（可以看做结算，退出）

性能摸底

• 直接去现场测是否会影响到正常乘车的乘客（搭建测试环境）
• 对闸机做基准测试，要知道闸机的通行能力，才能估算规划要增加多少台（基准测试）

确定测试范围和目标

• 想知道地铁站，在多少人进去闸机范围后会开始后面的排队，最佳人数、最多人数（负载测试）
• 想知道地铁站，在最多人数进入后，会造成系统的瘫痪吗？（压力测试）
• 想知道地铁站，在连续的高负载下，系统是否会有其他问题出现？（稳定性测试）
• 压力测试也要关注事务的成功率，为了可以达到并发和响应的需求，他们可能直接跨过围栏或闸机，直接进入站厅，但这些是我们想要的吗？我们应该考虑只有正常按流程走的正确率。（事务正确率）

测试执行

• 安排多少人，什么时候开始（人员安排）
• 安排多少张交通卡（测试数据准备）
• 怎么安排乘客的进入，乘车多人，模拟平峰、高峰场景，要持续多久、稳定性测试（场景设计）

测试监控

• 在地铁站入口、排队进闸机的位置增加传感器实时知道多少人进来（增加监控节点）
• 要观察监控现在进站的人数，闸机的处理能力，有没人在排队，排队的时间是否能够接受（监控分析）

测试分析

假设从基准测试得知一台闸机的TPS是2（进闸机的流程是乘客刷卡、机器验卡、闸机开关门等步骤组成，这个流程每台机器都有着相对固定的时间或流速的上限），最佳的用户体验排队时间是半小时内。这次结果说明不符合性能需求？千人进站大概多少台闸机能够满足需求？

10台闸机，1000/10/2=50，最后一个人排队时间50分钟
20台闸机，1000/20/2=25，最后一个人排队时间25分钟

10台闸机不够用，超过了半小时了给用户的体验很不好，这时候就会有人离开换别的交通工具去，得出10台闸机不符合需求？

最佳的用户体验排队时间是半小时内，但也有可以接收超过半小时的人，因为大多数还是地铁比较方便快捷，公交、的士也同样可能会堵在路上；有些是“来都来了”（继续排队的人）；
进站人数下降了，可能是有人看到这个站开始排队了走到上一个不堵的站上车（换别的系统）；有些看到人太多了，去吃个饭加个班，换个时间段等人少了再去坐地铁（错峰）；也有可能这个时间段就是没有新的需要去坐地铁，要坐的人都已经进站了；用户是各式各样的。

假设从日志上获取到以下其中一个高峰期模型。高峰期的进站人数是逐渐增加，刚开始的话基本不需要怎么等，但是进站的人数遇上了闸机的处理上限，系统开始拥堵，排队的人开始累加，后面人的排队时间开始延长。

第一个10分钟，这个时间段他们到闸机位置检测，进入了100人，通行了100人，累计通行了 100人
第二个10分钟，这个时间段他们到闸机位置检测，进入了200人，通行了200人，累计通行了 300人
第三个10分钟，这个时间段他们到闸机位置检测，进入了400人，通行了200人，累计通行了 500人， 还有200人需要等待
第四个10分钟，这个时间段他们到闸机位置检测，进入了200人，通行了200人，累计通行了 700人， 还有200人需要等待
第五个10分钟，这个时间段他们到闸机位置检测，进入了100人，通行了200人，累计通行了 900人， 还有100人需要等待
第六个10分钟，这个时间段他们到闸机位置检测，进入了100人，通行了200人，累计通行了1100人，没有等待

分析
在第一波的时候没什么压力， 在第一个10分钟就能处理完， 等待时间最久的是 5分钟。
在第二波的时候开始负载满了， 在第二个10分钟就能处理完， 等待时间最久的是10分钟。
在第三波开始出现了拥堵的现象， 等到了第四个10分钟时内可以处理完，等待时间最久的是20分钟。
在第四波因为要处理前面第三波的人，等到了第五个10分钟时内可以处理完，等待时间最久的是20分钟。
在第五波进站人数开始下降， 等到了第六个10分钟时内可以处理完，等待时间最久的是20分钟。
在第六波进站人数开始下降， 在第六个10分钟内可以可以处理完， 等待时间最久的是10分钟。

这样的情况10台闸机满不满足需求？有没必要加到20台闸机？这里面最久的20分钟，他一定是都在排着队进闸机吗？进入闸机的人可能有着不同的用户的行为习惯，在进入地铁站后他们会立刻刷闸机吗？可能有些人是去洗手间？充值交通卡？借地铁出站口过对面马路？进站了一下就出来了（忘了带交通卡、进地铁站吹空调、看到人流量大了怕堵住就先离开）？等等，他们是先后是到达闸机处（数据到服务器接收到时间是不固定的）可能在路上（网络传输时间）花了5分钟，电梯太多人坐了又等下一趟（网络传输时间异常）再花了5分钟，过安检（有一些系统的挡板，分散一下压力）花了5分钟，去充值（其他业务）又花了5分钟。到了闸机处可能他就可以直接进站了。
是不是存真的有这个“千人并发”的场景？实际上是不是都实时涌入千人呢？有的话是每天都会有这么多人吗？还是某个节假日的高峰期才会有这个场景？现在的瓶颈可能会在哪？是卡在地铁站入口，地铁入口少？在入口被限流了？是卡在电梯慢？是卡在去闸机的路上太远？（响应时间拆分）是卡在充值的机器不够用，排队人很多？是卡在厕所上，厕所不够用？闸机不够用？闸机不够稳定？可以从流程上进行优化？现在有没必要直接加到20台或者30台闸机？还是预想到未来需要能够达到这个级别，预留位置以后再增加？

可以怎么优化呢？

硬件升级

• 例如原本闸机开关的时间，可能要5秒，换了一个更高性能的闸机或读卡器的部件，直接提高了系统的TPS。实际情况升级硬件可能会提高效率，但不能简单粗暴的就升级硬件作为优先的一种解决方案，或者真实的瓶颈还可能在软件和架构，背后可能还要对升级硬件成本、业务量、用户体验等做综合考虑。（内存、硬件之类的升级）

业务优化

• 换一些新的方式，刷卡的话一分钟通过3人（TPS为3），这样通行的效率和业务多样性，避免压力都在一个点上。（提供其他方式，优化总的时间）
• 不用在等第一个人通过时，就可以在后面刷卡，减少闸门打开的时间，代码提高TPS。（队列优化，异步处理）
• 双向闸机，可以在入站和出站时间业务分明的情况下，有空闲的闸机暂时利用起来去处理一部分进站的请求。如潮汐车道。（代码优化）

架构优化

• 增加多台闸机，可以处理更多需要通行的人。（负载均衡，加节点机器）
• 在高峰期启动备用闸机，在平峰的时候不需要的时候就关掉。（弹性扩容，扩展性）
• 增加多台闸机和维护人员，去处理突发状况，如果闸机突然坏了，能不能及时修复故障或切换一台新的闸机。（高可用，为稳定性考虑）
• 增加安检人员，在进入地铁站时就有铁马，分批放乘客进来，避免乘客在车站内拥堵。（限流，或者更友好的提示系统显示正在繁忙中，请耐心等待）
• 增加安检步骤，让乘客可以延长进入闸机的时间，让他晚一点点进入闸机（加挡板，如验证码登录，多了一个需要填写或接收的步骤，就让瞬时的登录请求打散）
• 为保障核心的压力通行，减少服务的类型，本来可以刷卡、二维码的，现在降级了只能刷卡，优先提高这部分人的效率。（降级，保障某些核心业务运行）
• 为避免损伤主要的部件，就像电器里加保险丝及时止损。例如连续高频率持续开关运行3个小时，需要关闭休息一会，避免机器损坏后的过高的维修成本。（熔断）

请求是先后到达服务器的，所以真的需要关注某一分钟的千人并发吗？