🌏【架构师指南】分布式技术知识点总结(下)
每日一句
人生由淡淡的悲伤和淡淡的幸福组成,在小小的期待、偶尔的兴奋和沉默的失望中度过每一天,然后带着一种想说却又说不出来的“懂”,作最后的转身离开。
分布式系统设计策略
心跳检测机制
周期检测心跳机制
Server 端每间隔 t 秒向 Node 集群发起监测请求,设定超时时间,如果超过超时时间,则判断“死亡”。
累计失效检测机制
在周期检测心跳机制的基础上,统计一定周期内节点的返回情况(包括超时及正确返回),以此计算节点的“死亡”概率。
高可用(High Availability)
高可用是系统架构设计中必须考虑的因素之一。通常是指,经过设计来减少系统不能提供服务的时间。\
系统高可用性的常用设计模式包括三种:
主备(Master-SLave)
互备(Multi-Master)
集群(Cluster)模式
高可用 HA 下"脑裂问题"
在高可用(HA)系统中,当联系两个节点的"心跳线"断开时(即两个节点断开联系时),本来为一个整体、动作协调的 HA 系统,就分裂成为两个独立的节点(即两个独立的个体)。
【脑裂预防方案】
添加冗余的心跳线 [即冗余通信的方法]:同时用两条心跳线路 (即心跳线也 HA),这样一条线路坏了,另一个还是好的,依然能传送心跳消息,尽量减少"脑裂"现象的发生几率。
【仲裁机制】
当两个节点出现分歧时,由第 3 方的仲裁者决定听谁的。这个仲裁者,可能是一个锁服务。
【隔离(Fencing)机制】
共享存储 fencing:确保只有一个 Master 往共享存储中写数据;
客户端 fencing:确保只有一个 Master 可以响应客户端的请求;
Slave fencing:确保只有一个 Master 可以向 Slave 下发命令。
负载均衡
轮询(次数 hash):默认方式,每个请求会按时间顺序逐一分配到不同的后端服务器
weight:权重方式,在轮询策略的基础上指定轮询的几率,权重越大,接受请求越多
ip_hash:依据 ip 分配方式,相同的客户端的请求一直发送到相同的服务器,以保证 session 会话
least_conn:最少连接方式,把请求转发给连接数较少的后端服务器
fair(第三方):响应时间方式,按照服务器端的响应时间来分配请求,响应时间短的优先分配
url_hash(第三方):依据 URL 分配方式,按访问 url 的 hash 结果来分配请求,使每个 url 定向到同一个后端服务器
Random 随机机制。
服务限流
限流算法-计数器(固定窗口)计数器限制每一分钟或者每一秒钟内请求不能超过一定的次数,在下一秒钟计数器清零重新计算。存在问题:客户端在第一分钟的 59 秒请求 100 次,在第二分钟的第 1 秒又请求了 100 次, 2 秒内后端会受到 200 次请求的压力,形成了流量突刺
限流算法-计数器(滑动窗口)滑动窗口其实是细分后的计数器,它将每个时间窗口又细分成若干个时间片段,每过一个时间片段,整个时间窗口就会往右移动一格。时间窗口向右滑动一格,这时这个时间窗口其实已经打满了 100 次,客户端将被拒绝访问,时间窗口划分的越细,滑动窗口的滚动就越平滑,限流的效果就会越精确
限流算法-漏桶(削峰填谷)漏桶算法类似一个限制出水速度的水桶,通过一个固定大小 FIFO 队列+定时取队列元素的方式实现,请求进入队列后会被匀速的取出处理(桶底部开口匀速出水),当队列被占满后后来的请求会直接拒绝(水倒的太快从桶中溢出来)
限流算法-令牌桶令牌桶算法是以一个恒定的速度往桶里放置令牌(如果桶里的令牌满了就废弃),每进来一个请求去桶里找令牌,有的话就拿走令牌继续处理,没有就拒绝请求。
令牌桶的优点是可以应对突发流量缺点就是相对漏桶一定程度上减小了对下游服务的保护
版权声明: 本文为 InfoQ 作者【李浩宇/Alex】的原创文章。
原文链接:【http://xie.infoq.cn/article/0628caef1d55335055265a680】。文章转载请联系作者。
评论