高并发&高可用系统的常见应对策略 秒杀等-(阿里)

 

对于一个须要处理高并发的系统而言，能够从多个层面去解决这个问题。

一、数据库系统：数据库系统能够采起集群策略以保证某台数据库服务器的宕机不会影响整个系统，而且经过负载均衡策略来下降每一台数据库服务器的压力（固然用一台服务器应付通常而言没啥问题，找一台当备机放着应付宕机就行，若是一台应付不了，那么再加一台，可是备机仍是要的，至少一台），另外采起读/写分离的方法下降数据库负载，再加上分库和分表进一步下降数据库负载，从而能够从容地应对高并发问题。固然成本会比较高，毕竟要这么多服务器。

二、分布式缓存系统：创建分布式缓存系统是相当重要的，全部的读写都先进入缓存系统，而后由缓存系统来安排从数据库系统/源服务器的读写。好比读的话，要是找不到，则把数据从数据库中读出放入缓存系统里（一样的，把页面从源服务器中获取并保存在缓存服务器中），再读取给客户端；写的话，则先写入缓存，由缓存系统把数据异步提交到消息队列中，而后写入数据库里。缓存分为硬盘缓存和内存缓存，硬盘缓存更多地用来缓存页面和页面资源例如多媒体资源，而内存缓存更多地用来缓存数据库的数据和应用中的一些状态。硬盘缓存有Squid，内存缓存有Memcached，微软在.Net Framework 4.0推了个Velocity也是内存缓存。

三、监控系统：这么多服务器和系统，总归是须要监控的，否则出了问题排查起来会很是麻烦，因此上述系统在开发时也要考虑到监控这一块，作好日志记录，而后配合监控系统能够一会儿查到问题根源。

四、前端系统：和数据库系统同样能够采用服务器集群和负载均衡，能够把各个服务细分而后注册到服务中心再分别部署到不一样的服务器上即采用分布式服务的方式，还能够使用多线程，另外为了更好地用户体验，能够多用异步方式和客户端操做来显示数据或者执行操做，ajax，js等等能够派很多用处，此外，还能够使用网页静态化（这样不但下降了开销还会提升网页被搜索到的几率，.Net有URLRewrite能够作到，只须要引入dll并注册而后设置Rewrite的规则便可），还有图片等多媒体资源单独设置服务器与页面分离，使用镜像网站或者CDN技术（Content Delivery Network，智能镜像网站+缓存技术，让用户能够访问本身最近的镜像网站的缓存服务器中的缓存页面）

五、服务器CPU和IO的平衡：对于全部的服务器，都须要保证它们的CPU和IO保持平衡，若是失衡，须要查找缘由，更改部署和配置以达到平衡。

对于通常的小型服务器，最佳线程数=CPU核的个数*2 + 2，固然这个只是经验之谈，实际公式比较复杂，为最佳线程数=((线程等待时间+线程cpu时间)/线程cpu时间) * cpu核的数量。

memcached的存储结构是把内存划分红不一样尺寸的内存块，并创建多个相同尺寸的内存块做为一个内存块群，存储的时候根据数据的实际大小选用最合适尺寸的内存块进行存储，这样子的缺点就是若是数据大小不是和内存块大小一致就会浪费一些内存，因此再设置内存块大小的时候要确保不一样的尺寸之间的大小差距不要太大。

memcached不会删除保存的数据，它是在接收到获取命令时先检查下数据是否过时，若是过时就返回没有数据，而后标志下这个内存块能够被从新保存数据，当内存都被使用须要释放数据时，它会根据LRU（Least Recently Used）机制来释放内存块。

memcached不支持分布式，也就是说不一样服务器上的memcached不会互相通讯，因此对于使用多台memcached服务器，须要客户程序来把须要保存的数据分发到不一样的memcached服务器上，分发的方法就是用key经过一个分发策略来肯定须要发送的服务器，而后进行发送保存，获取时也用key经过相同的分发策略肯定服务器并获取。若是某台memcached服务器发生故障，能够经过从新分配服务器的方法把数据保存到新的服务器上。

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。缓存的目的是提高系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹；而降级是当服务出问题或者影响到核心流程的性能则须要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，好比稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后几页），所以需有一种手段来限制这些场景的并发/请求量，即限流。

 

限流的目的是经过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则能够拒绝服务（定向到错误页或告知资源没有了）、排队或等待（好比秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。

 

通常开发高并发系统常见的限流有：限制总并发数（好比数据库链接池、线程池）、限制瞬时并发数（如nginx的limit_conn模块，用来限制瞬时并发链接数）、限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）；其余还有如限制远程接口调用速率、限制MQ的消费速率。另外还能够根据网络链接数、网络流量、CPU或内存负载等来限流。

 

先有缓存这个银弹，后有限流来应对61八、双十一高并发流量，在处理高并发问题上能够说是如虎添翼，不用担忧瞬间流量致使系统挂掉或雪崩，最终作到有损服务而不是不服务；限流须要评估好，不可乱用，不然会正常流量出现一些奇怪的问题而致使用户抱怨。

 

在实际应用时也不要太纠结算法问题，由于一些限流算法实现是同样的只是描述不同；具体使用哪一种限流技术仍是要根据实际场景来选择，不要一味去找最佳模式，白猫黑猫能解决问题的就是好猫。

 

因在实际工做中遇到过许多人来问如何进行限流，所以本文会详细介绍各类限流手段。那么接下来咱们从限流算法、应用级限流、分布式限流、接入层限流来详细学习下限流技术手段。

 

限流算法

常见的限流算法有：令牌桶、漏桶。计数器也能够进行粗暴限流实现。

 

解耦神器：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

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

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 计数器
• 如：类秒杀活动

客户端控流

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

1. 监控，及时扩容

应用限流后就决定了只能处理必定量的请求，对于增加期应用来讲，通常仍是但愿可以处理更多的用户请求，毕竟意味着带来更多的用户、更多的收益。因此就须要监控应用流量，根据实际状况及时进行扩容，提升整个系统的处理能力，以便为更多的用户提供服务

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 性能负载

• 当前在互联网+的大潮下，众所周知淘宝、京东这些交易系统天天产生的数据量都是海量的，天天的交易并发也是惊人的，尤为是“双11”、“6.18”这些活动，对系统的峰值响应提出了很是高的要求，因此对系统架构也就有了很要的要求。

  在写这篇博客的前2天，据说某系统在25人的用户量下就宕机了，实在让人震惊，因此捋了下互联网交易系统咱们能够采起哪些技术来解决互联网平台下大数据量高并发的问题。

  首先根据架构分层把不一样技术进行了一些分类，以下图：

  互联网技术架构分层策略图

  接下来我会逐一解释各个技术的大概原理和思路，供你们参考和学习：

  1、互联网层

  一、负载均衡

  负载均衡英文名称为Load Balance，意思就是分摊到多个操做单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工做任务。

  好比Nginx是一款能够经过反向代理实现负载均衡的服务器，把流量导向不一样的服务器；如今的云平台都提供了负载均衡服务，不过须要单独付费，好比阿里的SLB。

  二、内容分发网络(CDN)

  内容分发网络基本思路是尽量避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。

  经过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统可以实时地根据网络流量和各节点的链接、负载情况以及到用户的距离和响应时间等综合信息将用户的请求从新导向离用户最近的服务节点上。

  其目的，是使用户可就近取得所需内容，解决Internet网络拥挤的情况，提升用户访问网站的响应速度。这个不须要单独去实现，能够用现成的产品去作，好比: Akamai(好些，比较贵)，Verizon EdgeCast(便宜些)，ChinaCach；若是是云平台基本上都提供了这个服务，不过也须要付费的，好比阿里云基于本身的CDN加速提供了不一样形式的加速；好比基于P2P技术的PCDN，加强防御DDoS、CC、Web应用攻击的SCDN以及全站加速。

  2、Web服务器层

  一、Session→Cookie

  传统的B/S架构都是把用户会话放到Session里面，在在线用户量不高的状况下没啥问题，可是对于如今互联网采起了分布式或者微服务架构，就很难单独去维护Session了，由于Session会分布在不一样的服务器上，会话的同步会面临着很大的问题。因此一种方式是把Session的维护拿到Cookie里去作，不依赖于某台或多台服务器，同时也减小了服务器的开销。固然，也能够利用内存缓存服务器来统一存储Session信息，有的内存缓存服务器还能把内存数据持久化到磁盘来提升可用性和可恢复性，就不会有同步问题了。

  二、Static page

  动态页面静态化，为何又要把动态网页以静态网页的形式发布呢？一个很重要的缘由就是搜索引擎；另外一个重要缘由就是提升程序性能。

  不少大型网站，进去的时候看它页面很复杂，可是加载也没有耗费多长时间，缘由在于先于用户获取资源或数据库数据，进而经过静态化处理，生成静态页面。全部人都访问这一个静态页面，而静态化处理的页面自己的访问速度要较动态页面快不少倍，所以程序性能会有大大的提高。使用场景是那些常常须要访问可是数据不常常更新的时候。这种状况就是时候将动态页面静态化了，好比淘宝的宝贝信息页面，页面动态部分能够用AJAX加载进来，好比月销多少笔。

  三、Cache

  缓存，Web服务层的缓存依赖于下面三个方面：

  浏览器端的缓存，好比CSS/JS等；

  在CDN这类技术当中作大量页面缓存来提升就近访问速度；

  本身搭建内存缓存服务器对频率访问比较高的页面进行缓存，好比首页等。

  四、Gzip

  利用浏览器能自动进行Gzip解压缩的原理对访问页面和资源（含图片、JavaScript、CSS等）进行Gzip压缩，减小文件大小，以此来提升网络加载速度。

  五、One file

  原理是把多个须要加载的内容合成一个文件，减小加载次数和网络链接时间，提升访问效率，好比把小图标集合合成一个大图片，把CSS/JavaScript 合成到一个文件里面。

  六、Cluster

  集群和传统的高性能计算机技术相比，计算机集群经过一组松散集成的计算机软件和/或硬件链接起来高度紧密地协做完成计算工做。在某种意义上，它们能够被看做是一台计算机。

  集群系统中的单个计算机一般称为节点，一般经过局域网链接，但也有其它的可能链接方式。集群计算机一般用来改进单个计算机的计算速度和/或可靠性。通常状况下，集群计算机比单个计算机（好比工做站或超级计算机）性能价格比要高得多，大多数集群采用主从式来管理集群节点，好比Websphere Cluster。

  和常见的分布式的不一样点在于：集群是同一个业务部署在多个服务器上；分布式是一个业务分拆成多个子业务，或者自己就是不一样的业务，部署在不一样的服务器上。

  简单地说，分布式是以缩短单个任务的执行时间来提高效率，而集群则是经过提升单位时间内执行的任务数来提高效率。

  3、应用服务器或者业务服务器层

  一、Distributed/分布式|SC/服务中心|微服务|Decouple/解耦

  分布式系统是支持分布式处理的软件系统，是由通讯网络互联的多处理机体系结构上执行任务的系统。简单来讲，分布式处理就是多台相连的计算机各自承担同一工做任务的不一样部分，在人的控制下同时运行，共同完成同一件工做任务。包括分布式操做系统、分布式程序设计语言及其编译系统、分布式文件系统、分布式数据库系统、分布式调度系统等。这经常伴随须要作负载均衡、熔断和限流等；还得考虑是全量计算仍是增量计算等。

  因此随着分布式的发展，微服务架构就变得愈来愈流行，它的主要做用是将功能分解到离散的各个服务当中，从而下降系统的耦合性，并提供更加灵活的服务支持，围绕业务领域组件来建立应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单，因此业务的解耦和拆分的就变得愈来愈重要。

  如今随着容器(Docker)的发展让分布式、微服务变得更加灵活和容易，也让如今支持大数据量高并发提供了很好的基础设施。

  二、Cache

  这一层的缓存主要是对高频数据进行缓存，好比对中间计算结果进行缓存，并且是基于内存缓存居多，好比Memcached和Redis，有的还提供缓存持久化，好比Redis。在分布式计算中常常要对批量数据进行缓存预读取以提升计算速度。

  三、同步转异步/MQ

  同步转异步的思路一方面不让进程或者线程阻塞在顺序执行里，从而加快程序的执行，就像Node.js用异步和Java用同步作相同计算测试，好多时候速度Node.js比Java还快，不信你们能够试试，像双11的抢购都是采用了异步机制。

  另外一方面不让用户一直等在那里，用户能够继续作别的事情，等异步执行完毕通知用户。这里面大量用到了消息队列(MQ)，流行的产品不少，最先的WebsphereMQ，到如今的Kafka、RabbitMQ，有些甚至和流行的开源框架紧密集成，好比RabbitMQ和SpringBoot。

  4、数据访问、文件访问、内部网络访问层

  一、读写分离

  由于在大数据量并发状况下，读的操做频率远远超过写操做，因此经过读写分离来提升读的速度，其思路是让主数据库（master）处理事务性增、改、删操做（INSERT、UPDATE、DELETE），而从数据库（slave）处理SELECT查询操做，下面是淘宝最先的时候采用的读写分离策略：

  读写分离示意图

  二、DB Cluster

  集群就再也不作过多说明，数据库集群是利用至少两台或者多台数据库服务器，构成一个虚拟单一数据库逻辑映像，像单数据库系统那样，向客户端提供透明的数据服务。其目的仍是为了增长数据吞吐量，提升数据库性能，知足大数据量下对数据的读写速度要求。

  阿里云的RDS云数据库就继承了上述2大特征，外面看来是一个MySQL集群，提供统一的透明访问，而在内部就自动实现了读写分离，为高性能数据库存储提供了很大便利。

  三、分布式存储(DAS/NAS/SAN)

  三种分布式存储方案，你们可自行百度，各类介绍比较比较多，这里再也不赘述，好比阿里的OSS存储也是一种分布式存储。

  四、Cache

  缓存无处不在，连CPU都有二级缓存，在数据访问这一层，能够根据你的数据须要充分利用缓存技术来提供读写速度，好比对要求不是特别实时的大数据进行预统计分析，而后缓存下来作报表等，这个时候直接从缓存里读取便可，提升统计速度。

  五、NoSQL，Key/Value

  NoSQL，泛指非关系型的数据库。随着互联网Web2.0网站的兴起，传统的关系数据库在应付Web2.0网站已经显得力不从心，暴露了不少难以克服的问题，而非关系型的数据库则因为其自身的特色（高可扩展性、分布式计算、低成本、架构的灵活性、半结构化数据，没有复杂的关系）获得了很是迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤为是大数据应用难题。其数据库类型有列存储、文档存储、Key/Value存储、对象存储和图存储等。

  六、Split/分割，Partition/分区

  表分区是DB对于很是大的表进行优化的一种有效方法，是根据数据库定义不一样的分区策略决定的，好比取模、时间和哈希等，是很是有效的一种手段，在不少状况下比表分割更有效。

  好比，有一个代码表使用分区表把100万纪录分在10个分区中（ID每从1到10万为一个分区），那样写查询语句的时候，只要给出查询条件中所须要的代码，DB自动会定位到对应的分区进行查询，大大下降的查询时间。

  而采用表分割那必须先根据查询的代码指定所要查询的表，才能找到相应的记录，是由DBA或架构师根据业务须要来定义如何分割的。表分割分为水平分割和垂直分割：

  水平分割：根据一列或多列数据的值把数据行放到两个独立的表中；

  垂直分割：把主码和一些列放到一个表，而后把主码和另外的列放到另外一个表中。

  七、BGP

  边界网关协议，主要用于互联网AS（自治系统）之间的互联，BGP的最主要功能在于控制路由的传播和选择最好的路由。中国网通与中国电信都具备AS号（自治系统号），全国各大网络运营商多数都是经过BGP协议与自身的AS号来互联的。

  使用此方案来实现双线路须要在CNNIC（中国互联网信息中心）申请IDC本身的IP地址段和AS号，而后经过BGP协议将此段IP地址广播到移动，网通、电信等其它的网络运营商，使用BGP协议互联后移动。网通与电信的全部骨干路由设备将会判断到IDC机房IP段的最佳路由，以保证移动、网通和电信用户的高速访问。如今很多的云平台都支持BGP。

• 参考：高并发&高可用系统的常见应对策略

• 参考：高并发限流策略

• 参考：解决高并发的三大策略之面对峰值响应冲击