架构师
文章平均质量分 61
记录架构师必备技能
chengqiuming
这个作者很懒,什么都没留下…
展开
-
SnowFlake 算法实现
一背景在分布式系统中,如何在各个不同的服务器产生ID值?例如,有一个订单系统部署在 A、B两个节点上,那么如何在这两个节点上产生各自的订单ID,并且保证ID值不会冲突。通常有三种解决方案。使用数据库的自增特性(或Oracle中的序列),不同节点直接使用相同数据库的自增ID值 使用UUID算法产生ID值 使用雪花算法生成ID值二雪花算法1说明SnowFlake 被称为雪花算法,它是分布式 ID 生成器。雪花算法是由 Twitter 公布的分布...原创 2022-03-18 19:22:54 · 3348 阅读 · 0 评论 -
TCC事务
一点睛TCC事务是“Try-Confirm-Cancel”三个单词的缩写。可靠性消息队列虽然能够保证最终结果的相对可靠性,过程也足够简单,但整个过程完全没有任何隔离性可言,虽然在一些业务中隔离性是无关紧要的,但在有些业务中缺乏隔离性就会带来许多麻烦。例如,缺乏隔离性就会带来的一个明显问题便是“超售”:如两个客户在短时间内都成功购买了同一件商品,而且他们各自购买的数量都不超过目前的库存,但他们购买的数量之和却超过了库存。如果这件事情属于刚性需求,且隔离级别足够时是可以完全避免的。例如,上面这个场景..原创 2022-03-13 09:54:32 · 3236 阅读 · 0 评论 -
可靠事件队列
一BASE理论BASE分别是基本可用性(BasicallyAvailable)、柔性事务(SoftState)和最终一致性(EventuallyConsistent)的缩写。二案例以交易过程中正确修改账号、仓库和商家服务中的数据为例进行说明。1最终用户向书店发送交易请求,购买一本价值为 100元的书。2系统首先应对用户账号扣款、商家账号收款、库存商品出库这三个操作做出一个出错率的先验评估,根据出错概率的大小来安排它们的操作顺序,这种评估一般直接体现在程序代码中,一...原创 2022-03-12 16:56:00 · 2893 阅读 · 0 评论 -
远程服务调用和进程间通信
一进程间通信远程服务调用(RPC)在计算机科学中已经存在超过四十年时间,但仍然对不少程序员来说,还是一个模糊的概念。RPC 出现的目的,就是为了能够与调用本地方法一样去调用远程方法。先看一段简单的Java代码public static void main(String[] args){ System.out.println("hello world")}运行这段代码要完成下面四个工作:a 传递方法参数b 确定方法版本c 执行被调用方法d 返回执行结果上...原创 2022-02-22 21:51:47 · 609 阅读 · 0 评论 -
Thread 的 stackSize
一点睛一般情况下,我们在Thread的构造函数中不会去指定stackSize,而是统一通过 xss参数进行设置,当stackSize越大,代表着正在线程内方法调用递归的深度越深。在某些平台下,越高的stackSize设定,可以允许的递归深度越深,反之,越少的stackSize设定,则递归深度越浅。当然在某些平台下,该参数压根就不起任何作用,如果该参数设置为0,也不起任何作用。二测试代码package concurrent;public class ThreadS...原创 2022-02-09 20:25:05 · 1030 阅读 · 0 评论 -
抽奖活动架构设计
一需求描述实现一个大转盘活动,用户有三次抽奖机会,每次抽奖后给用户返回中奖结果。中奖概率和奖品在活动前由产品经理给出一等奖——中奖概率为 1 %,1000元红包二等奖——中奖概率为 5 %,100元红包三等奖——中奖概率为 10 %,10 元红包其余为没有中奖用户通过具体页面可以看到中奖纪录。二需求分析我们发现中奖概率的格式是有问题的,只有中奖概率和奖品,没有奖品数量。没有奖品数量就是对预算没有控制,如果中奖数量超过了预算就会造成损失,所以在需求中要补充奖品数量和...原创 2022-02-06 17:05:19 · 3044 阅读 · 0 评论 -
统计用户在线时长
一需求描述一款在线游戏,玩家登录后可以选择挂机和游戏两种状态。 挂机状态:玩家不操纵游戏,游戏由系统托管。 游戏状态:玩家主动操纵游戏。 玩家刚登录时直接进入游戏状态,玩家的游戏状态如下图所示。在玩家的游戏面板上展示自上线后的挂机的累计时长和游戏的累计时长。此功能仅作为展示使用,目的是让玩家对挂机时间和主动游戏时间有一个概念,合理分配不同状态的时间。允许统计时间有一分钟内的时延。服务器端支持显示功能,计算好两个时长数据,供客户端展示。二项目背景该游戏服务器..原创 2022-02-05 11:53:27 · 7987 阅读 · 0 评论 -
流程和文化
一研发阶段典型流程二需求阶段一般在需求阶段都是产品经理写需求,程序员和架构师参与需求评审,确定实现需求的可行性和代价。一个高效的团队要有一套需求管理的系统,该系统能够展示需求的状态,是“未评审”“开发中”还是“已发布”等,并且记录整个需求的生命周期,通过该系统协同产品、设计、开发、测试等多个团队一起工作。在评审需求时,产品经理要保证需求的完整性——开发人员和测试人员通过阅读需求单就可以进行后续工作,而不是还要通过开会才能详细了解需求。产品经理要保证文档尽量详细,内容无歧义。目前可选用..原创 2022-02-01 17:06:40 · 414 阅读 · 0 评论 -
随机数在互联网业务中的应用
一 随机数的定义在信息学中,随机数的定义如下:随机性——不存在统计学偏差,是完全杂乱的数列。不可预测性——不能通过过去的数列推测出下一个出现的数。不可重现性——除非将数列本身保存下来,否则不能重现相同的数列。随机数可能在统计上呈现出某种规律。在工程上,主要是用到了随机数的两个特性。1 不可预测性2 均匀获取数字(在大量随机统计时,每个数出现的期望相同)在安全相关场景中,用到的是随机数的不可预测性。例如,生成秘钥、验证码等场景,让黑客不能找到生成的规律。在抽奖、负载均衡原创 2022-02-01 14:26:00 · 1617 阅读 · 0 评论 -
利用线性同余的一致性 Hash 算法
一 算法内容以下是线性同余的一致性 Hash 算法的全部代码。输入参数分别是 64 位的 key 和桶的数量(一般对于服务节点的数量),输出一个桶的编号(从0开始)。1 代码package consistenthash;/*** @className: JumpConsistentHash* @description: 利用线性同余的一致性 Hash 算法* @date: 2022/2/1* @author: 贝医*/public class JumpConsistentH原创 2022-02-01 12:46:10 · 660 阅读 · 0 评论 -
多阶 Hash设计和实现
一 多阶 Hash 设计多阶hash实现与分析 - 知乎二 多阶 Hash 实现https://github.com/zfengzhen/mem_hash原创 2022-01-31 18:30:50 · 834 阅读 · 0 评论 -
树状数组与排行榜
一问题引出互联网产品要设计一歀排行榜,该排行榜是基于分数进行排行,分值范围为[1,1000],每个分值可以有多个人。1小明的分值为 300分,求出它的排名。2一段时间后,部分用户的的分值都发生了变化,小明的分值也发生了变化,求他的排名。二树状数组1概念所有的正整数都可以用二进制表示。例如:34 = 2^1 + 2 ^712 = 2^2 + 2^334和 12的二进制表示如下对于一个整数i,lowbit(i)表示i的二进制最后一个位置1所...原创 2022-01-30 11:47:18 · 1539 阅读 · 0 评论 -
架构师的产品思维
工程师要以产品经理的角度思考问题。代码最终要变成产品,通过产品来提高服务。如果用户不接受产品,那么再好的代码也没有实际用途。如果一个架构师只关心程序的性能和实现,那么他只是一个好的程序员,却不能成为一个优秀的架构师。利用代码实现程序只是手段,不是我们做产品的目标。我们的目标是软件对用户有帮助,可以解决用户的痛点。所以一个架构师要有产品思维,从产品的角度去思考程序设计,理解产品需求。一体验业务架构师也要像产品经理一样,多体验自己的产品,关注运营数据,查看用户的反馈,收集社区中用户反馈的痛点。.原创 2022-01-29 11:42:17 · 1166 阅读 · 0 评论 -
架构的自动化思维
一拒绝重复对于软件工程师来说,要摆脱纯手动的操作,不做重复劳动。重复劳动对工程师技术成长的帮助有限,而且人为操作容易出错,交给程序实现比较可控。对于重复操作,我们可以设置一些阀值,当重复操作超过阀值时,我们就要思考,是否有办法进行自动化。1时间成本计算时间成本不能只看累计时长,还需要看权重,以及工作时被打断需要多长时间恢复之前的工作状态。有三种评估时间成本的方式。a累计这种时间成本的计算方法就是单纯的求和运算,计算在已件事情上消耗的时间总和是多少。例如,每次提取数据都是...原创 2022-01-29 10:25:43 · 853 阅读 · 0 评论 -
聚沙成塔的架构思想
一点睛作为架构师,要具备这种思考方式——设计的架构尽量简洁,功能单一,降低复杂程度,尽力复用;在系统之间做到低耦合,把复杂的部分封装到系统内部;把整体使用最多的部分抽象独立,通过组合多个小而简洁的模块,汇聚成一幅完整的架构图。二小而简洁好的架构都是简单的、易于理解的。我们在设计系统的时候,也要追求简洁,控制好系统规模。不要将系统设计得过大,导致系统复杂,不易维护和修改。一般互联网系统的功能都很繁杂。在设计系统的时候,要把一个大系统分解成互相正交的一些小系统。通过网络通信,指定协议来实现不..原创 2022-01-27 21:15:30 · 516 阅读 · 0 评论 -
及时偿还技术债务
一点睛互联网业务变化很快,一方面是随着产品特性不断增多,多团队同时开发导致代码量逐渐增大,系统架构也越来越复杂。时间长了,会导致代码风格不统一,代码中引入了一些不合理的地方。另一方面,系统架构经过长期的发展,系统间调用的约束可能被打破,随着系统越来越复杂,很少有人能够了解整个系统的调用顺序。这时需要定期梳理,及时调整重复的架构模块和不合理的调用关系。随着产品运营的变化,有些产品的方向也要进行修改和调整,导致从前正确的代码和架构变成了技术债务,需要进行清理或重新整理。对于架构师的要求是:及时发现.原创 2022-01-23 18:41:51 · 351 阅读 · 0 评论 -
完成比完美重要
一最小可用,快速迭代最简可行产品是指可以先发布一个最简单的可行的产品版本,验证设计人员和产品人员的想法。在开发一个新系统的时候,如果上市时间比较紧,那么一般会做一个最小可用集合的产品,优先实现产品的核心功能,保证用户的基本体验,然后逐步迭代开发新版本,补全缺失的其他地方。在这环节中,保证每个版本都形成闭环,然后一层一层添加功能,快速迭代。好的架构是演化出来的,不是一次性设计出来的。在设计时,不是不顾以后,只看当下,而是想到系统以后要扩展,要先想到理想的系统是什么样子,为以后升级系统提前预埋好升.原创 2022-01-22 15:35:21 · 380 阅读 · 0 评论 -
先抗住再优化
一点睛完成比完美重要。先抗住再优化是互联网行业的一条普遍真理。互联网产品的开发项目,没有一个项目的开发时间是充裕的,每个项目的开发时间都非常紧张。互联网产品越早上市、越早接触用户,就意味着在起步阶段比竞争对手的速度更快。通过运营来获取用户反馈,分析相关数据,才能知道什么样的产品适合用户,继而打磨出用户喜欢的产品。时间资源是固定的,在开发时间和产品上线时间的取舍中,大多数情况都是尽量减少开发时间对产品上线的影响,让产品尽早有可用版本供用户使用。简而言之,就是先抗住再优化。抗住的前提是指先正常.原创 2022-01-22 14:30:19 · 697 阅读 · 0 评论 -
如何应对事故
一点睛互联网业务的线上事故很难避免,有时会因为研发的代码出现bug导致,有时会因为外部环境发生变化而引起事故。我们能做的是尽量减少人为事故,防止出现低级事故,降低外部不可抗事故的影响。二处理事故1上报信息出现事故第一时间向上级上报信息。自己弄好,谁也不说行吗?肯定不行,纸保不住火。将事故信息上报给上级只有好处,没有坏处。规范的事故处理流程是在众多“流血”的事故中总结出来的宝贵经验。隐瞒不上报肯定是不行的。2快速恢复事故发生后,第一时间想的应该是如何快速恢复系统,而...原创 2022-01-22 10:30:29 · 247 阅读 · 0 评论 -
稳定为王的保障方法
架构师都希望自己的系统是稳定的,那么如何保障系统的稳定性呢?一合理拒绝当架构师收到一个需求的时候,不应该马上去想如何实现,而是先对需求进行评审。了解需求的真正目的,并且评审是否是合理需求——对产品是否有帮助,对系统的稳定性是否有影响,如果都是否定的,则要合理拒绝。二理清主次关系在设计系统的时候,要理清主次关系。首先把系统主要逻辑画出来,然后添加依赖模块,针对主次关系设置不同的优先级,以及提供不同的解决方案。我们需要从以下方面去思考。1了解系统的全貌知道哪些功能是调用外部...原创 2022-01-22 09:31:24 · 262 阅读 · 0 评论 -
稳定为王的控制因素
稳定是基础,作为架构师要一直牢记在心。在研发过程中,我们要培养稳定为王的架构意识。稳定的控制因素有下面几个。一 安全用户的操作可能会触及系统的安全漏洞,对系统服务造成影响。黑客的攻击也会对信息安全和系统安全进行冲击,对产品的稳定性和用户口碑造成影响,导致软件系统不被用户信任,甚至用户会产生恐慌。网站的安全性对网站的影响是致命的,也是运营稳定的前提之一。安全性问题主要有两大类。1 系统安全系统安全性指的是业务依赖的系统底层服务、基础服务所引起的通用安全问题。虽然它们不是开发人员代码原创 2022-01-21 19:00:24 · 3116 阅读 · 0 评论 -
BASE 理论
一点睛BASE 理论是由 eBay 架构师提出的,它是对大规模分布式系统实践的总结,BASE理论是对CAP理论的延伸,其核心思想是即使无法做到强一致性(CAP的一致性是强一致性),但应用可以采用适当的方式来使系统达到最终一致性。BASE 理论是基本可用(Basically Available)、软状态(Soft State)和最终一致性(Eventually Consistent)。二 基本可用什么是基本可用呢?假设系统出现了不可预知的故障,但还是能用,相比较正常的系统而言,可以提...原创 2022-01-18 20:49:40 · 815 阅读 · 0 评论 -
CAP定理
一点睛分布式系统(distributed system)正变得越来越重要,大型网站几乎都是分布式的。分布式系统的最大难点,就是各个节点的状态如何保持一致。CAP 理论是在设计分布式系统的过程中,处理数据一致性问题时必须考虑的理论。二 什么是 CAP 理论Consistency:一致性,等同于所有节点访问同一份最新的数据副本。Availability:可用性,每次请求都能获取非错的响应,但不能保证获取的数据都是最新的。Partition tolerance:分区容错性,分区相对于通信.原创 2022-01-18 20:01:23 · 2422 阅读 · 0 评论 -
Web 类业务负载均衡实战
一点睛在实际生产环境,负载均衡是多种方式的结合。二实战架构图三架构说明1 最外层使用DNS服务2在DNS中配置LVS的虚拟IP地址供用户访问。3虚拟IP地址挂载到实际的服务器,通过Nginx做反向代理,按照地域来接入内网。4在Web侧是的逻辑层调用底层的鉴权等服务,使用服务发现组件5在Web侧调用Mysql服务,使用内网虚拟IP地址实现更换存储不影响业务的目的。6由于Web侧的缓存服务器实现后可以快速重建,所...原创 2022-01-17 18:24:06 · 909 阅读 · 0 评论 -
LVS 的 Tunneling 模式
一架构图二流程说明前提:在Realserver上绑定虚拟IP地址,负载均衡器和Realserver包通过Tunnel模式通信。1用户通过外网访问LVS的负载均衡服务器,把请求发送到对外的虚拟IP地址和端口上。2负载均衡服务器收到请求后,检测请求的IP地址和端口是否匹配LVS的规则表。如果匹配商,则按照负载均衡算法选择一台后端的Realserver。3负载均衡器把用户发送的包封装到一个新的IP地址包中,新的IP地址包的目标地址是...原创 2022-01-17 18:22:57 · 816 阅读 · 0 评论 -
LVS 的 DR 模式
一架构图二流程说明前提:每个 Real server要把lookback(回环IP地址)都设定为负载均衡器的IP地址,而且要抑制 arp。1用户通过外网访问LVS的负载均衡服务器,把请求发送到对外的虚拟IP地址和端口上。2负载均衡服务器收到请求后,检测请求的IP地址和端口是否匹配LVS的规则表。如果匹配商,则按照负载均衡算法选择一台后端的Realserver。3将这台选中的Realserver的 MAC地址重新封装到IP地址包中并...原创 2022-01-16 20:11:30 · 250 阅读 · 0 评论 -
LVS 的 NAT 模式
一架构图二流程说明1用户通过外网访问LVS的负载均衡服务器,把请求发送到对外的 vip地址和端口上。2负载均衡服务器收到请求后,检测请求的IP地址和端口是否匹配LVS的规则表。如果匹配上,则按照负载均衡算法选择一台后端的Realserver。3将请求包中目的IP地址和端口信息用 Real server的IP地址和端口信息重写。4把重写后的请求包发送给后端的Realserver。5Realserver处理结束后,把回包发送给负载均衡...原创 2022-01-16 19:50:29 · 234 阅读 · 0 评论 -
负载均衡常用组件介绍
一 DNSDNS 是一种实现负载均衡的方式,为了扩展后端的服务能力,我们会在一个域名下配置多个IP地址。在DNS上可以配置访问策略,按照运营商、地域进行优先选择,然后按照随机的方式分配被访问的节点。DNS一般用在 Web类业务中,用户在请求域名的时候,会先访问DNS服务器,从DNS服务器中解析到真正的IP地址,然后通过IP地址访问服务器。如果服务端要做扩容或缩容,则可以通过修改DNS配置文件控制服务器数量、地域接入分布及权重等。优点配置简单,不用单独开发...原创 2022-01-16 18:50:36 · 2075 阅读 · 0 评论 -
一致性 Hash
一算法描述当 Hash表更新节点的数量时,只有k/n的关键字位置有变化,其他关键字的位置的映射关系不变。与一致性Hash算法相比,其他算法的节点个数n变化后,更多的Key关键字和节点的映射会发生变化。实现一致性Hash算法的前提是: 每个请求的Key的范围是 0到 2的32次方,一共有k个Key。 一共有n个节点,每个节点对应一个服务器。 二常规实现把Key的取值范围内的数字(一共2的32方个数字)组成一个环节,然后随机在这个环上...原创 2022-01-15 16:01:48 · 174 阅读 · 0 评论 -
负载均衡之最小连接数和映射分配算法
一最小连接数最小连接数算法会根据后端服务器当前连接情况来选择连接数最小的服务器进行连接。从服务方的角度来说,每次都会选择有足够资源的服务器进行连接。和轮询类似,除了最小连接数,也有加权最小连接数,保证能力强的服务器能够连接更多的客户端。按照最小连接数实现负载均衡,后端分配的请求情况如下图所示。二映射分配无状态的服务可采用轮询或随机算法。但有些服务是有状态的,例如,一些存储信息或具有缓存的服务。具有固定Key的请求要落在固定的节点上,这时就要通过静态分配来均衡分配请求。1...原创 2022-01-15 15:14:39 · 2001 阅读 · 0 评论 -
负载均衡之源地址Hash
一 算法源地址 Hash 是根据客户端的 IP 地址,通过 Hash 函数的运算把 IP 地址转换为一个固定的数字。根据“Hash”后的数字,对服务器列表进行取模运算,得到服务器的序号。这种算法的好处是,同一个 IP 地址所选择的服务器总是相同的。相同服务器本地缓存数据,对于有状态的服务来说,每次访问都会命中缓存。除了源地址 Hash 外,还有目标地址 Hash,它和源地址 Hash 的原理类似。下图是按源地址进行 Hash 运算后,后端分配的请求情况。二 实现package原创 2022-01-15 14:35:16 · 1899 阅读 · 0 评论 -
负载均衡之随机访问
一 算法随机访问能保证在请求数量较大的情况下,每个节点被选择的总次数是均匀的。随机访问也可以使用权重。具体做法是先计算全部权重的总和,每次随机一个小于等于总和的数字。每次“随机”后,寻找“随机”的值落在哪个节点的权重之中。从宏观上看,随机访问是分布均匀的,和轮询的效果是一样的。随机访问的优点是每次选择都是无状态的,不用记录上次选择到哪个节点。如果选取的随机算法不够随机,则会导致后端请求不均匀。下图是按随机分配时,后端分配请求的情况。二 加权随机算法实现1 需求有两台服务器,第原创 2022-01-15 14:15:28 · 357 阅读 · 0 评论 -
负载均衡之加权轮询
一 算法加权轮询是对基本轮询算法的一个补充。加权轮询是指给后端的每个节点都赋予权重,分配请求时,不只按照节点数量轮询,而是按照节点的权重来决定轮询的个数。按照权重的总和来轮询,再根据没个权重所属的服务节点来决定将请求分配给哪个节点。权重高的节点占用的轮询份数较多,被请求的次数增加,权重小的节点占用的轮询份数较少,被请求的次数减少。二 实现package loadbalance;/*** @className: WeightRobinSelect* @description: 加原创 2022-01-15 10:56:15 · 2473 阅读 · 0 评论 -
负载均衡之基本轮询
一算法轮询就是后端有多少个服务节点要分配,根据顺序进行轮询分配,分配完后最后一个节点后,再轮流回到第一个节点进行分配。轮询有一个缺点,后端不同节点的处理能力可能不同,简单的轮询会导致真正处理能力强的节点并没有完全发挥处理能力。不同客户端对于服务器的访问请求以轮询的方式依次分配给后端服务器。二实现package loadbalance;/*** @className: RobinSelect* @description: 基本轮询* @date: 2022/1/15...原创 2022-01-15 10:34:11 · 722 阅读 · 0 评论 -
令牌桶算法
一算法令牌桶算法和漏桶算法不同的是,有时后端能够处理一定的突发情况,只是为了系统稳定,一般不会让请求超过正常情况的60%,给容灾留有余地。但漏桶算法中后端处理速度是固定的,对于短时的突发情况,后端不能及时处理,和实际处理能力不匹配。令牌算法是以固定速度往一个桶内增加令牌,当桶内令牌满了后,就停止增加令牌。上游请求时,先从桶里拿一个令牌,后端只服务有令牌的请求,所以后端处理速度不一定是匀速的。当有突发请求过来时,如果令牌桶是满的,则会瞬间消耗桶中存量的令牌。如果令牌还不够,那么再等待发放令牌(固定速.原创 2022-01-09 19:29:35 · 9173 阅读 · 2 评论 -
限流之漏桶算法
一算法描述漏桶算法比较形象,设想有一个桶,桶的底部有一个洞,当装上水的时候,水会一滴一滴地从底部漏掉。当装的水太满,水会溢出,但底部漏水的速度还是不变的。底部漏水的速度就是系统处理的速度,桶里存储的水就是上游过来的请求。当请求太多,超过桶的容量,就会被拒绝。系统只在另一端按照固有的速度处理请求。如下图所示,外部的请求随机而来,把“桶”填满后,装不进“桶”的请求被丢弃。每秒从“桶”中匀速“漏出”一定量的“水”(请求),服务进程处理漏出的请求包。当请求突增的时候,漏桶算法能够保证处理速度总.原创 2022-01-09 17:28:44 · 1816 阅读 · 0 评论 -
限流之滑动窗口算法实战
一算法滑动窗口算法弥补了计数器算法的不足。滑动窗口算法把间隔时间划分成更小的粒度,当更小粒度的时间间隔过去后,把过去的间隔请求数减掉,再补充一个空的时间间隔。如下图所示,把1分钟划分为10个更小的时间间隔,每6s为一个间隔。1一个时间窗口为1分钟,滑动窗口分成10个格子,每个格子6秒。2 每过6秒,滑动窗口向右移动1个格子。3每个格子都有独立的计数器。4如果时间窗口内所有的计数器之和超过了限流阀值,则触发限流操作。如下图所示,滑动窗口算法比计数器算法控制得更精细。...原创 2022-01-09 13:02:05 · 10454 阅读 · 2 评论 -
限流之计数器算法
一点睛发生过载的原因主要是缓冲区满,导致处理的请求超时。所以限制流量,尽早拒绝过载状态的请求,能够保证服务尽量处理负载过程中的请求。限流的主要方法有下面四种: 计数器算法 滑动窗口算法 漏桶算法 令牌桶算法 本篇介绍计数器算法。二算法计数器算法是在一定的时间间隔里,记录请求次数,当请求次数超过该时间限制时,就把计数器清零,然后重新计算。当请求次数超过间隔内的最大次数时,拒绝访问。例如:一个接口每分钟允许访问100次。实现方式如下:1设置一...原创 2022-01-08 20:43:29 · 2300 阅读 · 0 评论 -
过载处理之隔离
一点睛隔离的本质是“不把鸡蛋都放在一个篮子里”。即使有些服务出现了过载的现象,也不至于所有的服务都受到影响,让全部服务不可用。隔离的方法有轻重分离、运营商分离、业务分区分离几种。二轻重分离指分清业务的主干逻辑和分支逻辑,将业务分开部署,不至于分支逻辑过载时,占用主干逻辑的资源,导致所有模块受到影响。一般在Web类应用中,图片和CSS等静态资源会有专门的下载服务器,甚至是专门的域名、这么做就是为了保证主要处理业务的逻辑,不会和下载资源的逻辑模块互相争夺资源,也保证在带宽紧张的情况下...原创 2022-01-08 19:16:59 · 2174 阅读 · 0 评论 -
过载现象和原因
一点睛过载保护是在系统过载的时候,对已有的系统进行保护——保证系统尽力提供服务,保证系统承载的正常请求时正常的,丢弃非正常请求,让服务始终对外维持在最大服务能力的范围内。二什么是过载1正常情况系统正常时,一个包从客户端发出,到返回给客户端的全部顺风顺水。2过载情况系统单位时间内只能处理n个包,但客户给单位时候内给系统发送的包大于n,久而久之,各级缓存会出现丢包现象,出现客户端请求超时现象,如果该服务还存在上下游服务,过载会导致更严重的级联失败的现象——雪崩。在分布式...原创 2022-01-05 18:50:50 · 4299 阅读 · 0 评论