微服务架构 高并发处理

• 在同时或者极短时间内，有大量请求到达服务端，每个请求都需要服务端耗费资源进行处理，并做出相应反馈
• 服务端比如同时开启进程数，能同时运行的线程数、网络连接数、CPU运算、I/O、内存都是有限，
  所以服务端能同时处理请求也是有限的。高并发本质就是资源的有限性
  如：1.系统在线人数10W，并不意味系统并发用户是10W,可能存在10w用户同时在首页查看静态文章，并未对服务器进行发送请求
  那么高并发数 是根据系统真实用户数并发送请求需要服务端耗费资源进行处理的请求
  2.服务端只能开启100个线程，恰好1个线程处理一个请求需要耗时1s，那么服务端1s只能处理100个请求，多余请求无法处理

经典案例

• 商品、活动秒杀下订单

准备阶段

• 系统独立部署
• 做好系统容量规划（7-7.5折计算），系统优化、系统容灾限流等方案
• 做好系统拆分，如：功能模块、实时/非实时、动态/静态等
• 参加活动商品设置定时上架时间
• 服务器时间同步（集群中每台机器时钟要保持一致）
• 动态生成下单页面的URL

实现阶段

客户端层面：

• 前端页面采用h5静态化，ajax获取动态内容；如实时库存、活动状态、当前时间等
• 做CDN部署加速
• 静态页面和资源缓存 如：（图片）
• JS针对请求过滤，减少请求发送到达服务端 如：（获取验证码、时间截止或已售空自动结束等）

Web端层面：

• F5/LVS+Nginx接收高并发请求、并做负载均衡
• Lua脚本+Redis做请求队列，针对有效请求用List排队，并实现一些基本操作（限流、账号参加次数检查、同一IP请求数检查）
  Redis单线程高性能，每秒处理100W请求，如果大于100W请求如何处理呢？
  1.可以结合Lua脚本控制请求数量并限流，有效减少redis压力；比如100W请求，过滤20W，还剩80W，无效请求直接返回客户端不到达服务端
  2.如果应用非常庞大，用户流量高额，Redis单节点做成集群模式，请求处理数量也随之增加
• Varnish缓存静态页面和静态资源
• Tomcat集群，预处理，通过业务场景判断用户是具备参加活动资格、账号是否正常、是否在黑名单等

逻辑层面：

• 按照Redis请求队列进行先后处理
• 纯内存操作+异步（通过Redis完成减库存，1.利用Redis的watch事物 2.利用Redis脚本Lua原子操作减库存）

高并发产生问题，分析思考

• 服务端处理响应会逐渐变慢，甚至会丢失部分请求不处理，严重会导致服务器崩溃
• 客户端（app\h5）、前端请求（nginx/varnish）、web服务器(webServer)、web应用(rmi/dubbo/远程调用)、缓存（redis/membercache）、消息队列（mq）、数据库（db）都会面临高并发等问题

高并发优化思路

客户端层面

• 尽量减少请求数量，充分利用客户端、浏览器自身缓存，如微服务前后端交互、网络传输详细记载，本文不在详叙
• 尽量减少对服务端资源不必要浪费，如重复请求连接后端打开/关闭操作连接池

Nginx层面

• 动静分离，静态资源直接返回
• 负载均衡，如F5/LVS分流多个Nginx
• 根据系统业务，单独拆分访问（路径）

Varnish层面

• 动态内容缓存、减少访问后端服务
• 使用页面片段缓存技术，如ESI

Web服务器层面

• 针对JVM配置进行合理优化
• 服务器配置进行优化，如：调整内存数量、线程数量等
• 相同服务部署多台机器，实现负载均衡
• 增加资源，如增加网络带宽、高性能服务器、高性能数据库 （立杆见效，服务器普通硬盘换SSD,数据库换物理机等）
• 请求分流
  1.使用集群：如之前1台处理100个请求，增加两台后，3台机器虚拟组成一个集群后，对外处理请求可以提升到300*80%=240
  2.采用微服务架构，后续微服务架构高可用会详细描述

Web应用层面（优化应用程序）

• 提高单个请求的处理速度，如上如果处理一个请求消耗从1s降低到0.5秒，并发就是200
• 耗时业务同步根据业务情况 使用mq异步处理
• 比如导入、导出耗时耗力 合理使用多线程批量处理、指向单台应用独立处理
• 高效使用缓存，减少锁的使用范围
• 优化访问数据库SQL
• 尽量避免远程调用、大量I/O等耗时操作
• 合理规划事物等比较耗资源操作
• 部分业务考虑采用预计算处理，减少实时计算耗资源操作 如：报表
• 不要盲目使用RPC、netty、http远程网络调用，如需特定调用注意加上超时时间

数据库层面

• 合理使用数据库引擎 如 mysql的InnoDB和MyISAM引擎
• 数据库系统参数配置优化
• 特殊复杂计算耗时操作可以考虑使用存储过程来处理
• 数据库集群，进行读写分离
• 合理设计数据库表结构、索引 如（组合索引）
• 分库、分区、分表降到单库单表并发量
• 合理使用Nosql，如传统、分布式数据库共存，根据数据特性合理存放（hbase、hive、mongoDB）

总结：

高并发并不只是单一渠道等问题，本文主要讲述高并发涉及场景等具体详细优化思路。
优化原则 分析定位哪个环节链路是高并发瓶颈，进行优化分而治之，最终提高请求处理速度。
笔者建议优化顺序如下
1.web应用层面 核心优化web应用层面，80%高并发等问题都和低效应用程序有关系。
2.web服务器层面
3.客户端层面
4.nginx层面
5.varnish层面
6.数据库层面

作者简介：张程 技术研究

更多文章请关注微信公众号：zachary分解狮 (frankly0423)