微服务和分布式的区别.docx

《微服务和分布式的区别.docx》由会员分享，可在线阅读，更多相关《微服务和分布式的区别.docx（26页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、微服务和分布式的区别分布式架构是分布式计算技术的应用以及工具目前成熟的技术包括J2EE,CORBA以及.NET(DCOM)这些技术牵扯的内容非常广相关的书籍也非常多也没有涉及这些技术的细节只是从各种分布式系统平台产生的背景以及在软件开发中应用的情况来讨论它们的主要异同。微效劳架构是一项在云中部署应用以及效劳的新技术。大局部围绕微效劳的争论都集中在容器或者其他技术是否能很好的施行微效劳而红帽讲API应该是重点。推荐学习Java视频教程微效劳可以在“自己的程序中运行并通过“轻量级设备与HTTP型API进展沟通。关键在于该效劳可以在自己的程序中运行。通过这一点我们就可以将效劳公开与微效劳架构在现有系

2、统中分布一个API区分开来。在效劳公开中许多效劳都可以被内部独立进程所限制。假如其中任何一个效劳需要增加某种功能那么就必须缩小进程范围。在微效劳架构中只需要在特定的某种效劳中增加所需功能而不影响整体进程的架构。从概念理解分布式效劳架构强调的是效劳化和效劳的分散化微效劳那么更强调效劳的专业化以及精细分工从理论的角度来看微效劳架构通常是分布式效劳架构反之那么未必成立。所以选择微效劳通常意味着需要解决分布式架构的各种难题。区别分布式的方式是根据不同机器不同业务。将一个大的系统划分为多个业务模块业务模块分别部署到不同的机器上各个业务模块之间通过接口进展数据交互。区别分布式的方式是根据不同机器不同业务。

3、微效劳更加强调单一职责、轻量级通信(HTTP)、独立性并且进程隔离。微效劳与分布式的细微差异是微效劳的应用不一定是分散在多个效劳器上他可以以是同一个效劳器。分布式是否属于微效劳不一定假如一个很大应用拆分成三个应用但还是很庞大固然分布式了但不是微效劳。微效劳核心要素是微小。微效劳架构是分布式效劳架构的子集。微效劳架构通过更细粒度的效劳切分使得整个系统的迭代速度并行程度更高但是运维的复杂度以及性能会随着效劳的粒度更细而增加。微效劳重在解耦合使每个模块都独立。分布式重在资源分享与加快计算机计算速度。分布式分散压力。微效劳分散才能。课程介绍微效劳架构的技术体系、社区目前已经越来越成熟。在最初系统架构的

4、搭建或当现有架构已到达瓶颈需要进展架构演进时很多架构师、运维工程师会考虑是否需要搭建微效劳架构体系。固然很多文章都讲微效劳架构是复杂的、会带来很多分布式的问题但只要我们解析这些问题并找到解法就会有种拨开云雾的感觉。微效劳架构也不是完美的世上没有完美的架构微效劳架构也是随着业务、团队成长而不断演进的。最开场可能就几个、十几个微效劳每个效劳是分库的通过APIGateway并行进展效劳数据合并、转发。随着业务扩大、不断地参加搜索引擎、缓存技术、分布式消息队列、数据存储层的数据复制、分区、分表等。本课程会一一解开微效劳架构下分布式场景的问题和通过对于一些分布式技术的原理、模型以及算法的介绍来帮助想要施

5、行微效劳架构的工程师们知其然并知其所以然。课程内容微效劳架构的演变微效劳是一种效劳间松耦合的、每个效劳之间高度自治并且使用轻量级协议进展通信的可持续集成部署的分布式架构体系。这一句包含了微效劳的特点微效劳架构以及其他架构有什么区别以下比照一些常见的架构。单体架构单体架构是最简单的软件架构常用于传统的应用软件开发和传统Web应用。传统Web应用一般是将所有功能模块都打包jar、war在一个Web容器JBoss、Tomcate中部署、运行。随着业务复杂度增加、技术团队规模扩大在一个单体应用中维护代码会降低开发效率即使是处理一个小需求也需要将所有机器上的应用全部部署一遍增加了运维的复杂度。SOA架构

6、当某一天使用单体架构发现很难推进需求的开发、和日积月累的技术债时很多企业会开场做单体效劳的拆分拆分的方式一般有程度拆分以及垂直拆分。垂直拆分是把一个应用拆成松耦合的多个独立的应用让应用可以独立部署有独立的团队进展维护程度拆分是把一些通用的会被很多上层效劳调用的模块独立拆分出去形成一个分享的根底效劳这样拆分可以对一些性能瓶颈的应用进展单独的优化以及运维管理也在一定程度上防止了垂直拆分的重复造轮子。SOA也叫面向效劳的架构从单体效劳到SOA的演进需要结合程度拆分及垂直拆分。SOA强调用统一的协议进展效劳间的通信效劳间运行在彼此独立的硬件平台但是需通过统一的协议接口互相协作也即将应用系统效劳化。举个

7、易懂的例子单体效劳假如相当于一个快餐店所有的效劳员职责都是一样的又要负责收银结算又要负责做汉堡又要负责端盘子又要负责清扫效劳员之间不需要有沟通用户来了后效劳员从前到后负责到底。SOA相当于让效劳员有职责分工收银员负责收银厨师负责做汉堡保洁阿姨负责清扫等所有效劳员需要用同一种语言沟通方便工作协调。微效劳以及SOA微效劳也是一种效劳化不过其以及SOA架构的效劳化概念也是有区别的可以从以下几个关键字来理解松耦合每个微效劳内部都可以使用DDD领域驱动设计的思想进展设计领域模型效劳间尽量减少同步的调用多使用消息的方式让效劳间的领域事件来进展解耦。轻量级协议Dubbo是SOA的开源的标准实现之一类似的还有

8、像gRPC、Thrift等。微效劳更倾向于使用Restful风格的API轻量级的协议可以很好得支持跨语言开发的效劳可能有的微效劳用Java语言实现有的用Go语言有的用C但所有的语言都可以支持Http协议通信所有的开发人员都能理解Restful风格API的含义。高度自治以及持续集成从底层的角度来讲SOA更加倾向于基于虚拟机或效劳器的部署每个应用都部署在不同的机器上一般持续集成工具更多是由运维团队写一些Shell脚本和提供基于共同协议比方Dubbo管理页面的开发部署页面。微效劳可以很好得以及容器技术结合容器技术比微效劳出现得晚但是容器技术的出现让微效劳的施行更加简便目前Docker已经成为很多微效

9、劳理论的根底容器。因为容器的特色所以一台机器上可以部署几十个、几百个不同的微效劳。假如某个微效劳流量压力比其他微效劳大可以在不增加机器的情况下在一台机器上多分配一些该微效劳的容器实例。同时因为Docker的容器编排社区日渐成熟类似Mesos、Kubernetes及Docker官方提供的Swarm都可以作为持续集成部署的技术选择。其实从架构的演进的角度来看整体的演进都是朝着越来越轻量级、越来越灵敏的应用方向开展甚至到近两年度日渐成熟起来的Serverless无效劳架构。从单体效劳到分层的效劳再到面向效劳、再到微效劳甚至无效劳对于架构的挑战是越来越大。微效劳架构以及分布式微效劳架构属于分布式系统吗

10、答案是肯定的。微效劳以及SOA都是典型的分布式架构只不过微效劳的部署粒度更细效劳扩展更灵敏。理解微效劳中的分布式如何理解微效劳中的分布式举一个招聘时一个同学来面试的例子。A同学讲目前所在公司在做从单应用到微效劳架构迁移已经差不多完成了。提到微效劳感觉就有话题聊了于是便问“是否可以简单描绘下效劳拆分后的部署构造、底层存储的拆分、迁移方案。于是A同学讲只是做了代码工程构造的拆分还是原来的部署方式数据库还是那个库所有的微效劳都用一个库分布式事务处理方式是“防止尽量都同步调用于是我就跟这位同学友好地微笑讲再见了。微效劳的分布式不仅仅是容器应用层面的分布式其为了高度自治底层的存储体系也应该相互独立并且也

11、不是所有的微效劳都需要持久化的存储效劳。一个“手机验证码微效劳可能底层存储只用一个Redis一个“营销活动搭建页面微效劳可能底层存储只需要一个MongoDB。微效劳中的分布式场景除了效劳本身需要有效劳发现、负载平衡微效劳依赖的底层存储也会有分布式的场景为了高可用性以及性能需要处理数据库的复制、分区并且在存储的分库情况下微效劳需要能保证分布式事务的一致性。课程背景微效劳架构的技术体系、社区目前已经越来越成熟所以在初期选择使用或企业技术体系转型微效劳的时候需要解析微效劳架构中的分布式的问题1.在所有效劳都是更小单元的部署构造时一个恳求需要调动更多的效劳资源如何获得更好的性能2.当业务规模增大需要有

12、地理分布不同的微效劳集群时其底层的数据存储集群是多数据中心还是单数据集群3.数据存储怎样进展数据复制4.业务数据到达大数据量时如何进展数据的分区5.分布式事务如何保证一致性6.不同程度的一致性有什么差异7.基于容器技术的效劳发现怎么处理8.应该用哪些RPC技术用哪些分布式消息队列来完成效劳通信以及解耦9.那么多的分布式技术框架、算法、效劳应该选哪个才合适企业的业务场景本课程从微效劳不得不面对以及解决的分布式问题出发包含分布式技术的一系列理论和架构模型、算法的介绍同时结合技术选型以及理论应用提供一系列解决方案的梳理。相信浏览完好个课程你会对微效劳的分布式问题有个系统地理解。本课程会对微效劳的分布

13、式场景问题一一击破为你提供解决思路。课程内容本课程例如代码地址如下1.Microservice2.API-gateway分布式系统的问题引出分布式系统的可能问题节点故障、网络延迟结合错误检测的可行方案进展介绍分布式中的时间以及顺序的问题和标量时钟以及向量时钟的实现。分布式数据存储分布式数据存储的技术选型、关系型数据库和一些流行的NoSQL技术介绍MongoDB、Redis、Neo4j及Cassandra等分布式存储技术使用的数据构造解析底层数据存储原理HashTable、SSTable、LSMTree、BTree等各个存储方案使用的场景和比照。数据复制对于大规模存储集群需要进展数据库的复制、排

14、除单点故障数据复制的模型以及实现和几种复制日志的实现方式主备同步、主主复制、多数据中心的数据复制方案数据复制中的读写一致性问题和写冲突问题的解决介绍以MySQL为例延伸集群数据复制方案。数据分区当单个领域模型维度的数据已经到一定规模时需要进展数据分区减轻单库压力。数据分区以及分表又有哪些不同数据分区可以怎样实现以MySQL的分区策略为例介绍不同分区策略的实现。数据分区后恳求的路由有哪些解决方案会展开介绍不同的方案又有什么差异。效劳发现以及效劳通信基于容器技术的微效劳体系如何选择效劳发现、负载平衡的技术实现不同的效劳发现的技术有什么区别怎样选型为了到达松耦合的目的和基于DDD思想微效劳之间减少效

15、劳调用可以通过哪些技术实现APIGateway可以用哪些技术框架实现远程调用可以有哪些技术框架如何进步同步通信的性能?分布式的消息队列都有哪些开源、商业实现应该如何选择合适的消息队列使用DDD思想应该怎样应对效劳通信怎样在理论中应用DDD分布式存储集群的事务理解分布式中的事务和本地事务的根底概念分布式存储的隔离级别和各个DB支持的隔离方案的实现原理以MySQLInnoDB中的MVCC为例看并发控制的在MySQL的实现学习存储系统对于分布式事务的实现思想。分布式一致性解析分布式系统的一致性有哪些问题和一致性的几种实现程度的模型线性一致性强一致性、顺序一致性及因果一致性、最终一致性分布式一致性相关

16、的理论CAPCA、CP、AP的相关算法的介绍和合适用于哪些理论介绍FLP不可能结果和BASE理论。分布式事务理论解析微效劳中分布式事务的问题1.介绍强一致性的理论二阶段、三阶段。2PC、3PC的优缺点以及限制XA协议的介绍以及理论方案和最终一致性理论TCC模型以及理论方案2.分布式锁的实现模型以及理论方案3.基于微效劳下的分布式事务理论案例分析。共识问题解析为什么分布式场景下有共识问题介绍共识算法以及全局消息播送的实现公式算法的根底leader选举以及quorum算法和一些已实现的算法的介绍以及比照VSR、Raft、Paxos、ZAB共识算法在微效劳体系的应用场景介绍效劳发现、一致性kv存储E

17、tcd、Zk和技术的选型怎样权衡一致性的追求以及性能。架构设计解析了很多分布式的问题以及解决方案之后回归微效劳架构模型、技术选型、再回首下微效劳的弊端以及特点微效劳体系的架构要素分析平安、伸缩性、性能、可用性、扩展性结合团队、业务场景的DDD理论以及总结。课程寄语假如你是一位开发工程师相信浏览完本系列课程将会解析很多分布式系统的理论知识同时也会理解一些分布式存储、中间件技术的原理对工作中的分布式架构会有体系化的明晰认知。假如你是一位架构师本系列课程提供了对于分布式系统问题的全面梳理和一些技术背后的理论结合理论以及目前业界先进的方案对于技术选型以及架构搭建提供了参考。第01课分布式系统的问题前言

18、无论是SOA或微效劳架构都是必需要面对以及解决一些分布式场景下的问题。假如只是单效劳、做个简单的主备那么编程那么会成为一件简单幸福的事只要没有bug一切都会按照你的预期进展。然而在分布式系统中假如想当然的去按照单效劳思想编程以及架构那可能会收获很多意想不到的“惊喜网络延迟导致的重复提交、数据不一致、局部节点挂掉但是任务处理了一半等。在分布式系统环境下编程以及在单机器系统上写软件最大的差异就是分布式环境下会有很多很“诡异的方式出错所以我们需要理解哪些是不能依靠的和怎样处理分布式系统的各种问题。理想以及现实微效劳架构跟SOA一样也是效劳化的思想。在微效劳中我们倾向于使用RESTful风格的接口进展

19、通信使用Docker来管理效劳实例。我们的理想是祈望分布式系统能像在单个机器中运行一样就像客户端应用再坏的情况用户只要一键重启就可以重新恢复然而现实是我们必须面对分布式环境下的由网络延迟、节点崩溃等导致的各种突发情况。在决定使用分布式系统或微效劳架构的时候往往是因为我们祈望获得更好的伸缩性、更好的性能、高可用性容错。固然分布式系统环境更加复杂但只要能解析分布式系统的问题和找到合适自己应用场景的方案便能更接近理想的开发环境同时也能获得伸缩性、性能、可用性。分布式系统的可能问题分布式系统从构造上来看是由多台机器节点和保证节点间通信的网络组成所以需要关注节点、网络的特征。1局部失败在分布式环境下有可

20、能是节点挂了或是网络断了如下列图假如系统中的某个节点挂掉了但是其他节点可以正常提供效劳这种局部失败不像单台机器或本地效劳那样好处理。单机的多线程对象可以通过机器的资源进展协调以及同步和决定怎样进展错误恢复。但在分布式环境下没有一个可以来进展协调同步、资源分配和进展故障恢复的节点局部失败一般是无法预测的有时甚至无法知道恳求任务是否有被成功处理。所以在开发需要进展网络通讯的接口时RPC或异步消息需要考虑到局部失败让整个系统承受局部失败并做好容错机制比方在网络传输失败时要能在效劳层处理好并且给用户一个好的反应。2网络延迟网络是机器间通信的唯一途径但这条唯一途径并不是可靠的而且分布式系统中一定会存在网

21、络延迟网络延迟会影响系统对于“超时时间、“心跳机制的判断。假如是使用异步的系统模型还会有各种环节可能出错可能恳求没有成功发出去、可能远程节点收到恳求但是处理恳求的进程突然挂掉、可能恳求已经处理了但是在Response可能在网络上传输失败如数据包丧失或延迟而且网络延迟一般无法区分。即使是TCP可以建立可靠的连接不丧失数据并且按照顺序传输但是也处理不了网络延迟。对于网络延迟敏感的应用使用UDP会更好UDP不保证可靠传输也不会丧失重发但是可以防止一些网络延迟合适处理音频以及视频的应用。3没有分享内存、锁、时钟分布式系统的节点间没有分享的内存不应理所当然认为本地对象以及远程对象是同一个对象。分布式系统

22、也不像单机器的情况可以分享同一个CPU的信号量和并发操作的控制也没有分享的物理时钟无法保证所有机器的时间是绝对一致的。时间的顺序是很重要的夸大一点讲假设对于一个人来讲从一个时钟来看是7点起床、8点出门但可能因为不同时钟的时间不一致从不同节点上来看可能是7点出门、8点起床。在分布式环境下开发需要我们可以有意识地进展问题识别以上只是举例了一局部场景以及问题不同的接口实现会在分布式环境下有不同的性能、扩展性、可靠性的表现。下面会继续上述的问题进展讨论怎样实现一个更可靠的系统。概念以及处理模型对于上述分布式系统中的一些问题可以针对不同的特征做一些容错以及处理下面主要看一下错误检测和时间以及顺序的处理模

23、型。在实际处理中一般是综合多个方案和应用的特点。错误检测对于局部失败需要一分为二的对待。节点的局部失败可以通过增加错误检测的机制自动检测问题节点。在实际的应用中比方有通过LoadBalancer自动排除问题节点只将恳求发送给有效的节点。对于需要有Leader选举的效劳集群来讲可以引入实现Leader选举的算法假如Leader节点挂掉了其余节点能选举出新的Leader。实现选举算法也属于共识问题在后续文章中会再涉及到几种算法的实现以及应用。网络问题由于网络的不确定性比拟难讲一个节点是否真正的“在工作有可能是网络延迟导致的错误通过添加一些反应机制可以在一定程度确定节点是否正常运行比方安康检查机制一

24、般是通过心跳检测来实现的比方使用Docker的话Consul、Eureka都有安康检查机制当发送心跳恳求发现容器实例已经无法回应时可以认为效劳挂掉了但是却很难确认在这个Node/Container中有多少数据被正确的处理了。假如一个节点的某个进程挂了但是整个节点还可以正常运行。在使用微效劳体系中是比拟常见的一台机器上部署着很多容器实例其中个容器实例即相当于刚刚描绘挂掉的进程挂掉了可以有一个方式去通知其他容器来快速接收而不用等待执行超时。比方Consul通过Gossip协议进展多播关于Consul可以参考这篇Docker容器部署Consul集群内容。在批处理系统中HBase也有故障转移机制。在实

25、际做错误检测处理时除了需要节点、容器做出积极的反应还要有一定的重试机制。重试的实现可以基于网络传输协议如使用TCP的RTT可以以在应用层实现如Kafka的at-least-once的实现。基于Docker体系的应用可以使用SpringCloud的Retry结合Hytrix、Ribbon等。对于需要给用户反应的应用不太建议使用太多重试根据不同的场景进展判断更多的时候需要应用做出积极的响应即可比方用户的“个人中心页面当User微效劳挂了可以给个默认头像、默认昵称然后正确展示其他信息而不是反复恳求User微效劳。时间以及顺序在分布式系统中时间可以作为所有执行操作的顺序先后的断定标准可以以作为一些算法

26、的边界条件。在分布式系统中决定操作的顺序是很重要的比方对于提供分布式存储效劳的系统来讲RepeatedRead和Serializable的隔离级别需要确定事务的顺序和一些事件的因果关系等。物理时钟每个机器都有两个不同的时钟一个是time-of-day即常用的关于当前的日期、时间的信息例如此时是2018年度6月23日23:08:00在Java中可以用System.currentTimeMillis()获取另一个是Monotonic时钟代表着单调递增的时间一般是测量时间间距在Java中调用System.nanoTime()可以获得Monotonic时间常常用于测量一个本地恳求的返回时间比方Apac

27、hecommons中的StopWatch的实现。在分布式环境中一般不会使用Monotonic测量两台不同的机器的Monotonic的时间差是无意义的。不同机器的time-of-day一般也不同就算使用NTP同步所有机器时间也会存在毫秒级的差NTP本身也允许存在前后0.05%的误差。假如需要同步所有机器的时间还需要对所有机器时间值进展监控假如一个机器的时间以及其他的有很大差异需要移除不一致的节点。因为能改变机器时间的因素比拟多比方无法判断是否有人登上某台机器改变了其本地时间。固然全局时钟很难实现并且有一定的限制但基于全局时钟的假设还是有一些理论上的应用。比方FacebookCassandra使用

28、NTP同步时间来实现LWWLastWriteWin。Cassandra假设有一个全局时钟并基于这个时钟的值用最新的写入覆盖旧值。当然时钟上的最新不代表顺序的最新LWW区分不了实际顺序另外还有如GoogleSpanner使用GPS以及原子时钟进展时间同步但节点之间还是会存在时间误差。逻辑时钟在分布式系统中因为全局时钟很难实现并且像NTP同步经过也会受到网络传输时间的影响一般不会使用刚刚所述的全局同步时间当然也肯定不能使用各个机器的本地时间。对于需要确认操作执行顺序的时候不能简单依赖一个基于time-of-day的timestamps所以需要一个逻辑时钟来标记一些事件顺序、操作顺序的序列号。常见的

29、方式是给所有操作加上递增的计数器。这种所有操作都添加一个全局唯一的序列号的方式提供了一种全局顺序的保证全局顺序也包含了因果顺序一致的概念。关于分布式一致性的概念以及实现会在后续文章详细介绍我们先将关注点回归到时间以及顺序上。下面看两种典型的逻辑时钟实现。1LamportTimestampsLamporttimestamps是LeslieLamport在1978年度提出的一种逻辑时钟的实现方法。LamportTimestamps的算法实现可以理解为基于每个节点的一对值NodeIdCounter的全局顺序的同步。在集群中的每个节点Node都有一个唯一标识并且每个Node都持有一个本地的对于所有操作

30、顺序的一个Counter计数器。Lamport实现的核心思想就是把事件分成三类节点内处理的事件、发送事件、接收事件1.假如一个节点处理一个事件节点counter1。2.假如是发送一个消息事件那么在消息中带上counter值。3.假如是接收一个消息事件那么更新countermax(本地counter接收的消息中带的counter)1。简单画了个例如如下列图初始的counter都是0在Node1接收到恳求处理事件时counter1C:1表示并且再发送消息带上C:1。在Node1承受ClientA恳求时本地的Counter1ClientA恳求的值所以处理事件时max(1,0)12(C2)然后再发送消

31、息带上Counter值ClientA更新恳求的最大Counter值2并在下一次对Node2的事件发送时会带上这个值。这种序列号的全局顺序的递增需要每次Client恳求持续跟踪Node返回的Counter并且再下一次恳求时带上这个Counter。lamport维护了全局顺序但是却不能更好的处理并发。在并发的情况下因为网络延迟可能导致先发生的事件被认为是后发生的事件。如图中红色的两个事件属于并发事件固然ClientB的事件先发出但是因为延迟所以在Node1中会先处理ClientA也即在Lamport的算法中认为Node1(C:4)happensbeforeNode1(C5)。LamportTime

32、stamps还有另一种并发冲突事件不同的NodeId但Counter值一样这种冲突会通过Node的编号的比拟进展并发处理。比方Node2(C10)、Node1(C10)是两个并发事件那么认为Node2的时间顺序值Node1的序列值也就认为Node1(C10)happensbeforeNode2(C10)。所以可见Lamport时间戳是一种逻辑的时间戳其可以表示全局的执行顺序但是无法识别并发和因果顺序并发情况无法很好地处理偏序。2VectorClockVectorClock又叫向量时钟跟LamportTimestamps比拟类似也是使用SequenceNo实现逻辑时钟但是最主要的区别是向量时钟有

33、因果关系可以区分两个并发操作是否一个操作依赖于另外一个。LamportTimestamps通过不断把本地的counter更新成公共的MaxCounter来维持事件的全局顺序。VectorClock那么各个节点维持自己本地的一个递增的Counter并且会多记录其他节点事件的Counter。通过维护了一组NodeId,Counter值来记录事件的因果顺序能更好得识别并发事件也即VectorClock的NodeId,Counter不仅记录了本地的还记录了其他Node的Counter信息。VectorClock的NodeId,Counter更新规那么1.假如一个节点处理一个事件节点本地的逻辑时钟的co

34、unter1。2.当节点发送一个消息需要包含所有本地逻辑时钟的一组NodeId,Counter记录值。3.承受一个事件消息时更新本地逻辑时钟的这组NodeId,Counter值4.让这组NodeId,Counter值中每个值都是max(本地counter,接收的消息中的counter)。本地逻辑时钟counter1。如下列图简单示意了VectorClock的时间顺序记录三个Node初始counter都是0。NodeB在处理NodeC的恳求时记录了NodeC的Counter1并且处理事件时本地逻辑时钟的counter01所以NodeB处理事件时更新了本地逻辑时钟为B:1,C:1。在事件处理时通过

35、不断更新本地的这组Counter就可以根据一组NodeId,Counter值来确定恳求的因果顺序了比方对于NodeB第二个处理事件A:1,B:2,C:1早于第三个事件A:1,B:3,C:1。在数值冲突的时候如图中粉色剪头标记的。NodeC的A:2,B:2,C:3以及NodeBA:3,B:4,C:1。C:3C:1、B:2B:4种情况认为是没有因果关系属于同时发生。VectorClock可以通过各个节点的时间序列值的一组值识别两个事件的先后顺序。Vector提供了发现数据冲突的方式但是详细如何解决冲突需要由发现冲突的节点决定比方可以将并发冲突抛给Client决定或用Quorum-NRW算法进展读取

36、修复ReadRepair)。AmazonDynamo就是通过VectorClock来做并发检测的一个很好的分布式存储系统的例子。对于复制节点的数据冲突使用了QuorumNRW决议和读修复ReadRepair处理最新更新数据的丧失详细实现可以参考这篇论文Dynamo:AmazonsHighlyAvailableKey-valueStoreDynamo是典型的高可用、可扩展的提供弱一致性最终一致性保证的分布式K-V数据存储效劳。后续文章再介绍Quorums算法时也会再次提到。VectorClock在实际应用中还会有一些问题需要处理比方假如一个上千节点的集群那么随着时间的推移每个Node将需要记录大

37、量NodeId,Counter数据。Dynamo的解决方案是通过添加一个timestamp记录每个Node更新NodeId,Counter值的时间和一个设定好的阀值比方讲阀值是10那么本地只保存最新的10个NodeId,Counter组合数据。小结本文引出了一些分布式系统的常见问题和一些根底的分布式系统模型概念微效劳的架构目前已经被更广泛得应用但微效劳面临的问题其实也都是经典的分布式场景的问题。本文在分布式系统的问题中主要介绍了关于错误检测和时间以及顺序的处理模型。关于时间以及顺序的问题处理中没有一个绝对最优的方案Cassandra使用了全局时钟和LWW处理顺序断定Dynamo使用了Vectorclock发现冲突加上Quorum算法处理事件并发。这两个存储系统都有很多优秀的分布式系统设计以及思想在后续文章中会更详细的介绍数据复制、一致性、共识算法等。关注博主即可浏览全文