![](https://img-blog.csdnimg.cn/2021041611273712.png?x-oss-process=image/resize,m_fixed,h_224,w_224)
分布式
文章平均质量分 79
分布式
程铭程铭你快成名
这个作者很懒,什么都没留下…
展开
-
聊聊分布式锁的设计模型
什么是分布式锁?原创 2022-10-10 11:42:30 · 947 阅读 · 0 评论 -
从0到1搭建简单的灰度发布系统
什么是灰度发布系统灰度发布(又名金丝雀发布)是指在黑与白之间,能够平滑过渡的一种发布方式。在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。灰度期:灰度发布开始到结束期间的这一段时间,称为灰度期。(来源于百度百科)灰度发布的好处提前获得目标用户的使用反馈根据反馈结果,做到查漏补缺优化产品体原创 2021-11-19 18:10:13 · 3243 阅读 · 0 评论 -
对于分布式消息队列我有话说
消息中间件作为互联网常用的技术手段,能够进行服务解耦、削峰填谷、异步操作,虽然这些的确可以给我们的系统带来好处,但是如果使用不当也会带来不少的坑,本文以rabbitMQ为例来分享在使用在使用消息队列中遇到的一些坑以及解决方案。所以为分布式消息队列就是将消息分摊到各个节点上,所有节点上的消息汇总就是消息的总和。在了解今天正文内容之前,我们先大概了解一下消息队列的模型。从上面这张图可以看到,消息队列总共由发送者+队列+消费者组成。生产者在投放过程中消息丢失所谓生产者消息丢失指的是消息在生产者投放到队原创 2021-11-03 19:31:11 · 2483 阅读 · 0 评论 -
B站崩了、Facebook崩了,我们到底该怎么保证高可用
相信前一段时间的新闻大家都知道了,B站崩了三个半小时,Facebook全球崩了7个小时,那么作为工程师的我们到底应该怎么保证我们系统的稳定性和高可用呢?在了解以下思路和方案之前,我们先抛个砖,我们可以在两个层面保证高可用开发设计层面冗余:主备,负载均衡,failover取舍:降级,限流,熔断,超时控制运维层面灰度发、A/B Test故障演练监控报警异地多活背景以B站为例,我们来回顾一下B站宕机到恢复的时间线。2021年7月13日 晚上11点,B站主页崩溃App端原创 2021-10-27 15:39:28 · 2167 阅读 · 0 评论 -
那些年我们用过的分布式锁,你都get到了吗
分布式锁的特性互斥性:和我们本地锁一样互斥性是最基本,但是分布式锁需要保证在不同节点的不同线程的互斥。可重入性:同一个节点上的同一个线程如果获取了锁之后那么也可以再次获取这个锁。锁超时:和本地锁一样支持锁超时,防止死锁。常见的分布式锁MySQLzookeeperRedis基于MySQL实现分布式锁基于zookeeper实现分布式锁基于Redis实现分布式锁...原创 2021-05-19 15:55:26 · 3747 阅读 · 0 评论 -
干货!手把手教你搭建高可用架构
1. 系统集群式部署单点系统,一旦出故障整个系统都瘫痪,非常酸爽,所以在大型系统中都采用集群部署,某台实例出现了问题直接踢掉负载就好了,不必担心系统是单点这种尴尬场景。尤其是在电商系统中大促的场景下,都会有一些备份机器,担心机器不够用那么直接扩容吧。2. 减少系统间依赖在系统里尽量的避免外部依赖、第三方依赖等,毕竟命运掌握在自己手里才是最有把握的。试想一种场景,如果因为你依赖的外部服务挂了导致自己的服务大面积出错,那真正尴尬的才是你自己啊。3. 重试策略大型系统中通过网络进行rpc、http调用难原创 2021-04-22 22:06:27 · 1913 阅读 · 2 评论 -
我所了解的分布式事物
前言因为公司的项目用到了分布式事物,一开始对这个概念了解的只是模棱两可,所以自己学习了一波并整理了此篇博客。众所周知,分布式事务是企业集成中的一个技术难点,也是每一个分布式系统架构中都会涉及到的一个东西,尤其是在微服务中分布式事物是必须要解决的一个课题。All or Nothing在了解分布式事物之前,有必要复习一下数据库本地事物。事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分...原创 2019-06-04 16:58:43 · 6135 阅读 · 0 评论 -
关于TCC你可能不了解的细节
说到TCC大家可能并不陌生,但是也有一些小伙伴只是听到过,简单的了解过一些概念并没有实践过,所以对于有些细节还是不够了解。TCC作为分布式事务的一种具有强实时性保证的解决方案,其主要思想在于资源预留。在一切顺利的情况下,一阶段TRY还是很容易理解的。只不过为了保证在各种异常场景下,TCC都能够正常的工作,会添加不少异常处理手段。为了把两个阶段的行为梳理清楚,绘制了下面的流程图作为总结。一阶段TRY二阶段 CONFIRM/CANCEL分布式事务需要解决的问题幂等问题:TC重复调用二阶段解决:原创 2021-02-18 16:43:41 · 4267 阅读 · 0 评论 -
不能不知道的分布式基础理论
大型网站为什么要使用分布式服务单点服务虽然开发方便,但是随着业务的扩充很容易遇到瓶颈,降低系统的可用性。单点服务没有服务拆分的概念,排查问题不是很方便,遇到问题需要从头开始,增加了排查问题的成本。分布式系统会按照模块划分,解耦服务之间的依赖性,排查问题方便,降低排查问题的成本,从而提高了系统的可用性。单点服务的交付周期较长,一旦出现问题就会延长交付时间。分布式系统可以按照模块进行交付。按照模块划分之后,可以加快开发速度,每个业务模块的开发人员只需要专注所负责模块。但是分布式体统的设计也带来了一定的原创 2021-03-24 14:55:19 · 2603 阅读 · 0 评论 -
一致性协议之2PC和3PC
在分布式系统中每一个机器节点都可以知道自己在进行事务操作过程中的结果是成功还是失败,但是也无法得知其他节点的操作结果。因此当一个事务需要跨越多个节点的时候,为了保证事务的ACID的特性,这个时候就需要引入一个"协调者"的组件来统一调度所有节点的逻辑,这些被调度的节点被称为"参与者"。协调者负责调度参与者的执行逻辑,并最终决定这些参与者是否要把事务真正的提交。2PC2PC,是Two-Phase-Commit的缩写,即二阶段提交,是计算机网络尤其是在数据库领域内,为了基于分布式系统架构下的所有节点在进行事务原创 2021-04-14 11:39:27 · 1658 阅读 · 0 评论 -
一次性吃透分布式一致性Raft协议
简介Raft是一种为了管理复制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能,但是它的算法结构和 Paxos 不同,使得 Raft 算法更加容易理解并且更容易构建实际的系统。为了提升可理解性,Raft 将一致性算法分解成了几个关键模块:领导人选举、日志复制和安全性。同时它通过实施一个更强的一致性来减少需要考虑的状态的数量。参考文章http://thesecretlivesofdata.com/raft/https://raft.github.io/raft.pdf...原创 2021-03-29 19:07:20 · 6169 阅读 · 0 评论