1。分布式系统相关概念1.1模型1.1.1节点节点是按照分布式协议能够独立完成一组逻辑的个体程序。在工程中，它通常指的是一个过程。1.1.2通信节点之间是完全独立和隔离的，唯一的通信方式是通过不可靠的网络。1.1.3存储节点可以通过向与节点同一台机器上的本地存储设备写入数据来保存数据。1.1.4异常情况(1)机器宕机在大型集群中，每日宕机概率为0.1%，其后果是机器节点无法在工作后丢失所有内存信息，重启。(2)网络异常报文丢失：网络拥塞、路由变化、设备异常、网络分区（部分异常）报文乱序：IP存储转发、路由不确定、网络报文乱序数据错误：位错误不可靠TCP:到达协议后stackandbetweenarrivingprocesses,suddenshutdown,tcpdisorderofdistributedmultiplenodes(3)分布式系统三种状态下的任何请求都必须考虑三种情况：成功，失败，超时。对于超时的请求，无法得知请求是否执行成功。(4)存储数据丢失(5)其他异常的慢IO操作，网络抖动，拥塞节点上持久化了相同的数据。例如，GFS的同一个chunk的多个副本服务副本：多个节点提供相同的服务，服务不依赖于本地存储，数据来自其他节点。比如MapReduce的JobWorker1.2.2副本一致性副本的一致性是针对分布式系统的，不是针对某个副本的。根据强弱程度分为：强一致性：任何用户/节点都可以随时读取最后更新的副本数据。单调一致性：任何时候任何用户一旦读取了某个数据的更新值，就不会读取旧值会话一致性：任何用户一旦在某个会话中读取了某个数据的更新值，他就不会在此会话中读取旧值。一致性：每个副本的数据最终都会达到一致状态，但是时间不保证弱一致性：没有实用价值，省略。1.3衡量分布式系统的指标1.3.1性能吞吐量：在一定时间内能够处理的数据总量响应延迟：完成某项功能所需的时间并发能力：QPS（querypersecond）1.3.2可用性系统停用1.3.3可扩展性通过扩展集群机器来提高系统性能、存储容量和计算能力的特性是分布式系统独有的特性1.3.4一致性副本带来的一致性问题1.3.5：分布式可视化监控方案架构系统1.架构师如何解决分布式架构系统的监控问题。2、ELK是谁，从哪里来，又要到哪里去？3、京东海量数据检索，一起来体验吧。4、只需点击鼠标，即可一键完成高质量的监控界面。5、你离互联网架构师还有多远??？听听就好。6、架构师的技术栈应该是什么样的？你可以问，我一定会回答。转发转发转发重要的事情说3遍转发关注我的私信我会发私信：Java架构领取分布式架构思维导图和资深架构师讲解的分布式精讲视频资料（还提供高并发、spring源码、mybatis源码、dubbo、netty等多个知识点的Video技术分享！二、分布式系统原理2.1数据分布方式无论计算还是存储，问题的输入对象都是数据。如何拆分分布式系统的输入数据称为分布式系统基本问题2.1.1哈希方法一种常见的哈希方法是根据数据所属的用户id计算哈希优点：Hashability：元数据好资料：只需要功能+服务器总量缺点：扩展性：差，一旦集群规模扩大，大部分数据需要迁移重做分布式数据倾斜：当某个用户id的数据量极大时，很容易达到单台服务器处理能力的上限2.1.2按数据范围分布数据根据的取值范围划分数据特征值。比如用户id的取值范围分为[1,33),[33,90),[90,100),分三台服务器处理。请注意，区间大小与区间内数据的大小无关。优点：可扩展性：好。根据数据量灵活拆分原始数据范围缺点：元信息：大。容易成为瓶颈。2.1.3按数据量分布与按范围分布类似，元信息很可能成为瓶颈。2.1.4一致性哈希(1)以一台机器为节点，用哈希函数计算数据（特征）的哈希值，使哈希函数的值域成为闭环，节点随机分布在戒指上。每个节点负责按顺时针方向从自身到下一个节点处理值字段上的数据。优点：可扩展性：优秀。任何节点的动态添加和删除只影响相邻节点。缺点：元信息：大而复杂的随机分布节点容易造成不均匀性。动态添加节点后，只能解除相邻节点。当一个关节出现异常时，压力全部转移到相邻节点(2)虚拟节点虚拟节点，虚拟节点数量远大于机器数量，虚拟节点均匀分布在距离环上，而真实节点机器节点是通过元数据找到的。优点：某个节点不可用导致多个虚拟节点不可用，平衡了压力。增加一个新节点会导致增加多个虚拟节点，从而缓解全局压力。数据重复问题。(1)机器副本的缺点：恢复效率：低。如果1有问题，从23复制数据会消耗更多的资源。为避免影响服务，2将下线进行专项复印。结果，正常的工作副本只有3个。可扩展性：差。如果系统中的三台机器互为副本，那么只增加两台机器是无法形成新的副本组的。可用性：差。一台downw机器，其余两台机器压力增加50%。理想情况下会均匀分布到整个集群，而不是单个副本组(2)以数据段为单位的一个副本，比如3台服务器，10G数据，100M每个数据段对100hash取模得到，每台服务器是负责333数据部分。一旦数据被划分成数据段，就可以以数据段为单位管理副本，副本不再与机器硬关联。比如系统中有3个数据opq，每个数据段三份，系统中有4台机器：优点：恢复效率：高。可以同时复制整个集群可用性：好。machinedownmachine的压力分散到整个集群项目中，完全按照数据段建立replicas会造成元数据开销的增加。这种方法是将数据段组成一个大数据段。2.1.6本地化计算如果计算节点和存储节点位于不同的物理机上，开销会很大，网络带宽会成为系统的瓶颈；将计算调度到与存储节点在同一物理机上的节点称为计算本地化。2.2基本副本协议2.2.1集中式副本控制协议集中式副本控制协议的基本思想：一个中心节点协调副本数据的更新，维护副本之间的一致性，并发控制并发控制：多个节点需要修改该副本同时处理数据时，需要解决“写-写”、“读写”等并发冲突。单机系统采用锁等方式进行并发控制，也可以采用集中式协议。缺点是过于依赖中心节点。2.2.2primary-secondaryprotocol这是一种常用的集中式副本控制协议，只有一个节点作为主副本。需要解决的问题有4个：(1)数据更新的基本过程由主节点协调更新外部节点，并将更新操作发送给主节点。主节点执行并发控制并确定并发更新操作的顺序。主节点将更新操作发送给从节点。primary根据secondary节点的完成判断更新是否成功，然后将结果返回给外部节点。在步骤4中，一些系统例如GFS使用中继来同步数据，primary->secondary1->secondary2，以避免主带宽成为瓶颈。(2)数据读取方法方法一：由于数据更新过程是由primary控制的，所以primary副本上的数据一定是最新的。因此，始终只读取主副本的数据可以实现强一致性。为了避免机器浪费，可以采用前面讨论的方法对数据进行分段，以数据段为复制单位。达到每台机器都有一个primarycopy的目的。方法2：次要的可用性由主要控制。当主要更新次要失败时，将其标记为不可用。不可用的辅助副本会继续尝试与主副本同步数据，直到它在成功同步后变得可用。方法三：仲裁机制。后续讨论。(3)主副本的确定和切换如何确定主副本？当主副本所在机器异常时，如何切换副本？通常在主从分布式系统中，哪个副本为主的信息属于元信息，由专门的元数据服务器维护决定。执行更新操作时，首先查询元数据服务器获取副本的原始信息，然后进一步执行数据更新过程。切换副本有两个难点：如何判断节点状态发现原主节点异常（Lease机制）。切换primary后不影响一致性（Quorum机制）。(4)数据同步当secondary和primary不一致时，secondary需要和primary进行同步。造成不一致的原因有以下三种：网络分裂等异常导致secondary滞后于primary。一种常用的方法是在primary上重放操作日志（redolog），以追上primary的更新进度。在某些协议下，secondary是脏数据，被丢弃并转移给third，或者设计一种基于undologs的方法。Secondary是新添加的一个完全没有数据的副本，直接复制Primary的数据，但是要求Primary可以同时继续提供更新服务，这就需要Primary副本支持快照功能。即把复制数据在某个时刻形成一个快照，然后复制快照，然后用回放日志的方式追上快照后的更新操作。2.2.3去中心化拷贝控制协议去中心化拷贝控制协议没有中心节点，各节点通过平等协商达成共识。唯一可以在强一致性要求下应用的项目就是paxos协议。后续介绍。2.3租赁机制2.3.1基于租赁的分布式缓存系统(1)需求：分布式系统中有一个节点A存储和维护系统的元数据，系统中的其他节点访问A读取和修改元数据，导致A的性能成为系统瓶颈。为此，设计了元数据缓存，在每个节点上缓存元数据信息，以减少对A的访问，提高性能。各节点的缓存数据始终与A一致，可以处理节点宕机、网络中断等异常情况(2)解决原理：A向各节点发送数据，同时向该节点发出租约。每个租约都有一个有效期，通常是一个明确的时间点。一旦实际时间超过第二个时间点，租约在租约有效期内到期，A保证不会修改相应数据的值。当A修改数据时，首先阻塞所有新的读请求，等待之前为数据发出的所有租约到期，然后修改数据的值(3)客户端节点读取元数据的过程if(metadataisinlocalcache&&leaseisvalid){直接返回缓存中的元数据；}else{Result=请求从A读取元数据信息；如果（Result.Status==SUCCESS）{WriteToCache（Result.data，Result.lease）;}elseif(Result.Status==FAIL||Result.Status==TIMEOUT){retry()或exit();}}(4)client节点修改元数据的进程节点向A发送修改元数据的请求收到修改请求后，阻塞所有新的读数据请求，即接受读请求但数据不返回。A等待与元数据相关的所有租约超时。A修改元数据，将修改成功返回给节点。(5)优化点A修改了meta，在数据处理过程中应该阻塞所有新的读请求。这是为了防止持有租约的新缓存节点发出新的租约，形成活锁。优化方法是：一旦A进入修改流程，不再盲目阻塞读请求，而是只返回数据，不返回读请求的租约。因此，缓存节点只能读取数据，而不能缓存数据。进一步的优化是返回当前发出的租约的最大值。这也避免了活锁问题。A在修改元数据时需要等待所有租约到期。优化方法为：A主动通知每个持有租约的节点放弃租约，并清除缓存中的相关数据。如果收到缓存节点的回复，确认协商通过，则可以提前完成修改动作；如果失败或中途超时，则进入正常的等待租约到期的流程，不影响协议的正确性。2.3.2租赁机制深入分析（1）租赁定义租赁是发行人授予的在一定有效期内的承诺。发行人一旦发出租约，无论接收者是否收到，无论后续接收者处于何种状态，只要租约没有到期，发行人就必须严格遵守承诺；另一方面，接收方可以在租约有效期内使用发行方的承诺，一旦租约到期，不得继续使用。(2)租赁的解释由于租赁只是一种承诺，具体的承诺内容可以很广泛，可以是上节数据的正确性，也可以是某种权限。比如在并发控制中，同时只对某个节点发出租约，只有租约的持有者才能修改数据；例如在primary-secondary中，持有lease的节点有primary身份等。(3)lease的高可用有效期的引入很好的解决了网络异常问题。由于租约是一个确定的时间点，因此可以简单地重传；一旦收到租约，就不再依赖于网络通信(4)租约的时钟同步项目将发布者的有效期设置为大于接收者的有效期，即大于时钟误差。以免影响租约的有效性。2.3.3基于租约机制确定节点状态。在分布式系统中很难确定节点是否处于正常工作状态。由于存在网络分化的可能性，无法通过网络通信确定节点的状态。例如：abc互为副本a是主节点，q是监控节点。q通过ping判断abc的状态，认为a不能工作。把master节点切换到b就可以了。但实际上只是收不到ping，a认为自己没有问题，出现了a和b都认为自己是master节点的“双主”问题。解决方法是在q发送心跳的时候加上lease，也就是确认abc的状态，让节点在lease的有效期内正常工作。q给主节点一个特殊的租约，表示该节点作为主节点工作。一旦q想要切换primary，只需要等待上一个primary的租约到期就可以避免双主问题。2.3.4工程上一般选择租约的有效期为10秒。2.4Quorum机制2.4.1Write-all-read-one对于某个更新操作Wi，只有当所有N个副本都更新成功时，才算一次“成功提交更新操作”，对应的数据为“成功提交数据”，数据版本为Vi。缺点：频繁读写版本号容易成为瓶颈。当N-1个副本成功时，仍认为更新失败。2.4.2Quorum定义WARO最大限度的提高了读服务的可用性，最大程度的牺牲了写服务的可用性。通过折衷读写可用性，会得到一个Quorum机制：在Quorum机制下，一旦更新Wi在所有N个副本的W个副本上成功，则称为“成功提交的更新操作”，对应的数据为“Successfully提交的数据”。令R>N-W，最多需要读取R个副本，则读取Wi的更新数据Vi。可以看出WARO是Quorum中W=N时的特例。2.4.3读取最近一次成功提交的数据Quorum的定义基于两个假设：读者知道当前提交的版本号每次都是提交成功现在取消这两个假设，分析下面的实际问题：N=5,W=3，R=3，某副本的状态为（V2V2V2V1V1）。理论上读任意3份肯定能读到最新的数据V2，但是只读3份并不能保证读到最新的数据。比如读取了(V2V1V1)，因为副本状态为(V2V1V1V1V1)时也读取了(V2V1V1)，此时V2版本的数据为提交失败。所以只看3无法判断最新有效版本是V2还是V1。操作成功。成功的版本号保证连续读取R份，对于版本号最高的数据：如果有W份，则数据为最新结果；否则，假设有X个副本，继续读取其他副本，直到成功读取本版本的W个副本。如果找不到W，则第二大版本号为最新成功提交的版本。因此，单纯使用Quorum机制时，需要读取最多R+(W-R-1)=N份才能确定最新成功提交的版本。实际项目中，一般采用quorum和primary-secondary的结合，避免需要读取N份。2.4.4基于Quorum机制选择primary在primary-secondary协议中引入quorum机制：即primary成功更新W个副本，返回成功给用户。当primary异常时，需要选择一个新的primary，然后secondary副本和primary同步数据。通过监控节点q完成切换primary。引入quorum后，选择新primary的方法与读取数据类似，即q读取R个副本，在R个副本中选择版本号最高的副本作为新的primary。新的primary和q选出的replicas被移除后，剩下的至少W个replicas完成数据同步，然后作为新的primary。言外之意就是R个副本中版本号最高的那个副本一定是最新成功提交的数据。虽然不能确定版本号最高的数据==最新提交成功的数据，但是新的primary立即完成了W份的更新，使其数据提交成功。例如：N=5W=3R=3系统，副本在某一时刻的状态（V2V2V1V1V1），此时V1是最新成功提交的数据，V2是中间的数据未成功提交的状态。V2是作为脏数据被丢弃还是作为新数据被同步，完全取决于它能否参与到q所托管的新primary的选举中。如果q选择的是(V1V1V1)，则V2会在下一次更新过程中作为脏数据被丢弃；如果q选择(V2V1V1)，则V2会更新V1，成为最新的成功数据。2.5日志技术日志技术不是分布式系统技术，但是分布式系统广泛使用日志技术进行宕机恢复。2.5.1数据库系统日志回顾数据库日志分为四种类型：undoredoredo/undono-redo/no-undo，这里不再介绍。2.5.2重做和检查点通过重做日志恢复宕机的缺点是需要扫描整个重做日志，回放所有的重做日志。解决这个问题的方法是引入检查点技术。简化模型下，checkpoint在begin和end之间，内存按照一定的数据组织方式dump到磁盘。这样当down机恢复时，只需要向前找到距离最后一个end最近的begin，恢复中间内存状态。2.5.3no-undo/no-redo这个技术也叫01目录，就是有两个目录，activedirectory和inactivedirectory，还有一个masterrecord，或者“recorddirectory0”，demonrecord”usedirectory1”，目录0和1记录了每条数据在日志文件中的位置。2.6两阶段提交协议2.7基于MVCC的分布式事务由于这两个都与数据库事务有关，而两阶段提交协议在工程上的价值不大，因此省略。2.8Paxos协议是唯一在工程上有用的去中心化副本节点控制协议。理解起来太复杂了。2.9CAP理论ConsitencyAvailiablityTolerancetolerancetothePartition设计一个分布式协议完全具备CAP的三个属性是不可能的。三者之间永远只能妥协。该理论的意思是：不要试图去设计一个完美的分布式系统。
