设计抗住千万级流量的架构思路(转)
随着互联网的发展,各项软件的客户量日益增多,当客户量达到一定峰值时,当数以万计的流量来临时,程序的顺利运行以及即时响应则显得尤为重要,就像双11那天的淘宝一样。那么,如何设计架构才能够抗住这千万级的流量。
首先,要在我们架构设计的时候建立一些原则。
1.实现高并发
服务拆分:将整个项目拆分成多个子项目或者模块,分而治之,将项目进行水平扩展。
服务化:解决服务调用复杂之后的服务的注册发现问题。
消息队列:解耦,异步处理
缓存:各种缓存带来的并发
2.实现高可用
集群、限流、降级
3.业务设计
幂等:就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用,就像数学里的数字1,多少次幂的结果都是1。举个最简单的例子,那就是支付,用户购买商品后支付,支付扣款成功,但是返回结果的时候网络异常,此时钱已经扣了,用户再次点击按钮,此时会进行第二次扣款,返回结果成功,用户查询余额发现多扣钱了,流水记录也变成了两条...
详细内容参考 《分布式中的幂等性》https://www.cnblogs.com/vveiliang/p/6643874.html
防重:防止同样的数据同时提交
除了在业务方向判断和按钮点击之后不能继续点击的限制以外,在服务器端也可以做到防重:
在服务器端生成一个唯一的随机标识号(Token<令牌>)同事在当前用户的Session域中保存这个令牌,然后将令牌发送到客户端的form表单中,在form表单中使用隐藏域来存储这个Token,表单提交的时候联通这个Token一起提交到服务器,然后在服务器端判断客户提交上来的Token与服务器端生成的Token是否一致,如果不一致,那就重复提交了,此时服务器端就可以不处理重复提交的表单,如果相同则处理表单,处理完后清楚当前用户的Session域中存储的标识号。
在下列情况中,服务器程序将拒绝处理用户提交的表单请求:
1)存储Session域中的Token与表单提交的Token不一致
2)当前用户的Session中不存在Token
3)用户提交的表单数据中没有Token。
状态机
软件设计中的状态机概念,一般是指有限状态机(英语:finite-state machine,缩写:FSM)又称有限状态自动机,简称状态机,是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。
这里着重讲一下限流的概念和例子
限流的目的:
限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的请求进行限速来保护系统的可用性,一旦达到限制速率就可以拒绝服务。就像手机预售一样,假如要卖出3万台,只需要接收3万用户的请求就可以,其他的用户请求可以选择过滤,可以提示"当前服务器过忙,请稍后再试"的提示。
限流方式:
1. 限制瞬时并发数 : 比如在入口层(nginx添加nginx_http_limit_conn_module)来限制同一个ip来源的连接数,防止恶意攻击访问的情况。
2,限制总并发数:通过配置数据库连接池、线程池大小来约束总并发数
3. 限制时间窗口内的平均速率:在接口层面,通过限制访问速率来控制接口的并发请求。
4. 其他方式:限制远程接口的调用速率、限制MQ的消费速率。
常用限流算法
1.滑动窗口协议:一种常见的流量控制技术,用来改善吞吐量的技术。
滑动窗口协议的由来:
滑动窗口(sliding window)是一种流量控制技术。早期的网络通讯中,通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况,同时发送数据,导致中间节点阻塞掉包,谁也发送不了数据,所以就有了滑动窗口机制来解决此问题。 发送和接收方都会维护一个数据帧的序列,这个序列被称为窗口。
定义:滑动窗口协议(Sliding Window Protocol),属于TCP协议的一种应用,用于网络数据传输时的流量控制,以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输,提高网络吞吐量。
发送窗口:就是发送端允许连续发送的帧的序号表。发送端可以不等待应答而连续发送数据(可以通过设置窗口的尺寸来控制)
接收窗口:接收方允许接收的帧的序列表,凡是落在接收窗口内的帧,接收方都必须处理,落在接收窗口外的帧将被丢弃。接收方每次允许接收的帧数称为接收窗口的尺寸
演示地址:https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/selective-repeat-protocol/index.html
2.漏桶:漏桶算法能强行限制数据的传输速率。
漏桶算法思路很简单,请求先进入到漏桶里,漏桶以一定的速度出水。当水请求过大会直接溢出,可以看出漏桶算法能强行限制数据的传输速率。进入端无需考虑出水端的速率,就像mq消息队列一样,provider只需要将消息传入队列中,而不需要关心Consumer是否接收到了消息。
对于溢出的水,就是被过滤的数据,可以直接被丢弃,也可以通过某种方式暂时保存,如加入队列之中,像线程池里对溢出数据的4种处理机制一样
3.令牌桶:属于控制速率类型的限流算法。
对于很多应用场景来说,除了要求能够限制数据的平均传输速率外,还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了,令牌桶算法更为适合。令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌,而如果请求需要被处理,则需要先从桶里获取一个令牌,当桶里没有令牌可取时,则拒绝服务。
设置 Rate = 2 :每秒放入令牌的个数
桶的大小:100
这里用一个小demo来实现一下令牌桶
public class TokenDemo {//qps:每秒钟处理完请求的次数;tps:每秒钟处理完的事务次数//代表qps是10;RateLimiter rateLimiter = RateLimiter.create(10);public void doSomething(){if (rateLimiter.tryAcquire()){//尝试获得令牌.为true则获取令牌成功System.out.println("正常处理");}else{System.out.println("处理失败");}}public static void main(String args[]) throws IOException{/** CountDownLatch是通过一个计数器来实现的,计数器的初始值为线程的数量,此值是线程将要等待的操作数(线程的数量)。* 当某个线程为了想要执行这些操作而等待时, 它要使用 await()方法。* 此方法让线程进入休眠直到操作完成。* 当某个操作结束,它使用countDown() 方法来减少CountDownLatch类的内部计数器,计数器的值就会减1。* 当计数器到达0时,它表示所有的线程已经完成了任务,这个类会唤醒全部使用await() 方法休眠的线程们恢复执行任务。** */CountDownLatch latch = new CountDownLatch(1);Random random = new Random(10);TokenDemo tokenDemo = new TokenDemo();for (int i=0;i<20;i++){new Thread(()->{try {latch.await();Thread.sleep(random.nextInt(1000));tokenDemo.doSomething();}catch (InterruptedException e){e.printStackTrace();}}).start();}latch.countDown();System.in.read();}}
执行结果:
正常处理
正常处理
正常处理
正常处理
正常处理
处理失败
正常处理
处理失败
处理失败
处理失败
正常处理
处理失败
正常处理
处理失败
正常处理
正常处理
正常处理
正常处理
处理失败
处理失败
由此可见,当令牌不足时,会获取令牌失败,达到限流的效果。
4.计数器:最简单的一种。通过控制时间段内的请求次数。
转自:https://www.cnblogs.com/GodHeng/p/8834810.html
转载于:https://www.cnblogs.com/helios-fz/p/10932511.html
设计抗住千万级流量的架构思路(转)相关推荐
- 如何打造一个抗住千万级流量短信服务(续)
前言 在之前写过一篇博文<短信服务设计>当时讲述了设计的思路,有很多读者朋友反馈说想了解具体的设计思路:今天又重新回顾下当时的具体实现细节发现当时实现的还是有一些巧妙的地方,值得大家参考, ...
- 老板让你抗住千万级流量,如何做架构设计?
来源:cnblogs.com/GodHeng/p/8834810.html 随着互联网的发展,各项软件的客户量日益增多,当客户量达到一定峰值时,当数以万计的流量来临时,程序的顺利运行以及即时响应则显得 ...
- 阿里P8面试官:如何设计一个扛住千万级并发的架构(超级详细)
如何降低RT的值 继续看上面这个图,一个请求只有等到tomcat容器中的应用执行完成才能返回,而请求在执行过程中会做什么事情呢? 查询数据库 访问磁盘数据 进行内存运算 调用远程服务 这些操作每一个步 ...
- 一招上手!这样设计扛住亿级流量活动系统
作者 | 刘艳杰 责编 | 伍杏玲 出品 | CSDN云计算(CSDNcloud) 在企业里,做活动是一种十分常见的需求,有面向C端用户开展的活动,也有面向公司内部员工的活动.随着互联网技术的不断发展 ...
- 【商品架构day3】京东商品系统的演进之路 - 如何抗住亿级流量
本文来自京东尤凤凯老师的分享.商品,黄金交易流程最基础.最核心的环节,无商品不电商.商品数据无处不在,商家(采销.供应商)发布管理.供应商下采购单.仓储配送.促销.搜索.商详页展现.购物支付.财务结算 ...
- 大型电商平台如何抗住亿级流量之布隆过滤器
目录 前言 正文 什么是布隆过滤器 布隆过滤器有什么用 1.若干次 Hash 来确定其位置 2.布隆过滤器在电商商品中的实践 3.如何减少布隆过滤器的误判? 开发中,如何使用布隆过滤器? 1.布隆过滤 ...
- 【大型分布式网站】抗住千万流量的大型分布式系统架构设计
一.大型分布式网站架构技术 1.1 大型网站的特点 用户多,分布广泛 大流量,高并发 海量数据,服务高可用 安全环境恶劣,易受网络攻击 功能多,变更快,频繁发布 从小到大,渐进发展 以用户为中心 免费 ...
- mysql 亿级高并发_亿级流量系统架构之如何设计每秒十万查询的高并发架构.md
亿级流量系统架构之如何设计每秒十万查询的高并发架构 一.前情回顾 上篇文章(亿级流量系统架构之如何设计承载百亿流量的高性能架构)聊了一下系统架构中,百亿流量级别高并发写入场景下,如何承载这种高并发写入 ...
- 每秒10万并发 mysql_亿级流量系统架构之如何设计每秒十万查询的高并发架构
一.前情回顾 上篇文章(亿级流量系统架构之如何设计承载百亿流量的高性能架构)聊了一下系统架构中,百亿流量级别高并发写入场景下,如何承载这种高并发写入,同时如何在高并发写入的背景下还能保证系统的超高性能 ...
最新文章
- 如何配置一台深度学习工作站?
- python读取目录_Python读取一个目录下所有目录和文件
- css搜索框变圆脸角,CSS浮动布局
- 《机器学习实战》chapter 11 使用apriori算法进行关联分析
- mac 使用 php artisan,在Mac php artisan上設置Laravel遷移錯誤:沒有這樣的文件或目錄[duplicate]...
- 【04】Effective Java - 类和接口
- std::atomic和std::mutex区别
- Linux(debian7)操作基础(四)之CPU频率调整
- java用链表 编写记事本_(超详细) 动手编写 — 链表 (Java实现)
- java具有回收垃圾的作用吗_Java中垃圾回收功能
- Android中使用字体库的方法
- python图像风格迁移教程_Python+OpenCV图像风格迁移的实现方法讲解
- android WebView去广告 使用javascript脚本去除webView广告(两种思路)
- sqlilabs-mysql数据库注入靶场-page2
- sdp ddp内存怎么分_3600超到4266,阿斯加特洛极W3内存超频记录
- 阿里云数加案例-美柚
- 10 个提升效率的Linux小技巧
- 尼尔森F形状网页浏览模式
- MATLAB计算二元一次方程组
- 产品经理之PRD详解(非原创)
热门文章
- (计算机组成原理)第二章数据的表示和运算-第二节7:详解C语言中的强制类型转换
- Python pyppeteer通过cookie获取数据(cookie爬虫)
- Redis Info 命令
- 查看Linux内核版本、系统版本命令
- matlab主程序和子函数不在一个文件夹下,怎么调用?
- SQLSERVER 执行过的语句查询
- Memcached服务端自动启动(转载)
- Tomcat的目录结构详解
- Redis如何高效可靠地实现主从复制?终于有人讲明白了
- uitableview 弹性_iOS UITableView滚动头图 拉伸放大效果 (头部弹性效果) 增加iOS11支持 附有demo...