关于保险网销系统大并发背景下的思考

1、业务分析

     1、正常的网销系统业务流程：

   2、业务特性

          大幅推广、瞬时抢购、定时上架、瞬间并发量大。

2、技术与挑战

     之前有幸参与了某公司团险在线销售项目，按照极限标准来进行系统设计，背景如下，某企业与保险公司签订了团险合作业务，企业在线员工30W人，企业会安排员工统一在某天早上6：00-8:00之间完成所有人员投保工作。

          购买流程主要包括：详情页面、测算页面、信息录入页面、确定页面，由于浏览器存在缓存机制，部分静态文件不需要再次请求服务器，为了使带宽有充足的传输能力，我们计算时，将不考虑浏览器缓存。

如下是通过LR压测的报告来分析现状系统的一个性能状况(这是之前系统的一个压测情况，不太理想)

虚拟用户数	允许时间（s）	总的吞吐量（byte）	吞吐率（byte/s）	总点击次数（请求次数）	每秒点击次数	通过事务	失败事务	通过事务平均时间	失败事务平均时间
200	319	290,312,355	907,226	25,662	80	728	271	2.2750	0.8470
250	326	302,793,940	925,975	25,485	77	692	352	2.1160	1.0760
300	330	291,530,586	880,757	22,132	67	403	517	1.2180	1.5620

从报表上可以计算出，我们取虚拟用户为200 的数据，平均每个请求大小为 =（总吞吐量/总请求数）=290,312,355/25,662 = 11312b = 11Kb = 1.4KB

 计算每个事务（每个完整购买的流程）包含的请求数量（失败的先不纳入） 25,662/728 = 35 个

说明：TPS 与 QPS 不是一个概念，如下描述的事务表示一整个购买流程。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

结论：通过压测，我能能得到一个TPS的总流量为 35*1.4=49KB

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

   

2.1并发数预估  

    系统用户数：可能使用系统的用户数

    在线用户数：在我们系统中访问并操作的用户数

    并发用户数：（在本文中，指的是某块业务的并发数）

    计算平均并发数：C=nL/T （n:表示登录用户数，即在线人数 ，L：平均时长，T指考察时间）

    峰值并发数 C' =C+3*(根号C)

     说明：结合团险在线销售经验，用户平均在2分钟之内能完成这个销售流程 

        C = 300000*1/120= 2500

        C‘ = 2500+ 3* √2500=  2650

2.2带宽计算（主要是计算上行带宽，一般企业中，下行带宽可以认为是没有限制的）

        备注： 在计算机网络中，网络传输率采用的是b/s(比特每秒),所以传统上我们所说机房100M带宽指的是100Mb/s  ， 1B（字节）=8bit（比特）

        30W员工，集中投保时间为6:00-8:00

        TPS（一个全流程为一个事务） = 300000/(2*3600) = 42  ,经过上面的压测，计算的理论值，一个TPS的流量为49KB，那么带宽为 49*42KB/s = 2058KB/s

= 2MB/s = 16Mb/s  因此，需要为了这次活动，必须独享16M（上行带宽）带宽.

      极限峰值情况，根据并发情况，刚才计算一个TPS为49KB ，一个TPS包含4个页面，那么每个页面为12KB左右(我这边算平均值，应该使用流量统计工具，可以具体算出每个页面大小)。那么需要的带宽为 2650 *12=31800KB/s=31KB/s=248Mb/s ,当前服务器带宽为25M带宽，因此这个是相当不现实的。 因次秒杀活动/其他活动是，应该新增的网络带宽，必须和运营商重新购买或者租借。 为了减轻网站服务器的压力，需要将秒杀商品页面缓存在CDN，同样需要和CDN服务商临时租借新增的出口带宽 。因此建议，如果需要搞活动，最好是能上CDN。

3.3系统吞吐能力

     通过测试报告，我们可以看出，系统最优（200个并发用户的时候） TPS = 728/319=2.3个/S ,为了满足当前团购活动，系统要求的是  TPS（一个全流程为一个事务） = 300000/(2*3600) = 42  个/S  相差了21倍左右，因此理论上在带宽允许已经负载均衡的情况下，需要21台服务器才能支撑当前活动，目前最多能提供4台服务器。因此系统吞吐性能必须优化至少5倍以上。如下是当时的系统流程，并行结构。

     如上测试报告所述：QPS = 25,662/319= 80  ，而本次活动要求的QPS = （一个购买流程总请求数 35）*  300000/2*3600= 145  。

 

    

1、在后续的排查过程中 发现核保设计查询的数据库比较大，且有多表关联查询，因此数据库SQL优化是必须要做的一部，加上一次关联查询话费了3S 中，如果我们能优化为1S，那么系统整个吞吐能力提升了3倍，如果能优化到 100ms，那么就是提升30倍，那么这个服务器数量理论上也将减少30倍。

2、高并发服务器建议调小 TCP 协议的 time_wait 超时时间，：操作系统默认 240 秒后，才会关闭处于 time_wait 状态的连接，在高并发访问下，服 务器端会因为处于 time_wait 的连接数太多，可能无法建立新的连接，所以需要在服务器上 调小此等待值，在 linux 服务器上请通过变更/etc/sysctl.conf 文件去修改该缺省值（秒）：      net.ipv4.tcp_fin_timeout = 30

3、调大服务器所支持的最大文件句柄数（File Descriptor，简写为 fd）。 ：主流操作系统的设计是将 TCP/UDP 连接采用与文件一样的方式去管理，即一个连接对 应于一个 fd。主流的 linux 服务器默认所支持最大 fd 数量为 1024，当并发连接数很大时很 容易因为 fd 不足而出现“open too many files”错误，导致新的连接无法建立。 建议将 linux 服务器所支持的最大句柄数调高数倍（与服务器的内存数量相关）。

4、调整tomcat连接池数量，线程大小默认是200 ，不是越多越好，线程越多，涉及到的线程切换会消耗大量的cpu资源。

 

3.4 如果在调优到极限的情况下（且不添加硬件的情况下），还是满足不了。那么，我们只能采用限流措施，进行重启与过载保护。

如果系统发生“雪崩”，贸然重启服务，是无法解决问题的。最常见的现象是，启动起来后，立刻挂掉。这个时候，最好在入口层将流量拒绝，然后再将重启 。

秒杀和抢购的场景，流量往往是超乎我们系统的准备和想象的。这个时候，过载保护是必要的。如果检测到系统满负载状态，拒绝请求也是一种保护措施。在前端设置过滤是最简单的方式，但是，这种做法是被用户“千夫所指”的行为。更合适一点的是，将过载保护设置在CGI入口层，快速将客户的直接请求返回。因此需要引入网关平台。

转载于:https://my.oschina.net/wanhonghui/blog/849388