高并发&高可用系统的常见应对策略

解耦神器：MQ

MQ是分布式架构中的解耦神器，应用非常普遍。有些分布式事务也是利用MQ来做的。由于其高吞吐量，在一些业务比较复杂的情况，可以先做基本的数据验证，然后将数据放入MQ，由消费者异步去处理后续的复杂业务逻辑，这样可以大大提高请求响应速度，提升用户体验。如果消费者业务处理比较复杂，也可以独立集群部署，根据实际处理能力需求部署多个节点。需要注意的是：

需要确认消息发送MQ成功

比如RabbitMQ在发送消息到MQ时，就有发送回调确认，虽然不能够完全避免消息丢失，但也能够避免一些极端情况下消息发送失败的情况了。可以利用MQ的事务来避免更多情况的消息丢失

消息持久化

需要注意配置消息持久化，避免MQ集群挂掉的情况下大量丢失消息的情况

消息消费的幂等性

正常来说消息是不会重复发送的，但是一些特殊情况也可能会导致消息重复发送给消费者，一般会在消息中加一个全局唯一的流水号，通过流水号来判断消息是否已经消费过

注意用户体验

使用异步处理是在提高系统吞吐量考虑下的一种设计，相对于实时快速给用户返回结果，肯定用户体验会更差一点，但这也是目前来说综合考虑的一种不错的方案了，因此在设计之初就需要评估是否需要异步处理，如果需要异步处理，那一定要考虑如何给用户更友好的提示和引导。因为异步处理是技术实现结合实际业务情况的一种综合解决方案，对于产品来说是不应该关心的，需要技术人员主动尽早提出流程中异步处理的节点，在需求分析阶段就考虑如何设计才能对用户来说更加友好。如果在开发过程中才提出，很可能就会对用户展示界面有较大调整，从而导致需求变更、系统设计变更，而后就是甩锅、扯皮、延期了

项目管理

代码结构和规范

要注意代码结构的设计，提高代码可重用率
严格遵守代码规范，代码规范可以降低新成员的理解难度，也可以降低团队成员间互相理解的难度
参考：https://my.oschina.net/dengfuwei/blog/1611917

人员管理

分工要明确，需要有随时接收并处理问题的人员
信息透明，团队成员需要对系统有足够的了解，需要让团队成员有独当一面的能力
知识库，整理技术上、业务上的常见问题、经验，方便新成员快速理解并融入
分享，定期分享技术上、业务上的知识，团队成员共同快速进步。适当的分享系统运行成果，可以适当鼓舞团队士气
适当与业务沟通，了解一线业务需求和使用情况，以便不断改善，也可以在系统设计上有更长远的考虑
适当用一些项目管理工具，适当将一些工作进行量化。不适合团队的成员也需要及时淘汰

模块化设计

根据业务场景，将业务抽离成独立模块，对外通过接口提供服务，减少系统复杂度和耦合度，实现可复用，易维护，易拓展

项目中实践例子：
Before：

在返还购 APP 里有个【我的红包】的功能，用户的红包数据来自多个业务，如：邀请新用户注册领取 100 元红包，大促活动双倍红包，等各种活动红包，多个活动业务都实现了一套不同规则的红包领取和红包奖励发放的机制，导致红包不可管理，不能复用，难维护难拓展

After：

重构红包业务
红包可后台管理
红包信息管理，可添加，可编辑，可配置红包使用的规则，可管理用户红包
红包奖励发放统一处理
应用业务的接入只需要专注给用户进行红包发放即可

设计概要

Before VS After

产品有时提出的业务需求没有往这方面去考虑，结合场景和未来拓展需要，在需求讨论的时候提出模块化设计方案，并可以协助产品进行设计

通用服务抽离

在项目开发中经常会遇到些类似的功能，但是不同的开发人员都各自实现，或者因为不能复用又重新开发一个，导致了类似功能的重复开发，所以我们需要对能够抽离独立服务的功能进行抽离，达到复用的效果，并且可以不断拓展完善，节约了后续开发成本，提高开发效率，易于维护和拓展

项目中实践例子：
Before

在业务中经常需要对用户进行信息通知，如：短信定时通知，APP 消息推送，微信通知，等
开发人员在接到需求中有通知功能的时候没有考虑后续拓展，就接入第三方信息通知平台，然后简单封装个信息通知方法，后续也有类似信息通知需求的时候，另一个开发人员发现当前这个通知方法无法满足自己的需求，然后又自己去了解第三方平台重新封装了通知方法，或者后续需求加了定时通知的功能，开发人员针对业务去实现了个定时通知功能，但是只能自己业务上使用，其他业务无法接入，没有人去做这块功能的抽离，久而久之就演变成功能重复开发，且不易于维护和拓展

After
接触到这种可以抽离通用服务需求的时候，就会与产品确认这种需求是否后续会存在类似的需要，然后建议这把块需求抽离成通用服务，方便后续维护和拓展

设计概要

Before VS After

架构设计

前后端分离
对于并发量较大的应用，可以将前后端分离开，这样对于前端的资源就可以使用nginx等效率高的服务器，并且数据是在前端渲染，不是在服务端通过jsp、freemarker等渲染后返回前端。相当于把原本服务端处理的任务分散到用户端浏览器，可以很大程度的提高页面响应速度。前后端分离主要考虑的应该就是跨域的问题了，对于跨域主要考虑以下场景：

不跨域，建议使用这种方式。主要实现是将js、css、图片等静态资源放到CDN，使用nginx反向代理来区分html（或使用nodejs的服务端）和服务端数据的请求。这样能够保证前端和后端的请求都在同一个域名之下。这样做的好处主要是不用考虑跨域的问题，也可以避免跨域的一些坑，以支持更多的场景（比如RESTful）。采用这种方式的麻烦点主要是涉及到CDN、nginx、应用服务器的配置，所以在版本升级的时候需要有一些自动化的工具来提高效率、避免手动出现一些错误，并且要有一个较好的机制来保障版本升级的兼容性，比如CDN中的资源可以考虑在请求路径上增加一个版本号（在动静分离中也会提到）
服务端跨域。主要是在服务端配置以支持跨域请求。这种主要需要考虑的是服务端的权限处理，因为跨域默认是不会将访问的域的cookie传到服务端的，所以需要其他方式来传递一个请求的标志，用来控制权限
客户端跨域。这种方式不太适合业务类型系统，主要适用于一些公开的服务，比如：天气查询、手机号归属地查询等等

动静分离

动静分离主要也是对于性能上的优化措施，不同人对于动静分离的理解不一样，主要有以下两种

动态数据和静态资源分离。主要是指将静态资源（如：js、css、图片等）放到CDN，这样可以提高静态资源的请求速度，减少应用服务器的带宽占用。需要注意的是，因为使用了CDN，当版本升级的时候可以考虑在静态资源的访问路径上加一个版本号，这样升级之后可以避免CDN不刷新的问题，如果是APP应用，可以避免版本不兼容的问题，所以就需要在部署环节做一些自动化的工具，避免人工操作出现失误
服务端根据动态资源生成对应的静态资源，用户访问的始终是静态资源。这种比较常见于CMS（内容管理系统）、博客等类型的应用。主要方式是提前根据动态数据生成对应的静态资源（即html静态页面），这样用户访问的时候就直接访问html页面了，可以较大程度的提高访问速度。这种方式主要适合数据变化不太频繁的场景

避免过度设计

避免因为少数极端情况做过多处理
避免过度拆分微服务，尽量避免分布式事务
慎用前后端分离，比如一些内部管理型的使用量不高的应用，是没必要做前后端分离的

数据预先处理
对于一些业务场景，可以提前预处理一些数据，在使用的时候就可以直接使用处理结果了，减少请求时的处理逻辑。如对于限制某些用户参与资格，可以提前将用户打好标记，这样在用户请求时就可以直接判断是否有参与资格，如果数据量比较大，还可以根据一定规则将数据分布存储，用户请求时也根据此规则路由到对应的服务去判断用户参与资格，减轻单节点压力和单服务数据量，提高整体的处理能力和响应速度

资源前置
目前很多都是分布式微服务架构，就可能会导致调用链路很长，因此可以将一些基本的判断尽量前置，比如用户参与资格、前面提到的限流前置、或者一些资源直接由前端请求到目的地址，而不是通过服务端转发；涉及概率型的高并发请求，可以考虑在用户访问时即随机一部分结果，在前端告知用户参与失败。总之，就是将能提前的尽量提前，避免调用链路中不符合条件的节点做无用功

补偿机制
对于一些业务处理失败后需要有补偿机制，例如：重试、回退等

重试需要限制重试次数，避免死循环，超过次数的需要及时告警，以便人工处理或其他处理。重试就需要保证幂等性，避免重复处理导致的不一致的问题
回退。当超过重试次数或一些处理失败后，需要回退的，需要考虑周全一些，避免出现数据不一致的情况

幂等性
在实际处理中可能会出现各种各样的情况导致重复处理，就需要保证处理的幂等性，一般可以使用全局唯一的流水号来进行唯一性判断，避免重复处理的问题，主要是在MQ消息处理、接口调用等场景。全局唯一的流水号可以参考tweeter的snowflake算法【sequence-spring-boot-starter】。具体生成的位置就需要根据实际业务场景决定了，主要是需要考虑各种极端的异常情况

监控告警
在高并发系统中，用户量本身就很大，一旦出现问题影响范围就会比较大，所以监控告警就需要及时的反馈出系统问题，以便快速恢复服务。必须要建立比较完善的应对流程，建议也可以建立对应的经验库，对常见问题进行记录，一方面避免重复发生，另一方面在发生问题时可以及时定位问题。

自动化运维方面需要大力建设，可以很大程度提高线上问题的响应和解决速度。并且需要有全链路监控机制，可以更方便的排查线上问题并快速解决。全链路监控可以考虑像pingpoint、zipkin、OpenCensus等

架构独立服务

项目开发过程中有些需求是与所在项目业务无关，如：收集用户行为习惯，收集商品曝光点击，数据收集提供给 BI 进行统计报表输出，公用拉新促活业务（柚子街和返还公用），类似这种需求，我们结合应用场景，考虑服务的独立性，以及未来的拓展需要，架构独立项目进行维护，在服务器上独立分布式部署不影响现有主业务服务器资源

项目中实践例子：
架构用户行为跟踪独立服务，在开发前预估了下这个服务的请求量，并会有相对大量的并发请求
架构方案：

项目搭建选择用 nodejs 来做服务端
单进程，基于事件驱动和无阻塞 I/O，所以非常适合处理并发请求
负载均衡：cluster 模块 / PM2
架构 nodejs 独立服务
提供服务接口给客户端
接口不直接 DB 操作，保证并发下的稳定性
数据异步入库
通过程序把数据从：消息队列 =>mysql
nodejs+express+redis(list)/mq+mysql

用户行为跟踪服务的服务架构图

高并发优化

高并发除了需要对服务器进行垂直扩展和水平扩展之外，作为后端开发可以通过高并发优化，保证业务在高并发的时候能够稳定的运行，避免业务停滞带来的损失，给用户带来不好的体验

缓存：

服务端缓存
内存数据库

redis
memcache

方式

优先缓存
穿透 DB 问题
只读缓存
更新 / 失效删除

注意

内存数据库的分配的内存容量有限，合理规划使用，滥用最终会导致内存空间不足
缓存数据需要设置过期时间，无效 / 不使用的数据自动过期
压缩数据缓存数据，不使用字段不添加到缓存中
根据业务拆分布式部署缓存服务器

客户端缓存

方式

客户端请求数据接口，缓存数据和数据版本号，并且每次请求带上缓存的数据版本号
服务端根据上报的数据版本号与数据当前版本号对比
版本号一样不返回数据列表，版本号不一样返回最新数据和最新版本号

场景：

更新频率不高的数据

服务端缓存架构图

场景

多级缓存

虽然Redis集群这种缓存的性能已经很高了，但是也避免不了网络消耗，在高并发系统中，这些消耗是可能会引起很严重后果的，也需要尽量减少。可以考虑多级缓存，将一些变更频率非常低的数据放入应用内缓存，这样就可以在应用内直接处理了，相比使用集中式缓存来说，在高并发场景还是能够提高很大效率的，可以参考【cache-redis-caffeine-spring-boot-starter】实现两级缓存，也可以参考开源中国的J2Cache，支持多种两级缓存的方式。需要注意的就是缓存失效时一级缓存的清理，因为一级缓存是在应用内，对于集群部署的系统，应用之间是没法直接通信的，只能借助其他工具来进行通知并清理一级缓存。如利用Redis的发布订阅功能来实现同一应用不同节点间的通信

CDN也是一种缓存，只是主要适用于一些静态资源，比如：css、js、png图片等，前端会使用的较多。在一些场景下，可以结合动静分离、前后端分离，将前端资源全部放入CDN中，能够很大程度提高访问效率。需要注意的是前端静态资源是可能会更新的，当有更新的时候需要刷新CDN缓存。或者另一种策略是在静态资源的地址上增加一个类似版本号的标志，这样每次修改后的路径就会不一样，上线后CDN就会直接回源到自己应用内获取最新的文件并缓存在CDN中。使用CDN就需要一套比较完善的自动化部署的工具了，不然每次修改后上线就会比较麻烦

前端缓存

前端html中可以配置静态资源在前端的缓存，配置后浏览器会缓存一些资源，当用户刷新页面时，只要不是强制刷新，就可以不用再通过网络请求获取静态资源，也能够一定程度提高页面的响应速度

缓存穿透

当使用缓存的时候，如果缓存中查询不到数据，就会回源到数据库中查询。但是如果某些数据在数据库中也没有，如果不做处理，那么每次请求都会回源到数据库查询数据。如果有人恶意利用这种不存在的数据大量请求系统，那么就会导致大量请求到数据库中执行查询操作。这种情况就叫做缓存穿透。在高并发场景下更需要防止这种情况的发生
防止：如果数据库中查询不到数据，可以往缓存里放一个指定的值，从缓存中取值时先判断一下，如果是这个指定的值就直接返回空，这样就可以都从缓存中获取数据了，从而避免缓存穿透的问题。也可以根据缓存对象的实际情况，采用两级缓存的方式，这样也可以减少缓存设备的请求量。redis是常用的缓存，但是不能存储null，因此spring cache模块中定义了一个NullValue对象，用来代表空值。spring boot中Redis方式实现spring cache是有一些缺陷的（spring boot 1.5.x版本），具体参考[https://my.oschina.net/dengfuwei/blog/1616221]中提到的#RedisCache实现中的缺陷#

缓存雪崩

缓存雪崩主要是指由于缓存原因，大量请求到达了数据库，导致数据库压力过大而崩溃。除了上面提到的缓存穿透的原因，还有可能是缓存过期的瞬间有大量的请求需要处理，从缓存中判断无数据，然后就直接查询数据库了。这也是在高并发场景下比较容易出现的问题
防止：当缓存过期时，回源到数据库查询的时候需要做下处理，如：加互斥锁。这样就能够避免在某个时间点有大量请求到达数据库了，当然也可以对方法级别做限流处理，比如：hystrix、RateLimiter。也可以通过封装实现缓存在过期前的某个时间点自动刷新缓存。spring cache的注解中有一个sync属性，主要是用来表示回源到数据查询时是否需要保持同步，由于spring cache只是定义标准，没有具体缓存实现，所以只是根据sync的值调用了不同的Cache接口的方法，所以需要在Cache接口的实现中注意这点
在缓存的使用方面，会有各种各样复杂的情况，建议可以整理一下各种场景并持续完善，这样可以在后续使用缓存的过程中作为参考，也可以避免因为考虑不周全引起的异常，对于员工的培养也是很有好处的

异步

异步编程
方式：

多线程编程
nodejs 异步编程

场景：

参与活动成功后进行短信通知
非主业务逻辑流程需要的操作，允许异步处理其他辅助业务，等

业务异步处理

方式

业务接口将客户端上报的数据 PUSH 到消息队列（MQ 中间件），然后就响应结果给用户
编写独立程序去订阅消息队列，异步处理业务

场景：

大促活动整点抢限量红包
参与成功后委婉提示：预计 X 天后进行红包发放
并发量比较大的业务，且没有其他更好的优化方案，业务允许异步处理

注意：

把控队列消耗的进度
保证幂等性和数据最终一致性

缺陷：

牺牲用户体验

【业务异步处理】架构图

【业务异步处理】除了可以在高并发业务中使用，在上面通用服务的设计里也是用这种架构方式

限流

在类秒杀的活动中通过限制请求量，可以避免超卖，超领等问题
高并发的活动业务，通过前端控流，分散请求，减少并发量
更多限流方案参看对高并发流量控制的一点思考

服务端限流

redis 计数器
如：类秒杀活动

客户端控流

通过参与活动游戏的方式
红包雨 / 小游戏，等方式

监控，及时扩容

应用限流后就决定了只能处理一定量的请求，对于增长期应用来说，一般还是希望能够处理更多的用户请求，毕竟意味着带来更多的用户、更多的收益。所以就需要监控应用流量，根据实际情况及时进行扩容，提高整个系统的处理能力，以便为更多的用户提供服务

2.用户体验

当应用达到限流值时，需要给用户更好的提示和引导，这也是需要在需求分析阶段就需要考虑的

3.限流前置

在实际的系统架构中，用户请求可能会经过多级才会到达应用节点，比如：nginx-->gateway-->应用。如果条件允许，可以在尽量靠前的位置做限流设置，这样可以尽早的给用户反馈，也可以减少后续层级的资源浪费。不过毕竟在应用内增加限流配置的开发成本相对来说较低，并且可能会更灵活，所以需要根据团队实际情况而定了。nginx做限流设置可以使用Lua+Redis配合来实现；应用内限流可以使用RateLimiter来做。当然都可以通过封装来实现动态配置限流的功能，比如【ratelimiter-spring-boot-starter】

服务降级

当服务器资源消耗已经达到一定的级别的时候，为了保证核心业务正常运行，需要丢卒保车，弃车保帅，服务降级是最后的手段，避免服务器宕机导致业务停滞带来的损失，以及给用户带来不好的体验

业务降级

从复杂服务，变成简单服务
从动态交互，变成静态页面

分流到 CDN

从 CDN 拉取提前备好的 JSON 数据
引导到 CDN 静态页面

停止服务

停止非核心业务，并进行委婉提示

熔断降级

在微服务架构中，会有很多的接口调用，当某些服务出现调用时间较长或无法提供服务的时候，就可能会造成请求阻塞，从而导致响应缓慢，吞吐量降低的情况。这时候就有必要对服务进行降级处理。当超过指定时间或服务不可用的时候，采取备用方案继续后续流程，避免请求阻塞时间太长。比如对于概率性的请求（如抽奖），当处理时间过长时直接认为随机结果是无效的（如未中奖）。需要注意的是

配置熔断降级的时间需要综合权衡一下具体配置多少，而且正常情况下是能够快速响应的，当出现处理时间超时的情况或服务不可用的情况，就需要监控及时告警，以便尽快恢复服务
当出现熔断降级的时候，需要有对应的机制，比如：重试、回退。需要保证业务数据在代码逻辑上的一致性

可以使用hystrix来实现熔断降级处理

高并发优化概要图

防刷 / 防羊毛党

大多数公司的产品设计和程序猿对于推广活动业务的防刷意识不强，在活动业务设计和开发的过程中没有把防刷的功能加入业务中，给那些喜欢刷活动的人创造了很多的空子
等到你发现自己被刷的时候，已经产生了不小的损失，少则几百几千，多则几万
随着利益的诱惑，现在已经浮现了一个新的职业 “刷客”，专业刷互联网活动为生，养了 N 台手机 + N 个手机号码 + N 个微信账号，刷到的奖励金进行提现，刷到活动商品进行低价转手处理，开辟了一条新的灰色产业链
我们要拿起武器 (代码) 进行自我的防御，风控，加高门槛，通过校验和限制减少风险发生的各种可能性，减少风险发生时造成的损失
这里列出常用套路（具体应用结合业务场景）：

校验请求合法性

请求参数合法性判断
请求头校验
user-agent
referer
... ...
签名校验
对请求参数进行签名
设备限制
IP 限制
微信 unionid/openid 合法性判断
验证码 / 手机短信验证码
牺牲体验
自建黑名单系统过滤

业务风控

限制设备 / 微信参与次数
限制最多奖励次数
奖池限制
根据具体业务场景设计... ...

应对角色

普通用户
技术用户
专业刷客
目前还没有很好的限制方式

防刷 / 防羊毛党套路概要图

附加

APP/H5 中签名规则应该由客户端童鞋开发，然后拓展 API 给前端 JS 调用，在 H5 发起接口请求的时候调用客户端拓展的签名，这样可以避免前端 JS 里构造签名规则而被发现破解

并发问题

多操作

场景：

当 == 同用户 == 多次触发点击，或者通过模拟并发请求，就会出现多操作的问题，比如：签到功能，一天只能签到一次，可以获得 1 积分，但是并发的情况下会出现用户可以获得多积分的问题

剖析：

简化签到逻辑一般是这样的：
查询是否有签到记录 --> 否 --> 添加今日签到记录 --> 累加用户积分 --> 签到成功
查询是否有签到记录 --> 是 --> 今日已经签到过
假设这个时候用户 A 并发两个签到请求，这时会同时进入到【查询是否有签到记录】，然后同时返回否，就会添加两条的签到记录，并且多累加积分

解决方案：

最理想简单的方案，只需要在签到记录表添加【签到日期】+【用户 ID】的组合唯一索引，当并发的时候只有会一条可以添加成功，其他添加操作会因为唯一约束而失败

库存负数

场景：

当 == 多用户 == 并发点击参与活动，如：抽奖活动，这个时候奖品只有一个库存了，理论上只有一个用户可以获得，但是并发的时候往往会出现他们都成功获得奖品，导致奖品多支出，加大了活动成本

剖析：

有问题的逻辑流程一般是这样的：
中奖 --> 查询奖品库存 --> 有 --> 更新奖品库存 --> 添加中奖纪录 --> 告知中奖
中奖 --> 查询奖品库存 --> 无 --> 告知无中奖
假设抽奖活动，当前奖品 A 只有最后一个库存，然后用户 A、B、C，同时参与活动同时中奖奖品都是 A，这个时候查询商品库存是存在 1 个，就会进行更新库存，添加中奖纪录，然后就同时中奖了

解决方案：

最理想根本就不需要用多做一个库存的 SELECT 奖品库存操作，只需要 UPDATE 奖品库存 - 1 WHERE 奖品库存 >=1，UPDATE 成功后就说明是有库存的，然后再做后续操作，并发的时候只会有一个用户 UPDATE 成功

库存扣减

库存扣减的实现方式有很多种，而且涉及到扣减库存的时候还需要结合实际业务场景来决定实现方案，除了扣减库存，还需要记录一些业务数据。数据库在高并发量的应用中很容易遇到瓶颈，所以可以考虑使用Redis + MQ来做请求的处理，由MQ消费者去实现后续的业务逻辑。这样能够较快速的响应请求，避免请求阻塞而引发更多的问题

使用Redis来做库存扣减

利用Redis中的incr命令来实现库存扣减的操作。Redis从2.6.0版本开始内置了Lua解释器，并且对Lua脚本的执行是具有原子性的，所以可以利用此特性来做库存的扣减，具体实现可以参考【stock-spring-boot-starter】，starter中主要实现了初始化/重置库存、扣减库存、恢复库存

Redis集群的效率已经非常高了，能够支撑一定量的并发扣减库存，并且由于Redis执行Lua脚本的原子性可以避免超扣的问题。如果一个Redis集群还满足不了业务需要，可以考虑将库存进行拆分。即将库存拆成多份，分别放到不同的Redis集群当中，多个Redis集群采用轮询策略，基本能够在大体上保证各个Redis集群的剩余库存量不会相差太大。不过也不能绝对的保证数量均匀，所以在扣减库存操作返回库存不足时，还是需要一定的策略去解决这个问题，比如扣减库存返回库存不足时，继续轮询到下一个Redis集群，当所有Redis集群都返回库存不足时，可以在应用节点内或某个统一的地方打个标记表示已没有库存，避免每个请求都轮询全部的Redis集群。

扣减库存的幂等性

由于利用Redis的incr命令来扣减库存，没法存储请求源的信息，所以扣减库存的幂等性由应用来保证，可以利用客户端token或流水号之类的来做

MQ异步处理业务数据

扣减库存都会伴随一些业务数据需要记录，如果实时记录到数据库，仍然很容易达到瓶颈，所以可以利用MQ，将相关信息放入MQ，然后由MQ消费者去异步处理后续的业务逻辑。当然如果MQ消息发送失败需要恢复Redis中的库存，Redis操作和MQ操作无法完全保证一致性，所以在保证正常情况下数据一致性的前提下，还需要类似对账一样来验证扣减库存和实际库存的一致性。不过在这之前，我认为需要更优先考虑限流问题，需要提前压测出应用的性能瓶颈，根据压测结果对请求配置限流，优先保证高并发情况下应用不会崩溃掉，这样才能更好的保证接收到的请求能够按正常代码逻辑处理，减少发生库存不一致的情况

总结：

在开发业务接口的时候需要把 == 同用户 == 和 == 多用户 == 并发的场景考虑进去，这样就可以避免在并发的时候产生数据异常问题，导致成本多支出
可以使用下面的工具进行模拟并发测试：

Apache JMeter
Charles Advanced Repeat
Visual Studio 性能负载

扫码关注作者公众号