互联网应用如何进行流量削峰,应对瞬间请求?

互联网应用经常会遇到要处理高峰问题,这也是我所负责业务经常要面对的事情,比如遇到一个热点事件、或者策划一个活动(比如说秒杀),访问的骤增带来读写的流量的骤增,每个环节都面对瞬间请求骤增的问题,那么有哪些方法可以做到流量削峰或者说流量削峰要从哪几个方面考虑呢,说下我的浅见:

1、基于SOA的架构设计,弹性扩展瓶颈模块服务器资源;
2、接入层以及各服务模块极大的用好cache,增加QPS,从而加大整个集群的吞吐量;
3、模块间使用消息队列通信,进行模块异步解耦,访问量上来后,使用时间成本换取业务能够正常服务;
4、各服务模块对自身负责的同时,要做好后端依赖有效调用的判断,做到向上游模块所做的调用都是必要的调用,无冗余或无效的调用;

5、划分好动静资源,静态资源使用CDN进行服务分发。

在资源有限的情况下,做好各模块的降级预案,再从这5个方面多做努力,高峰期服务集群的流量会做到及好提升的。

时间: 2024-10-16 07:32:42

互联网应用如何进行流量削峰,应对瞬间请求?的相关文章

信析宝智能短信是什么 智能短信成互联网新的场景流量入口

信析宝是直接纳入手机系统的SDK 产品,可以改造手机自带短信 信析宝是一套基于语义识别技术的场景化构建平台,该平台由语义解析引擎,场景构建引擎,算法生成引擎和云端运营平台组成. 信析宝以SDK的方式输出语义解析和场景构建服务,能将接收到的文字形态的企业短信.IM消息.邮件等信息进行智能识别,生成结构化数据,并为之匹配相应的场景,让阅读和处理信息变得更高效,给用户更好的应用体验. 信析宝目前主要应用在手机系统原生的短信.IM社交软件.邮件.手机桌面上,将传统的短信.邮件的内容进行智能识别,并根据内

互联网金融高并发方案

小微金融.场景金融等新兴银行金融业务亟需一种新型的弹性架构来应对高并发.大流量的业务冲击,同时,要满足应用快速版本迭代升级.敏捷运维管理等需求.本文分享了BoCloud博云如何利用互联网应用架构与Docker容器技术帮助银行业应对“互联网+”挑战,建设基于PaaS平台的敏捷IT架构. 移动互联网渠道创新是传统企业无法也不能躲避的业务变革,无论是接入或者自建互联网渠道都需要回答如下问题:现在的IT架构能否应对互联网渠道创新业务的爆炸性冲击?什么样的IT架构才能够解决这个问题并具备应对未来需求的良好

Java电商秒杀系统深度优化 从容应对亿级流量挑战

第1章 课程导学[学前须知]本章对这门课程进行说明,包括:电商秒杀场景的介绍.秒杀系统涉及模块的介绍,秒杀核心的知识点的介绍,课程的学习规划等. 第2章 秒杀项目框架回顾[秒杀免费课程场景解析,源码走读]本章会介绍前期秒杀免费课程当中所涉及的基础框架搭建知识,项目分层,源码导读等,帮助大家更快的理解秒杀的基础项目,为后续更深一步的课程学习打基础.如果小伙伴们对免费课相关内容已经非常熟悉,可以跳过此章! 第3章 云端部署,性能压测[从本地调试到云端上线的必经之路]本章结合前面的秒杀项目介绍了他在云

大型网站技术架构:摘要与读书笔记

花了几个晚上看完了<大型网站技术架构>这本书,个人感觉这本书的广度还行,深度还有些欠缺(毕竟只有200页左右).但是作为一个缺乏大型网站技术的IT民工,看完一遍还是很有收获的,至少对一个网站的技术演进.需要解决的问题有了一个全面的认识.文中也有一些作者个人的心得.感悟.总结,我觉得还是很中肯的. 在网上一搜,这本书的读书笔记还是很多的,而我自己还是决定写一篇读书笔记,主要是为了避免自己忘得太快.笔记的内容并不完全按照原书的内容,主要记录的是我自己感兴趣的部分. 本文地址:http://www.

「技术干货」Pontus-用友云限流服务

在我们讨论系统稳定性的时候,其实核心的关键词就是容量规划,如何做好业务容量与系统性能的评估,是保障系统稳定性的关键.对于系统性能的评估,需要我们具备自动化工具来对系统进行性能压测,探测系统在实际业务场景下的基线数据,这是我们进行系统资源配置的基础,也是在应对流量增长时进行弹性扩容的依据.在我们做好容量规划的前提下,在实际业务场景下,我们还是不可避免的会面对不确定的系统压力,在面对突发不确定流量的情况下,我们最担心的就是系统的"雪崩".就像突然爆发的车流让道路交通瘫痪一样,我们的系统在突

【转载】千万级规模高性能、高并发的网络架构经验分享

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重视它,战术上又要藐视它.先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右.对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 .为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据

【并发与负载】千万级规模高性能、高并发的网络架构经验分享

架构以及我理解中架构的本质 在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它.先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右.对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 .为什么我们又不能说轻视它?第一,

千万pv大型web系统架构,学习从点滴开始

架构,刚开始的解释是我从知乎上看到的.什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像.更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见. 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力.这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中

消息队列(一)

消息队列MQ 维基百科中是这样介绍消息队列的 消息队列(Message queue)是一种进程间通信或同一进程的不同线程间的通信方式,软件的贮列用来处理一系列的输入,通常是来自用户.消息队列提供了异步的通信协议,每一个贮列中的纪录包含详细说明的数据,包含发生的时间,输入设备的种类,以及特定的输入参数,也就是说:消息的发送者和接收者不需要同时与消息队列交互.消息会保存在队列中,直到接收者取回它 58沈剑是这样介绍消息队列的 消息队列,是一种跨进程的通信机制,用于上下游传递消息.在互联网架构中,MQ