如何用5W rmb支持34W并发

在《这垃圾APP，差点毁了70万高考生》一文中，咱们的报考app是用5W rmb 向供应商采购。在报名当天涌入海量考生，并发数飙升至34W，致使系统宕机，拒绝服务，致使考生没法报名，舆情哗然。

那么5W rmb 可否支持34W并发呢？

先不考虑服务器资源是否够，瓶颈会首先出如今数据库读写，假设如今有34W并发，并且根据访问性质来看应该是报名操做，而报名操做是带有数据库CRUD的，Mysql的最大链接数是2000(假设没作分库分表，5W rmb让开发商作分库分表显然是不可能的)，通常用到80%就很不错了，因此链接数用1600来算。而后假设数据库能在100ms内返回(想必也不是什么好机器)，那么一个链接1s能进行10次操做，那么1600链接用满，能进行1.6W次数据库操做。

但这个也只是理论上的峰值，在实际项目中，单库是绝达不到1.6W写入的，而且仍是涉及到多表操做的状况下。

实际上根据《高性能MySQL》第三版 1.5小节，在以下的测试环境中

测试机器Cisco UCSC250
内存384GB
存储引擎是InnoDB
测试的数据集2.5GB
MySQL的buffer pool设置为4GB

因此在内存为384G的机器上，吞吐量不会超过8000。那么384G机器要多少钱呢？

这是64G机器的价格，所以384=646 61.8W=10.8W/年

所以，若是要并发支持到8000，光数据库就至少须要10W/Y。固然，这是假设请求在1s内返回的状况，假设咱们容许服务能在5s内返回，那么此时并发能支持到4W。仍是在不考虑服务器，网络损耗的状况下，其实是远远达不到的。

因此，用5w来支持38w并发，是毫不可能的。

回到咱们刚才的计算，假设数据库吞吐量到达理论峰值，能支持8000用户同时访问，若是每一个客户能等待5s的化，能支持4w用户(前提是这些用户不能够同时访问，须要在5s内作到均匀分布，此时须要经过限流等手段来实现)

要支持8000用户同时访问，又须要多少个应用服务器呢？

假设咱们使用tomcat服务，每一个线程所占空间为8M，那么光tomcat线程就须要: 80008=64000=64G，固然还须要有主机内存，损耗啥的，按照一倍计算就是128G，那么须要是21.8W=3.6W

因此，若是须要支持4w个用户5s延时的访问，须要3.6+10.8= 14.4w rmb

这还只是服务器的钱，不算开发成本在内

那么，若是要支持38w的并发报名呢？这已是一个至关大的并发量了，首先须要考虑的是抛弃掉一部分流量，能够在cdn就直接抛弃，或是nginx，或者直接在应用服务器上，好比在这种状况下就只能保持8000/380000 = 2%，只能有2%的请求容许进来。

能够经过nginx+redis的方式抛弃掉98%的请求，这样能够不用浪费应用服务器资源。或者直接在应用服务器上作操做，抛弃掉没法响应的请求，避免流量拖垮整个系统。