电商网站建设布局,策划案模板范文,做设备开通哪个网站好,优秀网页设计案例欣赏1、关于分布式锁的了解#xff1f;
原理#xff1a;控制分布式系统有序的去对共享资源进行操作#xff0c;通过互斥来保持一致性。
具备的条件#xff1a; ①分布式环境下#xff0c;一个方法在同一时间只能被一个机器的一个线程执行 ②高可用的获取锁和释放锁 ③高性能…1、关于分布式锁的了解
原理控制分布式系统有序的去对共享资源进行操作通过互斥来保持一致性。
具备的条件 ①分布式环境下一个方法在同一时间只能被一个机器的一个线程执行 ②高可用的获取锁和释放锁 ③高性能的获取锁和释放锁 ④具备可重入特性 ⑤具备锁失效机制防止死锁 分布式锁的三种实现 A. 基于数据库实现分布式锁 B. 基于缓存Redis等实现分布式锁 C. 基于Zookeeper实现分布式锁 A.基于数据库的实现 在数据库中创建一个表表中包含方法名等字段并在方法名字段上创建唯一索引想要执行某个方法就是用这个方法名向表中插入数据成功插入则获取锁执行完成后删除对应的行数据释放锁 B.基于缓存Redis等实现分布式锁
推荐 Redis有很高的性能 Redis命令对此支持较好实现起来比较方便
实现 1获取锁的时候使用setnx加锁并使用expire 命令为锁添加一个超时时间超过该时间则自动释放锁锁的value值为一个随机生成的UUID,通过此在释放锁的时候进行判断。 2获取锁的时候设置一个获取的超时时间若超过这个时间就放弃获取锁。 3释放锁的时候通过UUID判断是不是该锁若是该锁就执行delete进行锁释放。 C.基于Zookeeper的实现方式
原因 Zookeeper是一个为分布式应用提供一致性服务的开源组件它内部是一个分层的文件系统目录树结构规定同一个目录下只能有一个唯一文件名。
实现 创建一个目录mylock线程A想获取锁就在mylock目录下创建临时顺序节点获取mylock目录下所有的子节点然后获取比自己小的兄弟节点如果不存在则说明当前线程顺序号最小获得锁线程B获取所有节点判断自己是不是最小的节点设置监听比自己次小的节点线程A处理完删除自己的节点线程B监听到便跟事件判断自己是不是最小的节点如果是则获得锁。使用Apache的开源库Curator它是一个Zookeeper客户端Curator提供的InterProcessMutex是分布式锁的实现acquire方法用于获取锁release方法用于释放锁。2、 分布式事务处理机制 在CAP定理中一致性、可用性、分区容错性是不可能同时存在的。但在实际的应用场景中数据的一致性是需要保证的。 事务是达到以上目的的最好方法
即保证执行结果的正确性保证数据的一致性ACID
常见的事务处理机制 Master-Slave 复制 Slave一般是Master的备份。读写都在Master上异步同步数据到SlaveMaster挂了Slave只能读。 Master-Master多主复制 2个以上Master都提供读写服务。一台挂了另一台正常读写。 两阶段提交 第一阶段准备阶段 协调者节点向所有参与者节点询问是否可以执行提交操作并开始等待各参与者节点的响应。参与者节点执行询问发起为止的所有事务操作并将Undo信息和Redo信息写入日志。各参与者节点响应协调者节点发起的询问。 第二阶段提交阶段 如果协调者收到了参与者的失败消息或者超市直接给每个参与者发送回滚Rollback消息否则发送提交Commit)消息参与者根据协调者的指令执行提交或者回滚操作释放所有事务处理过程中使用的锁资源。 三阶段提交 CanCommit阶段协调者向参与者发送commit请求参与者如果可以提交就返回Yes响应否则返回No响应。 PreCommit阶段协调者根据参与者的反应情况来决定是否可以记忆事务的PreCommit操作。 doCommit阶段进行真正的事务提交。具体为执行提交、终端事务。 3、用分布式和没有用分布式的项目的差异是什么?
传统项目:存在问题: 1:模块之间耦合度太高,其中一个功能升级,其他的模块都得一起升级部署。 2:开发困难,各个团队开发最后都要整合在一起. 3:系统扩展性差 4:不能灵活进行分布式部署 解决方案 把模块才分成独立的工程,单节点运行,如果某一个节点压力大了可以单独对这个节点进行增加配置,其他节点不受影响。缺点就是系统之间交互需要额外的工作量来进行接口的开发。把系统拆分成多个工程,需要完成系统的工程需要多个工程协作完成,这种形式就叫做分布式。 分布式:把系统拆分成多个子系统.
优点: 1:把模块拆分,使用接口通信,降低模块之间的耦合度. 2:把项目拆分成若干个子项目,不同的团队负责不同的子项目. 3:增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。 4:可以灵活的进行分布式部署. 5:提高代码的复用性,比如service层,如果不采用分布式rest服务方式架构就会在手机wap商城,微信商城,pc,androidios每个端都要写一个service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式,公用一个service层。 1、锁:
单进程的系统中存在多线程同时操作一个公共变量此时需要加锁对变量进行同步操作保证多线程的操作线性执行消除并发修改。解决的是单进程中的多线程并发问题。
2、分布式锁:
只要的应用场景是在集群模式的多个相同服务可能会部署在不同机器上解决进程间安全问题防止多进程同时操作一个变量或者数据库。解决的是多进程的并发问题。 3、事务
解决一个会话过程中上下文的修改对所有数据库表的操作要么全部成功要不全部失败。所以应用在service层。解决的是一个会话中的操作的数据一致性。 4、分布式事务
解决一个联动操作比如一个商品的买卖分为:
1添加商品到购物车
2修改商品库存-1
此时购物车服务和商品库存服务可能部署在两台电脑这时候需要保证对两个服务的操作都全部成功或者全部回退。解决的是组合服务的数据操作的一致性问题。 分布式锁是解决并发时资源争抢的问题分布式事务和本地事务是解决流程化提交问题。 一、其中分布式锁实现 1.基于数据库锁实现,悲观锁和乐观锁 悲观锁就是采用行锁for update ,属于排他锁其他任何写操作都要等当前操作完成性能差并发上来都要等操作完成需要设置setAutoCommit 乐观锁就是通过添加版本号在update 时比较版本号方式更新 比如version不被阻塞 2.基于redis实现 setnx(key,expire),get(key),getset(key,newexpire)实现完整的分布式锁并且可以通过注解来加锁 3.基于zookeeper 实际是基于paoxy 二、分布式事务实现 原则优先使用本地事务将操作优先在一个本地事务中完成无法使用本地事务的采用分布式事务 1.全局事务DTP模型基于2PC、3PC两段和三段提交实现但由于同步阻塞处理效率低不适合大型网站分布式场景 原则ACID刚性事务 2pc一阶段预提交二阶段提交都成功情况才会成功 2.柔性事务 原则基本可用最终一致即BASE理论 关于柔性事务最主要的有以下三种类型异步确保型、补偿型、最大努力通知型 幂等性参数列表对比是否重复请求 可补偿保证原子性 TCC操作TCC位于业务服务层而非资源层 TCC没有单独的准备(Prepare)阶段,Try操作兼备资源操作与准备能力 Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度) TCC有较高开发成本
