春节运维之：高并发＆高可用系统应对策略的一些思考

各位运维童鞋们，2018的春节即将来临，你们为业务做了高并发和高可用麽？

今天来看看一个运维高可用/高并发案例的思考。

首先来说说高并发吧。

高并发

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。

响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。

吞吐量：单位时间内处理的请求数量。

QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。

并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

高可用

高可用性H.A.（High Availability）指的是通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。它与被认为是不间断操作的容错技术有所不同。HA系统是目前企业防止核心计算机系统因故障停机的最有效手段。

随着IT信息系统的不断发展，数据在企业的应用越来越广，如何提高IT系统的高可用性成为建设稳健的计算机系统的首要任务之一。构成计算机网络系统的三大要素是：网络系统，服务器系统，存储系统。网络系统包括防火墙，路由器等网络设备，服务器系统主要指用户使用的各种服务器系统，存储系统，则是用户最主要的数据存储放的地点。

因此IT系统的高可用建设应包括网络设备高可用性，服务器设备高可用性，及存储设备的高可用性三个方面。

解耦神器：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集群这样的高性能缓存，减少数据库的频繁读取，以提高数据的查询效率，这里主要提下以下场景

CDN

CDN也是一种缓存，只是主要适用于一些静态资源，比如：css、js、png图片等，前端会使用的较多。

内容发布：它借助于建立索引、缓存、流分裂、组播（Multicast）等技术，将内容发布或投递到距离用户最近的远程服务点（POP）处；

内容路由：它是整体性的网络负载均衡技术，通过内容路由器中的重定向（DNS）机制，在多个远程POP上均衡用户的请求，以使用户请求得到最近内容源的响应；

内容交换：它根据内容的可用性、服务器的可用性以及用户的背景，在POP的缓存服务器上，利用应用层交换、流分裂、重定向（ICP、WCCP）等技术，智能地平衡负载流量；

性能管理：它通过内部和外部监控系统，获取网络部件的状况信息，测量内容发布的端到端性能（如包丢失、延时、平均带宽、启动时间、帧速率等），保证网络处于最佳的运行状态。

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

前端缓存

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

缓存穿透

当使用缓存的时候，如果缓存中查询不到数据，就会回源到数据库中查询。但是如果某些数据在数据库中也没有，如果不做处理，那么每次请求都会回源到数据库查询数据。如果有人恶意利用这种不存在的数据大量请求系统，那么就会导致大量请求到数据库中执行查询操作。这种情况就叫做缓存穿透，在高并发场景下更需要防止这种情况的发生。

缓存雪崩

缓存雪崩主要是指由于缓存原因，大量请求到达了数据库，导致数据库压力过大而崩溃。除了上面提到的缓存穿透的原因，还有可能是缓存过期的瞬间有大量的请求需要处理，从缓存中判断无数据，然后就直接查询数据库了。这也是在高并发场景下比较容易出现的问题。

数据预先处理

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

资源前置

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

监控告警

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

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

避免过度设计

避免因为少数极端情况做过多处理

避免过度拆分微服务，尽量避免分布式事务

代码结构和规范

要注意代码结构的设计，提高代码可重用率

严格遵守代码规范，代码规范可以降低新成员的理解难度，也可以降低团队成员间互相理解的难度

人员管理

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

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

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

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

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

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

（原文作者：J袁）