Java 高并发环境下的性能优化，揭秘支付宝技术内幕

前言

• 高并发常常会发生在有大活跃用户量，用户高汇集的业务场景中，如：秒杀活动，定时领取红包等。

为了让业务能够流畅的运行而且给用户一个好的交互体验，咱们须要根据业务场景预估达到的并发量等因素，来设计适合本身业务场景的高并发处理方案。

• 在电商相关产品开发的这些年，我有幸的遇到了并发下的各类坑，这一路摸爬滚打过来有着很多的血泪史，这里进行的总结，做为本身的归档记录，同时分享给你们。

Java 高并发环境下的性能优化（附高并发视频资料和面试题等），揭秘支付宝技术内幕 私信。

服务器架构

• 业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。
• 一个能够支持高并发的服务少不了好的服务器架构，须要有均衡负载，数据库须要主从集群，nosql缓存须要主从集群，静态文件须要上传cdn，这些都是能让业务程序流畅运行的强大后盾。
• 服务器这块可能是须要运维人员来配合搭建，具体我就很少说了，点到为止。

大体须要用到的服务器架构以下：

• 服务器
• 均衡负载(如：nginx，阿里云SLB)
• 资源监控
• 分布式
• 数据库
• 主从分离，集群
• DBA 表优化，索引优化，等
• 分布式
• nosql
• 主从分离，集群
• 主从分离，集群
• 主从分离，集群
• redis
• mongodb
• memcache
• cdn
• html
• css
• js
• image

并发测试

• 高并发相关的业务，须要进行并发的测试，经过大量的数据分析评估出整个架构能够支撑的并发量。
• 测试高并发可使用第三方服务器或者本身测试服务器，利用测试工具进行并发请求测试，分析测试数据获得能够支撑并发数量的评估，这个能够做为一个预警参考，俗话说知己自彼百战不殆。

第三方服务:

• 阿里云性能测试

并发测试工具：

• Apache JMeter
• Visual Studio性能负载测试
• Microsoft Web Application Stress Tool

实战方案
通用方案

日用户流量大，可是比较分散，偶尔会有用户高聚的状况；
场景： 用户签到，用户中心，用户订单，等

服务器架构图：

说明：

• 场景中的这些业务基本是用户进入APP后会操做到的，除了活动日(618,双11，等)，这些业务的用户量都不会高汇集，同时这些业务相关的表都是大数据表，业务可能是查询操做，因此咱们须要减小用户直接命中DB的查询；优先查询缓存，若是缓存不存在，再进行DB查询，将查询结果缓存起来。
• 更新用户相关缓存须要分布式存储，好比使用用户ID进行hash分组，把用户分布到不一样的缓存中，这样一个缓存集合的总量不会很大，不会影响查询效率。

方案如：

• 用户签到获取积分
• 计算出用户分布的key,redis hash中查找用户今日签到信息
• 若是查询到签到信息，返回签到信息
• 若是没有查询到，DB查询今日是否签到过，若是有签到过，就把签到信息同步redis缓存。
• 若是DB中也没有查询到今日的签到记录，就进行签到逻辑，操做DB添加今日签到记录，添加签到积分(这整个DB操做是一个事务)
• 缓存签到信息到redis，返回签到信息
• 注意这里会有并发状况下的逻辑问题，如：一天签到屡次，发放屡次积分给用户。

用户订单

• 这里咱们只缓存用户第一页的订单信息，一页40条数据，用户通常也只会看第一页的订单数据
• 用户访问订单列表，若是是第一页读缓存，若是不是读DB
• 计算出用户分布的key,redis hash中查找用户订单信息
• 若是查询到用户订单信息，返回订单信息
• 若是不存在就进行DB查询第一页的订单数据，而后缓存redis，返回订单信息

用户中心

• 计算出用户分布的key,redis hash中查找用户订单信息
• 若是查询到用户信息，返回用户信息
• 若是不存在进行用户DB查询，而后缓存redis，返回用户信息

其余业务

• 上面例子可能是针对用户存储缓存，若是是公用的缓存数据须要注意一些问题，以下
• 注意公用的缓存数据须要考虑并发下的可能会致使大量命中DB查询，可使用管理后台更新缓存，或者DB查询的锁住操做。

以上例子是一个相对简单的高并发架构，并发量不是很高的状况能够很好的支撑，可是随着业务的壮大，用户并发量增长，咱们的架构也会进行不断的优化和演变，好比对业务进行服务化，每一个服务有本身的并发架构，本身的均衡服务器，分布式数据库，nosql主从集群，如：用户服务、订单服务；

消息队列

秒杀、秒抢等活动业务，用户在瞬间涌入产生高并发请求
场景：定时领取红包，等

服务器架构图：

一级缓存

• 高并发请求链接缓存服务器超出服务器可以接收的请求链接量，部分用户出现创建链接超时没法读取到数据的问题；
• 所以须要有个方案当高并发时候时候能够减小命中缓存服务器；
• 这时候就出现了一级缓存的方案，一级缓存就是使用站点服务器缓存去存储数据，注意只存储部分请求量大的数据，而且缓存的数据量要控制，不能过度的使用站点服务器的内存而影响了站点应用程序的正常运行，一级缓存须要设置秒单位的过时时间，具体时间根据业务场景设定，目的是当有高并发请求的时候可让数据的获取命中到一级缓存，而不用链接缓存nosql数据服务器，减小nosql数据服务器的压力

好比APP首屏商品数据接口，这些数据是公共的不会针对用户自定义，并且这些数据不会频繁的更新，像这种接口的请求量比较大就能够加入一级缓存；

服务器架构图：

静态化数据

• 高并发请求数据不变化的状况下若是能够不请求本身的服务器获取数据那就能够减小服务器的资源压力。
• 对于更新频繁度不高，而且数据容许短期内的延迟，能够经过数据静态化成JSON，XML,HTML等数据文件上传CDN，在拉取数据的时候优先到CDN拉取，若是没有获取到数据再从缓存，数据库中获取，当管理人员操做后台编辑数据再从新生成静态文件上传同步到CDN，这样在高并发的时候可使数据的获取命中在CDN服务器上。
• CDN节点同步有必定的延迟性，因此找一个靠谱的CDN服务器商也很重要