Java开发大型互联网高并发架构实战之原理概念分析

JAVA大飞哥 2019-06-16 21:07:08

引言

高并发是指在同一个时间点，有很多用户同时访问URL地址，比如：淘宝的双11、双12，就会产生高并发。又如贴吧的爆吧，就是恶意的高并发请求，也就是所谓的DDOS攻击！

高并发会来带的后果

服务端：导致站点服务器/DB服务器资源被占满崩溃，数据的存储和更新结果和理想的设计是不一样的，比如：出现重复的数据记录，多次添加了用户积分等。

用户角度：尼玛，这么卡，老子来参加活动的，刷新了还是这样，垃圾网站，再也不来了！

我的经历：在做公司产品网站的过程中，经常会有这样的需求，比如搞个活动专题、抽奖、签到、积分竞拍等等，如果没有考虑到高并发下的数据处理，那就Game Over了，很容易导致抽奖被多抽走，签到发现一个用户有多条记录等等，各种超出正常逻辑的现象，这就是做产品网站必须考虑的问题，因为这些都是面向大量用户的，而不是像做ERP管理系统、OA系统那样，只是面向员工。

下面我进行实例分析，简单粗暴，动态分析，纯属本人经验分享，如有说错或者更好的建议，请留言，大家一起成长。

并发下的数据处理

通过表设计，如：记录表添加唯一约束，数据处理逻辑使用事物防止并发下的数据错乱问题。

通过服务端锁进程防止包并发下的数据错乱问题。

这里主要讲述的是在并发请求下的数据逻辑处理的接口，如何保证数据的一致性和完整性，这里的并发可能是大量用户发起的，也可能攻击者通过并发工具发起的并发请求。

例举1：通过表设计防止并发导致数据错乱

需求点：

【签到功能】一天一个用户只能签到一次，签到成功后用户获取到一个积分。

已知表：

1、用户表，包含积分字段；

2、高并发意淫分析(属于开发前的猜测)：在高并发的情况下，会导致一个用户签到记录会有多条，或者用户签到后不止加一积分。

我的设计：首先根据需求我会添加一张签到记录表，重点来了，这张表需要把用户唯一标识字段(ID,Token)和签到日期字段添加为唯一约束，或者唯一索引，这样就可以防止并发的时候插入重复用户的签到记录。然后在程序代码逻辑里，先执行签到数据的添加(这里可以防止并发，添加成功后再进行积分的添加，这样就可以防止重复地添加积分了。最后我还是建议所有的数据操作都写在一个sql事务里面， 这样在添加失败，或者编辑用户积分失败的时候可以回滚数据。

例举2：事务+通过更新锁，防止并发导致数据错乱；或者事物+Update的锁表机制

需求点：【抽奖功能】抽奖一次消耗一个积分，抽奖中奖后编辑剩余奖品总数，剩余奖品总数为0，或者用户积分为0的时候无法进行抽奖。

已知表：用户表，包含积分字段； 奖品表，包含奖品剩余数量字段。

高并发意淫分析(属于开发前的猜测)：在高并发的情况下，会导致用户参与抽奖的时候积分被扣除，而奖品实际上已经被抽完了。

我的设计：在事务里，通过WITH(UPDLOCK)锁住商品表，或者Update 表的奖品剩余数量和最后编辑时间字段，来把数据行锁住，然后进行用户积分的消耗，都完成后提交事物，失败就回滚。 这样就可以保证，只有可能存在一个操作在操作这件商品的数量，只有等到这个操作事物提交后，其他的操作这个商品行的事物才会继续执行。

例举3：通过程序代码防止包并发下的数据错乱问题

需求点：【缓存数据到cache里】，当缓存不存在的时候，从数据库中获取并保存在cache里，如果存在从cache里获取，每天10点必须更新一次，其他时间点缓存两个小时更新一次 到10点的时候，凡是打开页面的用户会自动刷新页面。

问题点：这里有个逻辑用户触发缓存的更新，用户刷新页面，当缓存存在的时候，会取到最后一次缓存更新时间，如果当前时间大于十点，并且最后缓存时间是10点前，则会从数据库中重新获取数据保存到cache中。 还有客户端页面会在10点时候用js发起页面的刷新，就是因为有这样的逻辑，导致10点的时候有很多并发请求同时过来，然后就会导致很多的sql查询操作，理想的逻辑是，只有一个请求会去数据库获取，其他都是从缓存中获取数据。(因为这个sql查询很耗服务器性能，所以导致在10点的时候，突然间数据库服务器压力暴增)

解决问题：C#通过（锁）lock，在从数据读取到缓存的那段代码前面加上锁，这样在并发的情况下只会有一个请求是从数据库里获取数据，其他都是从缓存中获取。

访问量大的数据统计接口

需求：用户行为数据统计接口，用来记录商品展示次数，用户通过点击图片，或者链接，或者其他方式进入到商品详情的行为次数。

问题点：这接口是给前端ajax使用，访问量会很大，一页面展示的时候就会有几十件商品的展示，滚动条滚到到页面显示商品的时候就会请求接口进行展示数据的统计，每次翻页又会加载几十件。

意淫分析：设想如果同时有1W个用户同时在线访问页面，一个次拉动滚动条屏幕页面展示10件商品，这样就会有10W个请求过来，服务端需要把请求数据入库。在实际线上环境可能还会超过这个请求量，如果不经过进行高并发设计处理，服务器分分钟给跪了。

解决问题：我们通过nodejs写了一个数据处理接口，把统计数据先存到redis的list里。(使用nodejs写接口的好处是，nodejs使用单线程异步事件机制，高并发处理能力强，不会因为数据逻辑处理问题导致服务器资源被占用而导致服务器宕机) 然后再使用nodejs写了一个脚本，脚本功能就是从redis里出列数据保存到mysql数据库中。这个脚本会一直运行，当redis没有数据需要同步到数据库中的时候，sleep，让在进行数据同步操作。

高并发下的服务器压力均衡，合理站点架设，DB部署

以下我所知道的：

服务器代理nginx，做服务器的均衡负载，把压力均衡到多台服务器；

部署集群MySQL数据库， Redis服务器，或者MongoDB服务器，把一些常用的查询数据，并且不会经常的变化的数据保存到其他NoSQL DB服务器中，来减少数据库服务器的压力，加快数据的响应速度；

数据缓存，Cache；

在高并发接口的设计中可以使用具有高并发能力的编程语言去开发，如：nodejs做web接口；

服务器部署，图片服务器分离，静态文件走CDN；

DBA数据库的优化查询条件，索引优化；

消息存储机制，将数据添加到信息队列中(redis list)，然后再写工具去入库

脚本合理控制请求，如，防止用户重复点击导致的ajax多余的请求，等等。

并发测试神器推荐

Apache JMeter

Microsoft Web Application Stress Tool

Visual Studio 性能负载

二、关于高并发架构

为了让业务可以流畅地运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。

在电商相关产品开发的这些年，我有幸遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里进行总结，作为自己的归档记录，同时分享给大家。

服务器架构

业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。

一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，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主从集群，如：用户服务、订单服务。

消息队列

秒杀、秒抢等活动业务，用户在瞬间涌入产生高并发请求。

场景：定时领取红包等。

服务器架构图：

说明：

场景中的定时领取是一个高并发的业务，像秒杀活动用户会在到点的时间涌入，DB瞬间就接受到一记暴击，hold不住就会宕机，然后影响整个业务；

像这种不是只有查询的操作并且会有高并发的插入或者更新数据的业务，前面提到的通用方案就无法支撑，并发的时候都是直接命中DB；

设计这块业务的时候就会使用消息队列的，可以将参与用户的信息添加到消息队列中，然后再写个多线程程序去消耗队列，给队列中的用户发放红包；

方案如：

定时领取红包；

一般习惯使用 redis的 list；

当用户参与活动，将用户参与信息push到队列中；

然后写个多线程程序去pop数据，进行发放红包的业务；

这样可以支持高并发下的用户可以正常的参与活动，并且避免数据库服务器宕机的危险。

附加：通过消息队列可以做很多的服务。

如：定时短信发送服务，使用sset(sorted set)，发送时间戳作为排序依据，短信数据队列根据时间升序，然后写个程序定时循环去读取sset队列中的第一条，当前时间是否超过发送时间，如果超过就进行短信发送。

高并发的几个重要概念

同步和异步

首先这里说的同步和异步是指函数/方法调用方面。

 

很明显，同步调用会等待方法的返回，异步调用会瞬间返回，但是异步调用瞬间返回并不代表你的任务就完成了，他会在后台起个线程继续进行任务。

并发和并行

 

并发和并行在外在表象来说，是差不多的。由图所示，并行则是两个任务同时进行，而并发呢，则是一会做一个任务一会又切换做另一个任务。所以单个cpu是不能做并行的，只能是并发。

临界区

临界区用来表示一种公共资源或者说是共享数据，可以被多个线程使用，但是每一次，只能有一个线程使用它，一旦临界区资源被占用，其他线程要想使用这个资源，就必须等待。

阻塞和非阻塞

 

·阻塞和非阻塞通常形容多线程间的相互影响。比如一个线程占用了临界区资源，那么其它所有需要这个资源的线程就必须在这个临界区中进行等待，等待会导致线程挂起。这种情况就是阻塞。此时，如果占用资源的线程一直不愿意释放资源，那么其它所有阻塞在这个临界区上的线程都不能工作。

·非阻塞允许多个线程同时进入临界区

所以阻塞的方式，一般性能不会太好。根据一般的统计，如果一个线程在操作系统层面被挂起，做了上下文切换了，通常情况需要8W个时间周期来做这个事情。

死锁、饥饿、活锁

所谓死锁：是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。就如同下图中的车都想前进，却谁都无法前进。

 

但是死锁虽说是不好的现象，但是它是一个静态的问题，一旦发生死锁，进程被卡死，cpu占有率也是0，它不会占用cpu，它会被调出去。相对来说还是比较好发现和分析的。

与死锁相对应的是活锁。

活锁，指事物1可以使用资源，但它让其他事物先使用资源；事物2可以使用资源，但它也让其他事物先使用资源，于是两者一直谦让，都无法使用资源。

举个例子，就如同你在街上遇到个人，刚好他朝着你的反方向走，与你正面碰到，你们都想让彼此过去。你往左边移，他也往左边移，两人还是无法过去。这时你往右边移，他也往右边移，如此循环下去。

一个线程在取得了一个资源时，发现其他线程也想到这个资源，因为没有得到所有的资源，为了避免死锁把自己持有的资源都放弃掉。如果另外一个线程也做了同样的事情，他们需要相同的资源，比如A持有a资源，B持有b资源，放弃了资源以后，A又获得了b资源，B又获得了a资源，如此反复，则发生了活锁。

活锁会比死锁更难发现，因为活锁是一个动态的过程。

饥饿是指某一个或者多个线程因为种种原因无法获得所需要的资源，导致一直无法执行。

并发级别

并发级别：阻塞和非阻塞（非阻塞分为无障碍、无锁、无等待）

阻塞

当一个线程进入临界区后，其他线程必须等待

无障碍

·无障碍是一种最弱的非阻塞调度

·自由出入临界区

·无竞争时，有限步内完成操作

·有竞争时，回滚数据

和非阻塞调度相比呢，阻塞调度是一种悲观的策略，它会认为说一起修改数据是很有可能把数据改坏的。而非阻塞调度呢，是一种乐观的策略，它认为大家修改数据未必把数据改坏。但是它是一种宽进严出的策略，当它发现一个进程在临界区内发生了数据竞争，产生了冲突，那么无障碍的调度方式则会回滚这条数据。

在这个无障碍的调度方式当中，所有的线程都相当于在拿去一个系统当前的一个快照。他们一直会尝试拿去的快照是有效的为止。

无锁

·是无障碍的

·保证有一个线程可以胜出

与无障碍相比，无障碍并不保证有竞争时一定能完成操作，因为如果它发现每次操作都会产生冲突，那它则会不停地尝试。如果临界区内的线程互相干扰，则会导致所有的线程会卡死在临界区，那么系统性能则会有很大的影响。

而无锁增加了一个新的条件，保证每次竞争有一个线程可以胜出，则解决了无障碍的问题。至少保证了所有线程都顺利执行下去。

下面代码是Java中典型的无锁计算代码

无锁在Java中很常见

while (!atomicVar.compareAndSet(localVar, localVar+1)){

localVar = atomicVar.get();

}

1.6.4 无等待

·无锁的

·要求所有的线程都必须在有限步内完成

·无饥饿的

总结

以 上就是我对Java开发大型互联网高并发架构实战之原理概念分析 问题及其优化总结，分享给大家，觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持！

最后，每一位读到这里的网友，感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上，我们可以一起学习、一起进步！都能赢取白富美，走向架构师的人生巅峰!

想了解学习Java方面的技术内容以及Java技术视频的内容可加群：722040762 验证码：头条（06 必过）欢迎大家的加入哟！