登录
/
注册
首页
论坛
其它
首页
科技
业界
安全
程序
广播
Follow
园子
关于
博客
发1篇日志+1圆
记录
发1条记录+2圆币
发帖说明
登录
/
注册
账号
自动登录
找回密码
密码
登录
立即注册
搜索
搜索
关闭
CSDN热搜
程序园
精品问答
技术交流
资源下载
本版
帖子
用户
软件
问答
教程
代码
VIP申请
网盘
联系我们
道具
勋章
任务
设置
我的收藏
退出
腾讯QQ
微信登录
返回列表
首页
›
业界区
›
业界
›
读发布!设计与部署稳定的分布式系统(第2版)笔记09_一 ...
读发布!设计与部署稳定的分布式系统(第2版)笔记09_一窝蜂和容量
[ 复制链接 ]
暴灵珊
前天 20:09
1. 停电事故后电力恢复的方式
1.1. 停电后常见的情形是,送电几秒钟后又再次断电
1.2. 数百万台空调和冰箱的用电需求,使刚刚恢复的电力供应发生过载
1.3. 当电力供应不足时,增加的电流很快就到达满负荷,导致过载,触发断路器跳闸,灯再次熄灭
2. 经验教训
2.1. 系统规模相对较小的组件子集上永远不会出现这种情况
2.2. 系统达到稳态时的负载,会与系统启动或周期性运行的负载存在明显不同
2.3. 示例
2.3.1. 一个应用程序服务器农场的启动过程
2.3.2. 每台服务器都需要连接到数据库,并加载一定数量的参考数据或种子数据
2.3.3. 每台服务器的缓存都从空闲状态开始,逐渐形成一个有用的工作集
2.3.4. 大多数HTTP请求会转换为一个或多个数据库查询
2.3.5. 当应用程序启动时,数据库上的瞬时负载要比运行一段时间后的负载高得多
3. 一窝蜂
3.1. 一堆服务器一同对数据库施加瞬时负载
3.2. 是对系统的集中使用,相比将峰值流量分散开后所需的系统能力,一窝蜂需要一个更高的系统容量峰值
3.3. 一窝蜂所需系统成本过高,高峰需求无法处理
3.4. 引发一窝蜂现象的情况
3.4.1. 在代码升级和重新运行之后,启动多台服务器
3.4.2. 午夜(或任何一个整点时间)触发cron作业
3.4.3. 配置管理系统推出变更
3.4.4. 当一些外部现象引起流量的同步“脉冲”时
3.4.5. 阻塞许多线程的所有地方,它们在等待某个线程完成工作
3.4.5.1. 这个状态打破时,新释放的线程就会对任何接收数据包的下游系统施加一窝蜂
3.4.6. 虚拟用户的脚本存在固定等待时间,则在进行负载测试时,就会产生流量脉冲
3.4.6.1. 脚本中的每个等待时间都应该附带一个小的随机时间增量
3.5. 解决方案
3.5.1. 使用增加的退避时间避免脉冲
3.5.1.1. 固定的重试时间间隔,会集中那段时间的调用方需求
3.5.1.2. 使用退避算法,不同调用方在经过自己的退避时间后,在不同的时间点发起调用
3.5.2. 使用随机时钟摆动以分散需求
3.5.2.1. 不要将所有cron作业都设置在午夜或其他任何整点时间执行
3.5.2.2. 混合的方式设置时间,分散负载
4. 系统容量
4.1. 无论系统资源是需要数月、数周还是数秒才能完成整备,最终都可能导致不同层级之间的处理速率不匹配
4.2. 由于容量不对等,前端总是有能力来压倒后端
4.3. 将系统容量均匀地进行匹配,是不切实际的
4.3.1. 除了某一天会派上用场,其他时间99%的基础设施将处于闲置状态
4.4. 对于服务的构建,如果不能使之全部满足前端潜在的压倒性需求,那么就必须构建服务调用方和服务提供方的韧性,从而能够应对海啸般袭来的请求
4.5. 对服务调用方来说,当响应获取速度变慢或连接被拒绝时,使用断路器模式有助于缓解下游服务的压力
4.6. 对服务提供方来说,可以使用握手和背压通知调用方,限制调用方发送请求的速度
4.7. 使用舱壁模式,为关键服务的高优先级调用方预留系统容量
5. 系统容量失衡
5.1. 放大效应的特例
5.2. 在QA环境中很少能观察到的问题
5.2.1. 主要原因是每个系统的QA环境通常会缩小到只有两台服务器
5.2.2. 检查服务器和线程的数量
5.2.3. 实现QA环境虚拟化并实现扩展
5.2.4. 重视接口的两侧
5.3. 考验机能帮助验证前端系统能否良好地实现降级
5.4. 关系中一方的增幅变化大大超过另一方
5.5. 宣传带来的流量高峰,就更难以预测了
5.5.1. 自黑式
5.5.2. 季节性、市场驱动或宣传驱动等流量模式的变化,会导致前端系统的大量请求涌向后端系统(通常是良性的),就像热门的社交媒体帖子导致网站流量剧增
5.6. 要为出现任何状况做好准备
5.6.1. 可以使用系统容量建模的方法,确保系统能力至少在可变范围之内
5.6.2. 如果系统具有韧性,那么它可能会减慢处理速度,甚至当无法在允许的时间内处理事务时,就开始出现“快速失败”
5.6.2.1. 当负载压力减弱后,系统应该还能够恢复回来
5.6.3. 使用自动扩展应对激增的访问请求
5.6.3.1. 存在时间相对滞后的问题,并且还会将问题向下转移到超载的平台服务上
来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
回复
使用道具
举报
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
相关推荐
那些年搞不懂的高深术语——依赖倒置•控制反转•依赖注入•面向接口编程
如何优雅的使用RabbitMQ
分布式锁1 Java常用技术方案
浅谈我对DDD领域驱动设计的理解
游戏编程十年总结(下)
【前端性能】高性能滚动 scroll 及页面渲染优化
验证码对抗之路及现有验证机制介绍
从零开始入门 K8s | 手把手带你理解 etcd
中文写程序,何陋之有?
NHibernate之旅(2):第一个NHibernate程序
公司的中场
Android 系统缺陷不完全点评
谈谈如何从本质上理解sql语句, 存储过程,ORM之间的联系和取舍。
FFmpeg开发笔记(六十二)Windows给FFmpeg集成H.266编码器vvenc
[一步一步MVC]第一回:使用ActionSelector控制Action的选择
.net环境下跨进程、高频率读写数据
第二个iPhone应用程序:“Say Hello”
从零开始学习jQuery (十一) 实战表单验证与自动完成提示插件
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
|
立即注册
回复
本版积分规则
回帖并转播
回帖后跳转到最后一页
浏览过的版块
代码
签约作者
程序园优秀签约作者
发帖
暴灵珊
前天 20:09
关注
0
粉丝关注
15
主题发布
板块介绍填写区域,请于后台编辑
财富榜{圆}
敖可
9988
处匈跑
9998
森萌黠
9996
4
堵赫然
9996
5
凶契帽
9996
6
柴古香
9996
7
背竽
9996
8
斜素欣
9994
9
恐肩
9994
10
里豳朝
9994
查看更多