高并发场景下如何保证系统稳定性

见贤思齐

导语微服务产品团队为了广大开发者朋友们可以更好的使用腾讯云微服务产品，将持续为大家提供微服务上云快速入门的指引性文档，内容通俗易懂易上手，本篇为本系列的第二篇，为开发者朋友们详解高并发场景下限流的解决方案，欢迎大家收看。作者简介刘远腾讯云泛互联网首席解决方案架构师本篇文章将从以下四个方面为大家详解高并发场景限流解决方案：秒杀场景架构概述限流实现原理及方案选型限流配置实践云书城沙盒环境演示秒杀场景架构概述场景特点在电商行业里，商家经常会做商品促销的活动，来进行品牌推广或吸引更多客户访问，在这种大促的场景下，通常会有高并发流量进入系统，也就是我们俗称的秒杀场景。在这种场景下，一般会遇到四个典型的特征。瞬时请求量大，商品价格低廉，吸引大量用户在活动开始时进行抢购。热点数据，指定部分商品参与活动，大量用户浏览量相对集中。避免超卖，因商品让利较多，商家为控制成本，所以数量有限。不能影响其他业务，秒杀活动同时其他业务也需要正常进行。在遇见以上特征带来的技术难题时，要如何保证系统正常运行呢？主要有以下几个设计要点：秒杀子系统与主站资源隔离；系统需要具备限流能力，能够消化掉秒杀开始瞬间的巨大流量；系统需要具备快速扩展能力；削峰填谷，避免写流量压垮数据库；热点商品提前缓存，通过缓存承载读流量；库存增减需要保证数据一致性。架构目标为保证活动的顺利开展，业务系统稳定，需要对承载高并发流量的架构进行合理改造。通常来讲，改造后的架构需要具备如下三个特点：高性能：能够承载秒杀时较高的读写流量，保证响应时长在可接受的范围内，并兼顾数据一致性。高可用：保证系统不宕机，即使发生故障，过载保护也能将故障控制在小范围内，不会影响核心业务运行。高扩展：系统具备水平/垂直扩展能力，避免单个服务成为性能瓶颈。改造示例下图是一个常见的电商平台架构，从上到下分别是流量链路途径的客户端、接入层、应用层以及数据层。在这样一个典型的架构上我们该如何改造，以实现高并发承载能力呢？参考上图，首先会在③位置，接入层网关对南北流量的超额部分限流，避免后端系统过载，保证业务正常运行。接下来，①、②、⑦这里进行读缓存的优化：①位置，客户端对部分变化不灵敏的数据进行本地缓存，减少后端读取压力；②位置，CDN缓存、CSS、JS等静态文件，就近加速访问，减少后端读取压力；⑦位置，Redis缓存热点数据，分担数据库查询压力，这三部分都是为了实现读优化的性能改造。写数据的优化，在⑤位置，常使用MySQL进行读写分离方式部署，多实例提升读写性能。如单实例遇到性能瓶颈时，也可同时利用水平分库分表的方式提升并发能力；⑥位置，使用消息队列进行异步解耦，以削峰填谷的方式控制请求处理速度。最后，在④位置，应用层服务支持纵向或横向扩展，提升应用服务响应能力。微服务之间采用熔断降级的策略，实现容错处理，避免群体故障。以上各实践均有助于解决高并发问题，但在实际设计中，架构师需要根据请求QPS量级，采用方案组合的形式逐步推进。具体落地进度，也要根据改造成本、资源成本、性能提升回报率等因素进行综合评估。如下图所示。限流实现原理及方案选型接下来我们会重点介绍阶段一和阶段二里的高并发限流能力。什么是限流呢？限流是高并发系统中，对于服务提供方的一种常见的保护手段。通过控制QPS的方式，把后端服务无法承受的部分流量拒绝掉，只将能够稳定处理的流量放入进来，避免后端服务被瞬时的流量高峰冲垮，在南北向设置阈值，保障大后方的稳定性。应用场景商品秒杀：保护网站不被高并发访问击垮；防恶意请求：防止恶意用户发送虚假流量，影响正常业务访问；防止注入、篡改或DDos攻击等；反爬虫：保护核心数据不被获取。超额流量处理方式返回失败：HTTP429TooManyRequests；降级处理：自定义静态页面返回；请求排队：阻塞请求，一段时间后再继续处理，实现限速。限流计数器在限流应用的开发中，有多种代码逻辑实现，我们最常见的就是限流计数器。固定窗口计数器（FixedWindow）方法：通过单位时间设置，如秒、分钟、小时，采用离散计数的方法，统计这个时间段里的流量值，一旦请求大于阈值可承受范围，就会将这个请求拒绝掉。这种实现方案简单，而且内存优化，请求会在自己所属时间单位里计算，不会出现跨时间段的“阻塞现象”问题：因时间段临界点问题，导致统计结果可能有偏差。以1s限定1000请求为例，在上一个统计时间的后0.5s进入了1000个请求，在下一个统计时间的前0.5s也进入了1000个请求，因为时间的连续性，实际1s内请求达到了2000，那限流是不符合预期的。滑动窗口模式计数器（SlidingWindow）方法：对固定窗口的一种改进，原理类似TCP拥塞控制。将时间单位整合为多个区间，在区间内统计计数，统计区间逐步进行窗口滑动，解决临界点问题。问题：内存占用较大，请求及时间戳需保留。限流计数器设计缺陷一般来讲，限流计数器适用于否决式限流，无法进行排队式限流，对流量“整形”，实现削峰填谷无能为力。如果需要这样的功能，应该如何改进呢?最直观的想法，就是使用队列，将超额的流量进行暂存，延迟进行处理。实现这种能力的算法模型，就是我们熟悉的漏桶算法。漏桶算法漏桶算法（LeakyBucket）如上图所示，网络流量和水流一样，不断的进入到系统，当我们系统的可承载能力很小的情况下，我们可以将超额的水在一个桶里暂存起来。当系统处理完前面的流量以后，后面的流量就会接着进行处理，这就起到了削峰填谷、流量限速的作用。下面为示意代码。漏桶Golang示意代码requests:=make(chanint,5)fori:=1;i10万；不同于Kafka，TDMQPulsar的消费者数量不受限于Topic的分区数，可启动更多的消费者提升处理能力；支持全局/局部顺序消息、定时消息、延时消息，满足各种业务需求。热数据缓存-TDSQLRedis上面说了写请求的优化，接下来再说一下读请求的优化。读请求前面提到，可以在客户层进行缓存，也可以在CDN层进行缓存，但更重要的是需要在数据库前也进行一次缓存，使得读请求不会直接到达系统最薄弱的环节——数据库，形成一个“冲突缓存带”。这里我们常将一些热点数据放在Redis里来供大促期间使用。产品优势超高性能；标准版10万+QPS；集群版支持千万级QPS；自动容灾切换；双机热备架构；主机故障后，访问秒级切换到备机，无需用户干预；在线扩容；控制台一键操作扩容；扩容过程中无需停服。标准版架构集群版架构总结除了本文提到的高并发秒杀场景外，在互联网服务的很多场景下，当系统希望实现高可用、高性能、高扩展的设计目标，都会使用到腾讯云云原生网关产品所提供的能力，比如灰度发布、全链路染色、多环境路由和多活容灾等架构。云原生网关（Cloud-NativeGateway）是腾讯云基于开源网关Kong推出的一款高性能高可用的网关产品，100%完美兼容开源。同时提供TKE/EKS集群直通，Nacos/Consul/Polaris/Eureka注册中心对接，实例弹性扩缩容等能力，并有特色能力插件增强，显著减少用户自建网关带来的开发及运维成本。另外，多可用区部署的模式，也保证了业务连续性，避免单可用区故障带来的服务中断。无论在微服务架构下还是传统Web架构下，云原生网关都能以流量网关、安全网关和服务网关所需要的各种能力特性，为业务云上部署提供助力。往期推荐《微服务上云快速入门指引》《ApachePulsar在微信大流量实时推荐场景下的实践》《好未来基于北极星的注册中心最佳实践》《百万级Topic，ApachePulsar在腾讯云的稳定性优化实践》《预告|ArchSummit全球架构师峰会杭州站即将盛大开幕》《PolarisMesh北极星V1.11.3版本发布》《SpringCloudTencent1.7版本最新发布》《腾讯云微服务引擎TSE产品动态》《千亿级、大规模：腾讯超大ApachePulsar集群性能调优实践》《云原生时代的Java应用优化实践》《全面兼容Eureka：PolarisMesh(北极星)发布1.5.0版本》《全面拥抱Go社区：PolarisMesh全功能对接gRPC-Go|PolarisMesh12月月报》《SpringBoot应用优雅接入北极星PolarisMesh》扫描下方二维码关注本公众号，了解更多微服务、消息队列的相关信息！解锁超多鹅厂周边！