高并发&高可用系统应对策略的一些思考

说明：
仅仅是本身的一些观点和思考，若有问题欢迎指正
文中【】内提到的spring boot starter是本身封装的，地址：https://gitee.com/itopener/springboot

解耦神器：MQ

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

须要确认消息发送MQ成功
好比RabbitMQ在发送消息到MQ时，就有发送回调确认，虽然不可以彻底避免消息丢失，但也可以避免一些极端状况下消息发送失败的状况了。能够利用MQ的事务来避免更多状况的消息丢失。

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

消息消费的幂等性
正常来讲消息是不会重复发送的，可是一些特殊状况也可能会致使消息重复发送给消费者，通常会在消息中加一个全局惟一的流水号，经过流水号来判断消息是否已经消费过

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

库存扣减

库存扣减的实现方式有不少种，并且涉及到扣减库存的时候还须要结合实际业务场景来决定实现方案，除了扣减库存，还须要记录一些业务数据。数据库在高并发量的应用中很容易遇到瓶颈，因此能够考虑使用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操做没法彻底保证一致性，因此在保证正常状况下数据一致性的前提下，还须要相似对帐同样来验证扣减库存和实际库存的一致性。不过在这以前，我认为须要更优先考虑限流问题，须要提早压测出应用的性能瓶颈，根据压测结果对请求配置限流，优先保证高并发状况下应用不会崩溃掉，这样才能更好的保证接收到的请求可以按正常代码逻辑处理，减小发生库存不一致的状况。

限流

相信不少猿都遇到过并发量猛增致使系统崩溃的状况，因此建议提早压测出系统性能瓶颈，包含各个应用接口、数据库、缓存、MQ等的瓶颈，而后根据压测结果配置对应的限流值，这样能够很大程度避免应用由于大量请求而挂掉。固然这也会带来其余的问题，好比如下两个方面：

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

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

限流前置
在实际的系统架构中，用户请求可能会通过多级才会到达应用节点，好比：nginx-->gateway-->应用。若是条件容许，能够在尽可能靠前的位置作限流设置，这样能够尽早的给用户反馈，也能够减小后续层级的资源浪费。不过毕竟在应用内增长限流配置的开发成本相对来讲较低，而且可能会更灵活，因此须要根据团队实际状况而定了。nginx作限流设置可使用Lua+Redis配合来实现；应用内限流可使用RateLimiter来作。固然均可以经过封装来实现动态配置限流的功能，好比【ratelimiter-spring-boot-starter】

缓存

在高并发应用中，确定避免不了数据的频繁读写，这时候缓存就可以起到很大做用了，通常会使用像Redis集群这样的高性能缓存，减小数据库的频繁读取，以提升数据的查询效率，这里主要提下如下场景：

多级缓存
虽然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接口的实现中注意这点。

在缓存的使用方面，会有各类各样复杂的状况，建议能够整理一下各类场景并持续完善，这样能够在后续使用缓存的过程当中做为参考，也能够避免由于考虑不周全引发的异常，对于员工的培养也是颇有好处的。

数据预先处理

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

资源前置

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

熔断降级

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

· 配置熔断降级的时间须要综合权衡一下具体配置多少，并且正常状况下是可以快速响应的，当出现处理时间超时的状况或服务不可用的状况，就须要监控及时告警，以便尽快恢复服务。

· 当出现熔断降级的时候，须要有对应的机制，好比：重试、回退。须要保证业务数据在代码逻辑上的一致性。

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

补偿机制

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

· 重试须要限制重试次数，避免死循环，超过次数的须要及时告警，以便人工处理或其余处理。重试就须要保证幂等性，避免重复处理致使的不一致的问题。

· 回退。当超太重试次数或一些处理失败后，须要回退的，须要考虑周全一些，避免出现数据不一致的状况。

幂等性

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

监控告警

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

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

人员管理

· 分工要明确，须要有随时接收并处理问题的人员；

· 信息透明，团队成员须要对系统有足够的了解，须要让团队成员有独当一面的能力；

· 知识库，整理技术上、业务上的常见问题、经验，方便新成员快速理解并融入；

· 分享，按期分享技术上、业务上的知识，团队成员共同快速进步。适当的分享系统运行成果，能够适当鼓舞团队士气；

· 适当与业务沟通，了解一线业务需求和使用状况，以便不断改善，也能够在系统设计上有更长远的考虑；

· 适当用一些项目管理工具，适当将一些工做进行量化。不适合团队的成员也须要及时淘汰。

避免过分设计

· 避免由于少数极端状况作过多处理；
· 避免过分拆分微服务，尽可能避免分布式事务。

代码结构和规范

· 要注意代码结构的设计，提升代码可重用率；· 避免严格遵照代码规范，代码规范能够下降新成员的理解难度，也能够下降团队成员间互相理解的难度。