网站不备案可以使用么,大学生网站开发工作室总结,个人微信crm系统,设计本官方网站 网络服务目录 分布式系统面试全集通第一篇什么是分布式?和微服务的区别什么是分布式分布式与微服务的区别 什么是CAP?为什么不能三者同时拥有分区容错性一致性可用性 Base理论了解吗基本可用软状态最终一致性 什么是分布式事务分布式事务有哪些常见的实现方案?2PC#xff08;Two Ph… 目录 分布式系统面试全集通第一篇什么是分布式?和微服务的区别什么是分布式分布式与微服务的区别 什么是CAP?为什么不能三者同时拥有分区容错性一致性可用性 Base理论了解吗基本可用软状态最终一致性 什么是分布式事务分布式事务有哪些常见的实现方案?2PCTwo Phase Commit3PCThree Phase CommitTCCTry Commit Cancel2PC、3PC、TCC区别2PC存在问题TCC存在问题TCC的优点对比2PC3PC有什么优点 有哪些分布式锁的实现方案?一、 分布式锁场景二、分布式锁特点基于缓存实现分布式锁以Redis为例 感谢阅读 分布式系统面试全集通第一篇
什么是分布式?和微服务的区别
什么是分布式
一个系统各组件分别部署在不同服务器。彼此通过网络通信和协调的系统。也可以指多个不同组件分布在网络上互相协作比如说电商网站也可以一个组件的多个副本组成集群互相协作如同一个组件比如数据存储服务中为了数据不丢失而采取的多个服务备份冗余当数据修改时也需要通信来复制数据分布式最早出现的目地首先是解决单点问题避免单点故障然后解决了性能问题
分布式与微服务的区别
分布式和微服的架构很相似只是部署的方式不一样而已。
分布式服务架构与微服务架构概念的区别与联系 分布式分散压力。 不同模块部署在不同服务器上; 作用分布式解决网站高并发带来问题 集群相同的服务 多台服务器部署相同应用构成一个集群 作用通过负载均衡设备共同对外提供服务 业务系统分解为多个组件让每个组件都独立提供离散自治可复用的服务能力; 通过服务的组合和编排来实现上层的业务流程; 作用简化维护降低整体风险伸缩灵活;微服务分散能力。 微服务找到服务/微服务网关open API; 架构设计概念各服务间隔离分布式也是隔离自治分布式依赖整体组合其它特性单一职责边界异步通信独立部署 是分布式概念更加严格的执行; SOA到微服务架构的演进过程; 作用各服务可独立应用组合服务也可系统应用巨石应用monolith的简化实现策略-平台思想. 明确一个问题分布式主要针对是部署方式微服务则是将应用才分的一种应用架构
什么是CAP?为什么不能三者同时拥有
在设计一个分布式项目的时候会遇到三个特性:
一致性(consistency)可用性(Availability)分区容错(partition-tolerance)都需要的情景 输入/唤起更 CAP定律说的是在一个分布式计算机系统中一致性可用性和分区容错性这三种保证无法同时得到满足最多满足两个。
分区容错性
分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system即分布式系统在遇到某节点或网络分区故障的时候仍然能够对外提供服务。分布式系统中尽管部分节点出现任何消息丢失或者故障系统应继续运行通常分布式系统的各各结点部署在不同的子网这就是网络分区不可避免的会出现由于网络问题而导致结点之间通信失败此时仍可对外提供服务。
一致性
一致性指all nodes see the same data at the same即更新操作成功并返回客户端time完成后所有节点在同时间的数据完全一致。一旦数据更新完成并成功返回客户端后那么分布式系统中所有节点在同一时间的数据完全一致。一致性是指写操作后的读操作可以读取到最新的数据状态当数据分布在多个节点上从任意结点读取到的数据都是最新的状态。
可用性
可用性指即服务一直可用而且是正常响应时间。“Reads and writes always succeed” 对于可用性的衡量标准如下:
Base理论了解吗
BASE(Basically Available、Soft state、Eventual consistency)是基于CAP理论逐步演化而来的核心思想是即便不能达到强一致性(Strong consistency)也可以根据应用特点采用适当的方式来达到最终致性(Eventual consistency)的效果。
基本可用
基本可用本质是一种妥协也就是出现节点故障或者系统过载时通过牺牲非核心功能的可用性保障核心功能的稳定运行。 实现基本可用的几个策略:
1、流量削峰(不同地区售票时间错峰出售) 以订票系统设计为例在春运期间开始售票前后会出现及其海量的请求峰值。 可以在不同的时间出售不同区域的票将访问请求错开削弱请求峰值。2、延迟响应异步处理(买票排队基于队列先收到用户买票请求排队异步处理延迟响应)还以订票系统为例。用户提交购票请求后往往会在队列中排队等待处理可能几分钟或十几分钟后系统才开始处理然后响应处理结果。3、体验降级(看到非实时数据采用缓存数据提供服务)以互联网系统为例若出现网络热点事件产生了海量的突发流量系统过载大量图片因为网络超时无法显示那么可以用小图片代替原始图片降低图片的清晰度和大小提升系统处理能力。4、过载保护熔断/限流直接拒绝掉一部分请求或者当请求队列满了移除一部分请求保证整体系统可用)把接收到的请求放在指定的队列中排队处理如果请求等待时间超时这时直接拒绝超时请求;如果队列满了之后就清除队列中一定数量的排队请求保护系统不过载实现系统基本可用。5、故障隔离(出现故障做到故障隔离避免影响其他服务)
软状态
软状态(弱状态)-允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延迟。
最终一致性
上面说软状态然后不可能一直是软状态必须有个时间期限。在期限过后应当保证所有副本保持数据一致性。 从而达到数据的最终一致性。这个时间期限取决于网络延时系统负载数据复制方案设计等等因素。
什么是分布式事务
分布式事务是相对本地事务而言的对于本地事务利用数据库本身的事务机制就可以保证事务的ACID 特性。
分布式事务有哪些常见的实现方案?
到现在分布式事务已经有很多的解决方案了有2PC、3PC、TCC这一篇博客我们先来分别讲讲最早的2PC、3PC这两种解决方案的模型及理论基础以后再丰富其他的分布式事务解决方案。
2PCTwo Phase Commit 第一阶段执行事务操作
事务询问。 协调者节点向所有参与者节点询问是否可以执行提交操作并开始等待各参与者节点的响应。执行事务。 参与者节点执行询问发起的所有事务操作并将Undo信息和Redo信息写入数据库日志。若操作成功这里其实每个参与者已经执行了事务操作各参与者向协调者反馈事务询问的响应。 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功则反馈一个“同意”消息如果执行失败则反馈一个“中止”消息。 第二阶段执行事务提交
当所有参与者节点在第一阶段向协调者节点反馈的消息全都是“同意”时
发送事务提交请求 协调者节点向所有参与者节点发出“正式提交(commit)”请求。事务正式提交 参与者节点正式完成提交操作并释放在整个事务期间占用的资源。反馈事务提交结果 参与者节点向协调者节点发送“完成”消息。完成事务 协调者节点收到所有参与者节点反馈的“完成”消息后完成分布式事务。 当任一参与者节点在第一阶段反馈的响应为“中止”或者协调者在第一阶段接收反馈信息超时
发送事务回滚请求 协调者节点向所有参与者节点发出“回滚操作(rollback)”请求。
事务回滚 各参与者节点收到请求利用之前写入的Undo信息执行本地事务回滚操作并释放在整个事务期间占用的资源。反馈事务回滚结果 参与者节点向协调者节点发送“回滚完成”消息。中断事务 协调者节点收到所有参与者节点反馈的“回滚完成”消息后取消事务。
3PCThree Phase Commit
3PC没有解决2PC所有问题只是降低了灾难的发生概率。只是在2PC基础上多一个询问
TCCTry Commit Cancel
这个模型有两个个阶段但是与2PC的三个阶段又有所不同。 第一阶段执行Try操作
事务发起。 协调者节点向所有参与者节点发起执行业务逻辑包含数据操作的命令并开始等待各参与者节点的响应。执行数据操作。 直接对数据库的数据执行操作。各参与者向协调者反馈执行操作的响应。 各参与者节点响应协调者节点发起的数据操作。如果参与者节点的数据操作实际执行成功则反馈一个“同意”消息如果有一个参与者执行失败则反馈一个“中止”消息。 第二阶段执行Confirm/Cancel操作 根据阶段一各事务参与者的响应如果所有事务参与者在阶段一执行成功那就执行Confirm操作有一个事务参与者在阶段一执行失败就执行Cancel操作进行数据库数据恢复。 Confirm 操作用于执行数据操作成功之后的业务逻辑。 Cancel 操作用于恢复阶段一对数据的操作。
2PC、3PC、TCC区别
1.在2PC的第一阶段基础之上3PC新加了一个准备阶段(上图所示)用于询问所有参与者节点是否已经准备好要进行分布式事务操作了这一阶段没有对资源的占用只是测试数据库是否能获取锁即可只是保证所有参与者都有能力参与事务如果有网络或者其他问题就不用进行第二、三阶段了。 2. 在3PC的所有阶段都为所有参与者节点和协调者节点添加了超时机制防止因某一节点宕机造成的资源无法释放问题。 3. 2PC中所有阶段只对协调者节点添加了超时机制。 4. TCC模型主要是在应用层做的一个分布式事务2PC和3PC则是在数据库层做的分布式事务。 5。 TCC模型可以用于不支持事务的数据库但是2PC和3PC要求数据库必须支持事务。
2PC存在问题
2PC只对协调者节点添加了超时机制如果协调者这一重要角色宕机所有参与者的资源就会一直得不到释放降低系统的可用性。 2PC中当其中任一节点宕机情况出现时不能保证数据的最终一致性。
TCC存在问题
代码编写难度高 每个参与者的业务都要写try、confirm、cancel三个操作并且各个操作的业务都有所不同 为满足一致性要满足try、canfirm、cancel三个操作的幂等。 对于幂等性可参考文章【分布式事务讲解 - Seata分布式事务框架AT、TCC两种模式】
TCC的优点
TCC的优点全是因为实现了应用层的分布式事务优点如下
可以降低数据库锁冲突提高吞吐量。 可以通过应用控制数据库锁的粒度而不用像2PC和3PC使数据库阻塞等待。 可以通过部署集群解决单点故障。
对比2PC3PC有什么优点
为所有参与者节点和协调者节点添加了超时机制 1如果协调者等待参与者反馈信息超时直接给所有参与者发送中断分布式事务请求。 2如果在第三阶段任一参与者等待协调者提交事务信息超时那就默认提交事务 添加超时机制可以防止因某一节点宕机造成的资源无法释放问题以及资源占用时间过长问题。 在第一阶段不锁定资源就好像在Synchronized外面加了个if条件能降低分布式事务执行失败率。
有哪些分布式锁的实现方案?
一、 分布式锁场景
般需要使用分布式锁的场景如下: 效率:使用分布式锁可以避免不同节点重复相同的工作比如避免重复执行定时任务等;正确性:使用分布式锁同样可以避免破坏数据正确性如果两个节点在同一条数据上面操作可能会出现并发问题。
二、分布式锁特点
一个完善的分布式锁需要满足以下特点: ·互斥性:互斥是所得基本特性分布式锁需要按需求保证线程或节点级别的互斥。·可重入性:同一个节点或同一个线程获取锁可以再次重入获取这个锁; ·锁超时:支持锁超时释放防止某个节点不可用后持有的锁无法释放; 高效性:加锁和解锁的效率高可以支持高并发 ·高可用:需要有高可用机制预防锁服务不可用的情况如增加降级; 阻塞性:支持阻塞获取锁和非阻塞获取锁两种方式; ·公平性:支持公平锁和非公平锁两种类型的锁公平锁可以保证安装请求锁的顺序获取锁而非公平锁
基于缓存实现分布式锁以Redis为例
加锁
public class RedisTool {private static final String LOCK_SUCCESS OK;private static final String SET_IF_NOT_EXIST NX;private static final String SET_WITH_EXPIRE_TIME PX;/*** 加锁* param stringRedisTemplate Redis客户端* param lockKey 锁的key* param requestId 竞争者id* param expireTime 锁超时时间超时之后锁自动释放* return */public static boolean getDistributedLock(StringRedisTemplate stringRedisTemplate, String lockKey, String requestId, int expireTime) {return stringRedisTemplate.opsForValue().setIfAbsent(lockKey, requestId, 30, TimeUnit.SECONDS);}}
这个setIfAbsent()方法一共五个形参
第一个为key我们使用key来当锁因为key是唯一的。 第二个为value这里写的是锁竞争者的id在解锁时我们需要判断当前解锁的竞争者id是否为锁持有者。 第三个为expx这个参数我们传的是PX意思是我们要给这个key加一个过期时间的设置具体时间由第五个参数决定 第四个参数为time与第四个参数相呼应代表key的过期时间。 总的来说执行上面的setIfAbsent()方法就只会导致两种结果
1.当前没有锁(key不存在)那么就进行加锁操作并对锁设置一个有效期同时value表示加锁的客户端。 2.已经有锁存在不做任何操作。上述解锁请求中缓存超时机制保证了即使一个竞争者加锁之后挂了也不会产生死锁问题超时之后其他竞争者依然可以获取锁。通过设置value为竞争者的id保证了只有锁的持有者才能来解锁否则任何竞争者都能解锁那岂不是乱套了。 解锁
public class RedisTool {private static final Long RELEASE_SUCCESS 1L;/*** 释放分布式锁* param stringRedisTemplate Redis客户端* param lockKey 锁* param requestId 锁持有者id* return 是否释放成功*/public static boolean releaseDistributedLock(StringRedisTemplate stringRedisTemplate, String lockKey, String requestId) {String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end;Long result stringRedisTemplate.execute(new DefaultRedisScriptLong(script, Long.class), Collections.singletonList(lockKey), requestId);return RELEASE_SUCCESS.equals(result);}
}
解锁的步骤
1、判断当前解锁的竞争者id是否为锁的持有者如果不是直接返回失败如果是则进入第2步。
2、删除key如果删除成功返回解锁成功否则解锁失败。
注意到这里解锁其实是分为2个步骤涉及到解锁操作的一个原子性操作问题。这也是为什么我们解锁的时候用Lua脚本来实现因为Lua脚本可以保证操作的原子性。那么这里为什么需要保证这两个步骤的操作是原子操作呢
设想假设当前锁的持有者是竞争者1竞争者1来解锁成功执行第1步判断自己就是锁持有者这是还未执行第2步。这是锁过期了然后竞争者2对这个key进行了加锁。加锁完成后竞争者1又来执行第2步此时错误产生了竞争者1解锁了不属于自己持有的锁。可能会有人问为什么竞争者1执行完第1步之后突然停止了呢这个问题其实很好回答例如竞争者1所在的JVM发生了GC停顿导致竞争者1的线程停顿。这样的情况发生的概率很低但是请记住即使只有万分之一的概率在线上环境中完全可能发生。因此必须保证这两个步骤的操作是原子操作。
分析
是否可重入以上实现的锁是不可重入的如果需要实现可重入在SET_IF_NOT_EXIST之后再判断key对应的value是否为当前竞争者id如果是返回加锁成功否则失败。
锁释放时机加锁时我们设置了key的超时当超时后如果还未解锁则自动删除key达到解锁的目的。如果一个竞争者获取锁之后挂了我们的锁服务最多也就在超时时间的这段时间之内不可用。
Redis单点问题如果需要保证锁服务的高可用可以对Redis做高可用方案Redis集群主从切换。目前都有比较成熟的解决方案。
感谢阅读
感谢您阅读本篇分布式系统面试博客分享如果您有任何问题或建议请随时在评论中告诉我们。谢谢
