千万级流量冲击下,如何保证极致性能

· 浏览次数 : 0

小编点评

随着互联网的快速发展,网络应用的流量规模不断扩大,特别是在电商大促、明星直播、重大赛事、头条热搜等热点事件中,秒级100w请求成为了常态。如何在这样的流量冲击下确保系统稳定、高效地处理每一个请求,为用户提供极致的体验,成为了技术团队面临的重要挑战。本文将深入探讨在超高流量下如何保证系统的极致性能。 一、系统架构优化 在应对千万级流量时,我们需要采用分布式、微服务化的架构,将业务拆分成多个独立的服务,每个服务负责处理特定的业务逻辑。通过水平扩展和垂直扩展相结合的方式,提升系统的整体处理能力。微服务架构可以参考作者的微服务系列文章。 二、负载均衡技术 负载均衡是实现高并发的关键技术之一。通过负载均衡器,我们可以将请求分发到多个服务器上,实现请求的均衡处理。常见的负载均衡策略包括轮询、加权轮询、最少连接数等。在实际应用中,我们可以根据业务需求和服务器性能选择合适的负载均衡策略,来协调多实例服务对每个分片流量分配的需求。负载均衡可以参考作者的文章《图解常用负载均衡策略》。 三、异步处理与并发控制 通过引入异步处理机制,我们可以将耗时操作放在后台执行,避免阻塞主线程,提高系统的响应速度。同时,合理的并发控制也是必不可少的,我们可以利用线程池、信号量等技术手段来控制并发量,避免系统过载。 1. 异步处理:处理一项任务的时候,有A、B、C三个步骤,需要先完成A操作,然后做B、C操作。任务执行成功与否强依赖A的结果,但不依赖B、C的结果。如果我们使用串行的执行方式,那处理任务的周期就会变长,系统的整体吞吐能力也会降低。所以使用消息队列是比较好的办法。 2. 削峰:将峰值期间的操作削减,比如A同学的整个操作流程包含12个步骤,后续的11个步骤是不需要强关注结果的数据,可以放在消息队列中。 3. 并发控制:可以通过一些办法来进行并发控制,如无效请求过滤和加锁等,避免大量的请求把系统冲垮。Web端/客户端的超预期请求过滤大部分的用户是没有耐心的,当你的系统因为吞吐过载迟钝(响应延迟)的时候,用户可能会反复的点击按钮、刷新页面来重启发送请求。这样会对原本就瓶颈的系统造成更大的伤害。最好的办法就是服务端响应回来或超时之前,对用户的重复请求无效。 4. 系统入口处(如网关接入层)的超预期请求过滤大部分操作是需要有幂等性保障的。同一个用户对一个服务批量且持续的请求必然是不正常的,要么是程序错误导致的循环请求,要么是攻击性行为。可以根据用户Id或者用户的登录Token来识别用户,避免单位时间内(比如1s)的过量调用(比如1000次),通过这种限制来达到控制无效流量的目的。 四、缓存策略 缓存是提升系统性能的重要手段。通过缓存热点数据,我们可以减少对数据库的访问次数,降低数据库的压力。同时,缓存还可以提高数据的访问速度,提升用户体验。在实际应用中,我们可以采用Redis等内存数据库作为缓存层,通过合理的缓存策略实现数据的快速访问。Redis官方站点中,有对Redis性能做了比较详细的压测,可以参考官方这一篇:How fast is Redis? 五、数据库优化 数据库是系统的核心组件之一,其性能直接影响到整个系统的性能。在应对高并发请求时,我们需要对数据库进行优化,包括优化SQL语句、建立合适的索引、分库分表、数据单元化设计等。通过数据库优化,我们可以提高数据的查询速度,减少数据库的负载,从而提升整个系统的性能。数据库的优化可以参考作者的两篇文章:MySQL索引优化总结(综合版)、MySQL分库分表。 六、流量限流 在流量高峰时段,我们可以通过限流技术来控制请求的速率,避免系统过载。限流的目标是在系统压力过大时拒绝部分请求,并且failover到固定的响应信息,保护系统的稳定性。以令牌桶原理(定速流入)为例,每秒钟只提供N个令牌,每个请求携带一个令牌标识前行,用完即限行。 七、总结 在千万级流量下保证并发请求的极致性能是一个复杂而挑战性的问题。通过综合运用系统架构优化、负载均衡技术、缓存策略、数据库优化等多种技术手段,我们可以有效地提升系统的处理能力和响应速度。同时,我们还需要根据具体的业务场景和性能需求进行针对性的优化和调整,以实现最佳的性能表现。在未来的发展中,随着技术的不断进步和业务的不断扩展,我们还将面临更多的挑战和机遇。只有不断地学习和探索新的技术手段和方法,我们才能更好地应对这些挑战,为用户提供更加优质、高效的服务体验。

正文

1 简要介绍

随着互联网的快速发展,网络应用的流量规模不断攀升,特别是在电商大促、明星直播、重大赛事、头条热搜等热点事件中,秒级100w请求成为了常态。在这样的流量冲击下,如何确保系统稳定、高效地处理每一个请求,为用户提供极致的体验,成为了技术团队面临的重要挑战。本文将深入探讨在超高流量下如何保证系统的极致性能。

2 架构建设方案

在解决千万级流量下的流量冲击问题时,我们需要综合运用多种技术手段,从系统架构、负载均衡、并发控制、缓存策略、数据库优化、限流等多个方面入手。

2.1 系统架构优化

系统架构是支撑高并发的基础。在应对千万级流量时,我们需要采用分布式、微服务化的架构,将业务拆分成多个独立的服务,每个服务负责处理特定的业务逻辑。通过水平扩展和垂直扩展相结合的方式,提升系统的整体处理能力
微服务架构可以参考作者的这个系列的文章《微服务系列
以下是微服务架构简图:
image

2.2. 负载均衡技术

负载均衡是实现高并发的关键技术之一。通过负载均衡器,我们可以将请求分发到多个服务器上,实现请求的均衡处理。
常见的负载均衡策略包括轮询、加权轮询、最少连接数等。在实际应用中,我们可以根据业务需求和服务器性能选择合适的负载均衡策略,来协调多实例服务对每个分片流量分配的需求。
负载均衡可以参考作者的这篇文章《图解常用负载均衡策略》。
以下是负载均衡器在架构中的位置和职能。
image

2.3 异步处理与并发控制

通过引入异步处理机制,我们可以将耗时操作放在后台执行,避免阻塞主线程,提高系统的响应速度。
同时,合理的并发控制也是必不可少的,我们可以利用线程池、信号量等技术手段来控制并发量,避免系统过载。

2.3.1 异步处理

互联网场景中经常使用消息中间件进行 异步处理\削峰 等操作,来缓解系统的压力。

1. 异步处理: 处理一项任务的时候,有3个步骤A、B、C,需要先完成A操作, 然后做B、C 操作。任务执行成功与否强依赖A的结果,但不依赖B、C 的结果。
如果我们使用串行的执行方式,那处理任务的周期就会变长,系统的整体吞吐能力也会降低(在同一个系统中做异步其实也是比较大的开销),所以使用消息队列是比较好的办法。

登录操作就是典型的场景:A:执行登录并得到结果、B:记录登录日志、C:将用户信息和Token写入缓存。 执行完A就可以从登录页跳到首页了,B、C让服务慢慢去消化,不阻塞当前操作。

image

2. 削峰: 将峰值期间的操作削减,比如A同学的整个操作流程包含12个步骤,后续的11个步骤是不需要强关注结果的数据,可以放在消息队列中。

2.3.2 并发控制

可以通过一些办法来进行并发控制,如无效请求过滤和加锁等,避免大量的请求把系统冲垮。

1. Web端/客户端的超预期请求过滤
大部分的用户是没有耐性的,当你的系统因为吞吐过载迟钝(响应延迟)的时候,用户可能会反复的点击按钮、刷新页面来重启发送请求。
这样会对原本就瓶颈的系统造成更大的伤害。最好的办法就是服务端响应回来或超时之前,对用户的重复请求无效。
如:限制用户在5秒之内只能提交一次请求,避免系统过载。

2. 系统入口处(如网关接入层)的超预期请求过滤
大部分操作是需要有幂等性保障的。同一个用户对一个服务批量且持续的请求必然是不正常的,要么是程序错误导致的循环请求,要么是攻击性行为。
可以根据用户Id或者用户的登录Token来识别用户,避免单位时间内(比如1s)的过量调用(比如1000次),通过这种限制来达到控制无效流量的目的。

3. 加锁进行并发控制

这些都是实现并发控制的关键机制。通过使用锁,我们可以确保在并发环境中对共享资源的访问是同步的,从而避免数据不一致或其他并发过载的问题。

2.4 缓存策略

缓存是提升系统性能的重要手段。通过缓存热点数据,我们可以减少对数据库的访问次数,降低数据库的压力。同时,缓存还可以提高数据的访问速度,提升用户体验。在实际应用中,我们可以采用Redis等内存数据库作为缓存层,通过合理的缓存策略实现数据的快速访问。

Redis官方站点中,有对Redis性能做了比较详细的压测,可以参考官方这一篇 How fast is Redis?
在较高的配置基准下(比如 8C 16G +),在连接数为0~10000的时候,最高QPS可达到120000。Redis以超过60000个连接为基准,仍然能够在这些条件下维持50000个q/s,体现了超高的性能。下图中横轴是连接数,纵轴是QPS。
image
下面这张图为data size 与整体吞吐量之间的趋向关系:
image

缓存可以扩展阅读作者的这个系列的文章:★ Redis24篇集合

2.5 数据库优化

数据库是系统的核心组件之一,其性能直接影响到整个系统的性能。在应对高并发请求时,我们需要对数据库进行优化,包括优化SQL语句、建立合适的索引、分库分表、数据单元化设计等。
通过数据库优化,我们可以提高数据的查询速度,减少数据库的负载,从而提升整个系统的性能。
image

数据库的优化可以扩展阅读作者这两篇文章:
MySQL索引优化总结(综合版)MySQL分库分表

2.6 流量限流

在流量高峰时段,我们可以通过限流技术来控制请求的速率,避免系统过载。限流的目标是在系统压力过大时拒绝部分请求,并且failover到固定的响应信息,保护系统的稳定性。
以令牌桶原理(定速流入)为例,每秒钟只提供N个令牌,每个请求携带一个令牌标识前行,用完即限行。如下图:
image

限流熔断可以扩展阅读笔者的这篇文章:微服务治理之限流、熔断

3 业务场景说明

在实际业务中,高并发的场景多种多样。以电商平台为例,在大促期间,大量的用户会同时访问平台,进行商品浏览、下单、支付等操作。这些操作都会产生大量的并发请求,对系统的性能提出极高的要求。此外,社交应用、在线游戏等也面临着类似的挑战。

4 总结

在千万级流量下保证并发请求的极致性能是一个复杂而挑战性的问题。通过综合运用系统架构优化、负载均衡技术、缓存策略、数据库优化等多种技术手段,我们可以有效地提升系统的处理能力和响应速度。同时,我们还需要根据具体的业务场景和性能需求进行针对性的优化和调整,以实现最佳的性能表现。
在未来的发展中,随着技术的不断进步和业务的不断扩展,我们还将面临更多的挑战和机遇。只有不断地学习和探索新的技术手段和方法,我们才能更好地应对这些挑战,为用户提供更加优质、高效的服务体验。

与千万级流量冲击下,如何保证极致性能相似的内容:

千万级流量冲击下,如何保证极致性能

1 简要介绍 随着互联网的快速发展,网络应用的流量规模不断攀升,特别是在电商大促、明星直播、重大赛事、头条热搜等热点事件中,秒级100w请求成为了常态。在这样的流量冲击下,如何确保系统稳定、高效地处理每一个请求,为用户提供极致的体验,成为了技术团队面临的重要挑战。本文将深入探讨在超高流量下如何保证系

上周热点回顾(6.10-6.16)

热点随笔: · 「指间灵动,快码加编」:阿里云通义灵码,再次降临博客园 (博客园团队)· 老生常谈!程序员为什么要阅读源代码? (Yxh_blogs)· 千万级流量冲击下,如何保证极致性能 (Hello-Brand)· 面试官:你讲下接口防重放如何处理? (程序员博博)· C#开发的目录图标更改器

千万级数据深分页查询SQL性能优化实践

最近接到了一个新需求,要求提供查询关注对象的粉丝列表接口功能。该功能的难点就是关注对象的粉丝数量过多,不少店铺的粉丝数量都是千万级别,并且有些大V粉丝数量能够达到上亿级别

稳定支撑千万级月活,华为日历背后的英雄

摘要:华为日历月活高达数千万,这使其对支撑业务的数据库提出了巨大挑战:高并发场景下,数据库如何实现快速扩容?海量数据运行,如何确保业务稳定性? 本文分享自华为云社区《稳定支撑千万级月活,华为日历背后的英雄》,作者: GaussDB 数据库。 随着科技进步,手机日历早已融入我们的生活,不仅可以记录时间

如何实现千万级优惠文章的优惠信息同步

金融社区优惠文章是基于京东商城优惠商品批量化自动生成的,每日通过不同的渠道获取到待生成的SKU列表,并根据条件生成优惠文章。 但是,生成优惠文章之后续衍生问题:该商品无优惠了,对应文章需要做取消推荐或下架处理,怎样能更快的知道该商品无优惠了呢?

一个混乱千万级软件项目

背景:公司接到一个亿级的项目,软件大概占到1/4的比例,整个项目包含了硬件和软件团队。软件团队是要实是一个软件产品,让其控制各种硬件设备做自动化运作,并打通上下游系统的数据。软件同时统计分析(包括机器学习和AI) 整个项目设备的运作和任务执行情况,服务于后续运营优化。 项目成员结构:大项目经理,对这

在云南,我用华为云AI开发出千万级用户的应用

摘要:创造无限,当“燃”是开发者,华为云1024程序员节,陶新乐和大家分享独立开发者的自由之路。 本文分享自华为云社区《在云南,我用华为云AI开发出千万级用户的应用》,作者:华为云社区精选。 在彩云之南,做一名独立开发者是种什么体验? 是每天醒来拉开窗帘,森林雪山跃入眼帘;是在苍山洱海边,沏一壶茶开

mysql 大表如何ddl 👑

大家好,我是蓝胖子,mysql对大表(千万级数据)的ddl语句,在生产上执行时一定要千万小心,一不小心就有可能造成业务阻塞,数据库io和cpu飙高的情况。今天我们就来看看如何针对大表执行ddl语句。 通过这篇文章,你能了解到下面的知识点, ![Pasted image 20230831165346.

[转帖]mysql百万级性能瓶颈-数据库选型

项目中使用了mysql数据库,但数据量增长太快,不久到了百万级,很快又到表到了千万级,尝试了各种优化方式,最终效果仍难达到秒级响应,那么引发了我关于数据库选型到一些思考。 1、mysql的单表性能瓶颈究竟是多少? 曾经在中国互联网技术圈广为流传着这么一个说法:MySQL 单表数据量大于 2000 万

[转帖]mysql百万级性能瓶颈-数据库选型

项目中使用了mysql数据库,但数据量增长太快,不久到了百万级,很快又到表到了千万级,尝试了各种优化方式,最终效果仍难达到秒级响应,那么引发了我关于数据库选型到一些思考。 1、mysql的单表性能瓶颈究竟是多少? 曾经在中国互联网技术圈广为流传着这么一个说法:MySQL 单表数据量大于 2000 万