HA架构关于应对高并发

前言：新项目上线，考验高并发，预选使用LR录制脚本跑脚本，考虑到搭建，使用简便的jmeter工具，来跑500、1000、1500、2000的并发并打出报告，中间经历过tomcat与jmeter优化。

高并发下考虑的层面系统 + nginx(理论3W左右) + tomcat--- 标签（tcp）

实际操作：

1、

方案：2000个线程，采取并大（可以选择单个线程间隔），错误日志实时打印

当并发量达到1740时候，出现报错，报错日志在附件jmeter.txt.

此时服务器，cpu占用量为2.5% 高于平时1.5%-2%，

Memcache大概多消耗1.4G-2G之间。

Tcp连接数监控从150左右飙升至2400左右，无影响

此时：服务器情况良好

另：tcp连接超过3000时候（昨天测试接口4700并发）。出现cpu报警，开始优化架构

开始排查：

发现报错，不是服务端报错，是不是jmeter工具内存飙高，发现自己pc内存吃紧，关闭其他程序，并且调整jmeter内存，再跑。

2017/04/25 13:59:59 INFO - jmeter.threads.JMeterThread: Thread finished: 线程组 1-484

2017/04/25 13:59:59 ERROR - jmeter.threads.JMeterThread: Test failed! java.lang.OutOfMemoryError: unable to create new native thread

at java.lang.Thread.start0(Native Method)

at java.lang.Thread.start(Unknown Source)

at sun.net.www.http.KeepAliveCache$1.run(Unknown Source)

调整之后再次跑并发测试，

报错结果为后端服务端接收http请求后返回异常

系统层面：

tcp连接数超过5000，没问题

连接中统计连接超时

死套接字超过1000，第一次是2200左右，第二次是1200，说明死套接字回收正常，速度还是可以的

再看一下。我的系统曾经做过的调优

应用服务器优化：

基本的+

【处理器子系统调优】：开启超线程，处理器，重要性不言而喻，cpu性能经常是瓶颈，Hyper-Threading（超线程功能，基于SMP 内核），

Hyper-Threading 在操作系统里将一颗处理器虚拟化为两颗使用，使得处理器，同一时刻，可以执行两个线程或进程

TIME_WAIT相关sysctl参数及超时时间

[[email protected] ~]# sysctl -a | grep tw

net.ipv4.tcp_max_tw_buckets //处于TIME_WAIT状态的socket数目的最大值

net.ipv4.tcp_tw_recycle = 1 //打开TIME_WAIT快速回收机制

net.ipv4.tcp_tw_reuse //TIME_WAIT状态socket复用

Sysctl –w net.ipv4.tcp_tw_len = 2 设置TIME_WAIT在2秒后超时

果断调整tomcat内存情况，（此时系统资源合理）

还是后端压力过大，死套接字还是占据tcp资源，返回

Server returned HTTP response code: 502 for URL: http://app.yunce56.cn/v10/message/test/list

来看一下大婶们关于这波测试给出的建议

假死有两种情况，1种是time_wait过多，一种是close_wait过多，前者自行优化，后者开发程序问题

我帮你百度了一下，得出一条结论：这个错误是由于服务器压力过大，不能及时处理client的请求导致服务器响应超时而抛出的错误

基本上可以得出结论：

即使做过死套接字回收机制+tomcat优化，应用服务器也无法支持瞬间大并发3000，单台服务器理论65535.停留在涉及理论，（根据业务，有长连接或者是持续连接，做tcp连接回收机制，重点谨慎考虑）

之后采取措施：使用haproxy/lvs + nginx(s)+tomcat(s)。来因对并发，单台服务器并发3000即有3%左右连接数无法得到后端及时响应。

返回测试结果。调整架构方案。

架构方案（方案 + 回退机制）

方案

实施：1、停止148nginx，修改配置文件

80->1080

2、启用haproxy与2台nginx，tcp观测端口

启动，观察nginx日志

测试:联系开发与测试，boss与wap运行

失败回退：1、还原/etc/nginx

2、停用haproxy

备注：因阿里云不支持VIP，故haproxy为单点，

后期部署ha节点，使用阿里云负载均衡两台ha

效果等同于keepalived+haproxy+nginx+tomcat

注重要的，关于80端口是谁提供的服务，根据架构决定，后来是haproxy+nginx

User:

此最重要，将使用原IP代理80端口，使用haproxy 80端口负载nginx集群（1080端口），此时haproxy 提供web访问，将夺取nginx 80端口，域名映射不变。

服务器采购

nginx书写

haproxy书写

上一篇文章书写，关于tomcat优化，借鉴之前的经验

http://chennailong.blog.51cto.com/10063928/1883671

方案提出，等待夜晚来临，运维，are you ready ? 2017年4月26日 22:00-凌晨

转载于:https://blog.51cto.com/chennailong/1919737

HA架构关于应对高并发

相关推荐