文章目录
概述
分布式,通俗意义上来讲，分布式是将一个整体按照分布到不同地方，只要一个节点出现问题，则会导致系统出现问题，分布式就是将多台服务器集中在一起，每台服务器都实现总体中的不同业务。每台服务器都缺一不可，如果某台服务器发生宕机了，则部分功能缺失，将导致整体无法运行。
分布式开发优点和缺点
优点
1.模块解耦：把模块拆分,使⽤接⼝通信,降低模块之间的耦合度
2.项目拆分，不同团队负责不同的⼦项⽬：把项目拆分成若⼲个⼦项⽬,不同的团队负责不同的子项目.
3.提高项目扩展性：增加功能时只需要再增加⼀个子项⽬,调用其他系统的接⼝就可以。
4. 分布式部署：可以灵活的进行分布式部署
5. 提高代码的复用性：比如service层,如果不采⽤分布式rest服务⽅式架构就会在⼿机wap商城,微信商城,pc,android，ios每个端都要写⼀个service层逻辑,开发量⼤,难以维护⼀起升级,这时候就可以采⽤分布式rest服务⽅式,公⽤⼀个service层
缺点：
1.系统之间的交互要使⽤远程通信,接⼝开发增⼤⼯作量；
2.网络络请求有延时；
3. 事务处理⽐较麻烦，需要使⽤分布式事务。
分布式存在的作用
主要是将应用程序的多个功能分配到多个服务器上去处理，细化了应用程序的功能模块，能够减缓服务器的压力，大幅度的提高效率
分布式就是将多台服务器集中在一起，每台服务器都实现总体中的不同业务。每台服务器都缺一不可，如果某台服务器发生宕机了，则网站的部分功能缺失，将导致整体无法运行。
分布式存在的作用主要是将应用程序的多个功能分配到多个服务器上去处理，细化了应用程序的功能模块，能够减缓服务器的压力，大幅度的提高效率。
布式：一个业务分拆多个子业务，部署在不同的服务器上
集群：同一个业务，部署在多个服务器上
举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成。
而分布式，从窄意上理解，也跟集群差不多， 但是它的组织比较松散，不像集群，有一个组织性，一台服务器垮了，其它的服务器可以顶上来。
分布式的每一个节点，都完成不同的业务，一个节点垮了，哪这个业务就不可访问了，传统类型的项目比较把整个业务看做一个整体，是偏向于系统开发的。
而所谓的微服务呢，就只关注与具体业务的，只不过从设计上考虑和移植复用和标准化。搞电商，最早的开发者只分前后台，后来拆分到不同的子系统比如订单、用户、物流、ERP、财务、BI等等，这是第一次的业务拆分。
然后开始流行平台化，对业务拆分的系统有了技术上的要求，统一API，统一标准等。这个时候大家发现，全部统一解耦无状态后，我不需要业务系统了啊，我把子系统直接更进一步独立成服务啊，比如订单服务，支付服务，物流服务，库存服务等等。搞双11，订单压力大，再多跑2个订单服务啊。
所以说，所谓微服务，还是没有脱离分布式的思想，最终目标还是奔着无状态可分布去的
分布式和集群的区别
1.首先从概念上来看，集群就是将全部的服务器都集中起来做同样的事情，而分布式是将一种业务拆分成其他的部分业务分布在多台服务器上；
2.集群是个物理形态，而分布式只是个工作方式；
3.集群一般是物理集中，统一管理的，而分布式则不强调这一点，不管放置在哪个位置，只要通过网络连接起来就行。
集群： 各个集群上内容都是一致，如果一个集群出现问题无法使用，则其他集群可以顶替上去
集群的特点
伸缩性（Scalability）
在一些大的系统中，预测最终用户的数量和行为是非常困难的，伸缩性是指系统适应不断增长的用户数的能力。提高这种并发会话能力的一种最直观的方式就增加资源（CPU，内存，硬盘等），集群是解决这个问题的另一种方式，它允许一组服务器组在一起，像单个服务器一样分担处理一个繁重的任务，我们只需要将新的服务器加入集群中即可，对于客户来看，服务无论从连续性还是性能上都几乎没有变化，好像系统在不知不觉中完成了升级
高可用性（High availability）
单一服务器的解决方案并不是一个健壮方式，因为容易出现单点失效。像银行、账单处理这样一些关键的应用程序是不能容忍哪怕是几分钟的死机。它们需要这样一些服务在任何时间都可以访问并在可预期的合理的时间周期内有响应。高可用性集群的出现是为了使集群的整体服务尽可能可用，以便考虑计算硬件和软件的易错性。如果高可用性集群中的主节点发生了故障，那么这段时间内将由次节点代替它。次节点通常是主节点的镜像，所以当它代替主节点时，它可以完全接管其身份，并且因此使系统环境对于用户是一致的。
负载均衡（Load balancing）
负载均衡集群为企业需求提供了更实用的系统。如名称所暗示的，该系统使负载可以在计算机集群中尽可能平均地分摊处理。该负载可能是需要均衡的应用程序处理负载或网络流量负载。这样的系统非常适合于运行同一组应用程序的大量用户。每个节点都可以处理一部分负载，并且可以在节点之间动态分配负载，以实现平衡。
高性能 (High Performance)
通常，第一种涉及为集群开发并行编程应用程序，以解决复杂的科学问题。这是并行计算的基础，尽管它不使用专门的并行超级计算机，这种超级计算机内部由十至上万个独立处理器组成。但它却使用商业系统，如通过高速连接来链接的一组单处理器或双处理器 PC，并且在公共消息传递层上进行通信以运行并行应用程序。因此，您会常常听说又有一种便宜的 Linux 超级计算机问世了。但它实际是一个计算机集群，其处理能力与真的超级计算机相等。
例如，在一个饭店里面，本来饭店里面只有一个厨师，切菜洗菜炒菜这些工作他全干了，后来随着客人的增多，又找了一个厨师，这个厨师也是能炒同样的菜，这两个厨师干的活一样，关系就是集群；
为了让厨师安心炒菜，把菜做到极致，又给厨师请了个配菜师，主要负责切菜洗菜，那么厨师和配菜师之间的关系就是分布式
BASE 理论
BASE 理论由 eBay 架构师 Dan Pritchett 提出，在 2008 年上被分表为论文，并且 eBay
给出了他们在实践中总结的基于 BASE 理论的一套新的分布式事务解决方案。
BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually
Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性和可用性权衡的
结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，
它大大降低了我们对系统的要求。
BASE 理论的核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，
采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，
系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。
针对数据库领域，BASE 思想的主要实现是对业务数据进行拆分，让不同的数据分布在不
同的机器上，以提升系统的可用性，当前主要有以下两种做法：
按功能划分数据库
分片（如开源的 Mycat、Amoeba 等）
BASE 理论的三要素
1.基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝
不等价于系统不可用。
比如：
响应时间上的损失：正常情况下，一个在线搜索引擎需要在 0.5 秒之内返回给用户相应的
查询结果，但由于出现故障，查询结果的响应时间增加了 1~2 秒
系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能
够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激
增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
2.软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体
可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
3.最终一致性
强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状
态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统
数据的强一致性
CAP理论
Consistency一致性，Availability可用性，Partition tolerance 分区容错性。
分布式系统（distributed system）正变得越来越重要，大型网站几乎都是分布式的。
分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance） 这三项中的两项。
一致性：更新操作成功并返回客户端完成后，所有节点在同⼀时间的数据完全一致，所以，⼀致性，说的就是数据一致性。
可用性：服务一直可用，而且是正常响应时间。
分区容错性：分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务
二段式满足cap理论的哪两个理论
两阶段提交协议在正常情况下能保证系统的强⼀致性，但是在出现异常情况下，当前处理的操作处于错误状态，需要管理员人工干预解决，因此可用性不够好，这也符合CAP协议的⼀致性和可用性不能兼得的原理。
分析下分布式强一致性、弱一致性、最终一致性
强一致性
当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是⽤户上一次写什么，下⼀次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。
弱一致性：
系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写⼊的值，也不会具体的承诺多久之后可以读到
最终一致性：
弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发⽣的前提下，不⼀致窗⼝的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是⼀个典型的最终⼀致性系统。
衡量分布式系统的指标
- 性能：系统的吞吐能力，指系统在某一时间可以处理的数据总量，通常可以 用系统每秒处理的总的数据量来衡量；系统的响应延迟，指系统完成某一功能 需要使用的时间；系统的并发能力，指系统可以同时完成某一功能的能力，通 常也用QPS(query per second)来衡量。上述三个性能指标往往会相互制约， 追求高吞吐的系统，往往很难做到低延迟；系统平均响应时间较长时，也很难 提高QPS。
- 可用性：系统的可用性(availability)指系统在面对各种异常时可以正确提供 服务的能力。系统的可用性可以用系统停服务的时间与正常服务的时间的比例 来衡量，也可以用某功能的失败次数与成功次数的比例来衡量。可用性是分布 式的重要指标，衡量了系统的鲁棒性，是系统容错能力的体现。
- 可扩展性：系统的可扩展性(scalability)指分布式系统通过扩展集群机器规模 提高系统性能（吞吐、延迟、并发）、存储容量、计算能力的特性。好的分布 式系统总在追求“线性扩展性”，也就是使得系统的某一指标可以随着集群中 的机器数量线性增长。
- 一致性：分布式系统为了提高可用性，总是不可避免的使用副本的机制，从 而引发副本一致性的问题。越是强的一致的性模型，对于用户使用来说使用起 来越简单。
分布式下down机的处理⽅案
1、dubbo：服务器宕机，zk临时被删除；
2、springcloud： 每30s发送心跳检测重新进行租约，如果客户端不能多次更新租约，它将在90s内从服务器注册中心移除。
3、apm监控：
分布式系统设计
1、分布式系统设计的两大思路：中心化和去中心化
中心化：中心化的设计思想在自然然界和人类⽣活中是如此的普遍和自然，它的设计思想也很简单，分布式集群中的节点按照角色分工，可以分为两种角色–“领 导”和“干活的”，中心化的一个思路就是“领导”通常分发任务并监督“干活的”，谁空闲了就给它
安排任务，谁病倒了就⼀脚踢出去，然后把它的任务分给其他人；中心化的另⼀个思路是领导只负责生成任务而不再指派任务，由每个“干活的”自发去领任务。
去中心化：全球IP互联网就是⼀个典型的去中心化的分布式控制架构，联网的任意设备宕机都只会影响很小范围的功能。去中心化设计通常没有“领 导”和“⼲活的”，角色一样，地位平等，因此不存在单点故障。实际上，完全意义的去中⼼化分布式系统并不多见，很多看起来是去中⼼化但工作机制采⽤了中心化设计思想的分布式系统正在不断涌现，在这种架构下，集群中的领导是动态选择出来的，而不是⼈为预先指定的，而且在集群发⽣故障的情况下，集群的成员会⾃发举⾏会议选举新的领导。典型案例如 ：zookeeper、以及Go语⾔实现的Etcd。
2、分布式系统的一致性原理
在说明一致性原理之前，可以先了解⼀下cap理论和base理论，具体看《事务与柔性事务》中的说明。
对于多副本的⼀致性处理，通常有⼏种⽅法：同步更新–即写操作需要等待两个节点都更新成功才返回，这样的话如果⼀旦发⽣⽹络分区故障，写操作便不可用，牺牲了A。异步更新–即写操作直接返回，不需要等待节点更新成功，节点异步地去更新数
据，这种⽅式，牺牲了C来保证A。折衷–只要保证集群中超过半数的节点正常并达到⼀致性即可满⾜要求，此时读操作只要⽐较副本集数据的修改时间或者版本号即可选出最新的，所以系统是强⼀致性的。如果允许“数据⼀致性存在延迟时间”，则是最终⼀致性。
如Cassandra中的折衷型⽅案QUORUM，只要超过半数的节点更新成功便返回，读取时返回多数副本的⼀致的值。然后，对于不⼀致的副本，可以通过read repair的⽅式解决。read repair：读取某条数据时，查询所有副本中的这条数据，⽐较数据与⼤多
数副本的最新数据是否⼀致，若否，则进⾏⼀致性修复。此种情况是强⼀致性的。
⼜ 如Redis的master-slave模式，更新成功⼀个节点即返回，其他节点异步地去备份数据。这种⽅式只保证了最终⼀致性。最
终⼀致性：相⽐于数据时刻保持⼀致的强⼀致性，最终⼀致性允许某段时间内数据不⼀致。但是随着时间的增⻓，数据最终会到达⼀致的状态。此种情况只能保证最终⼀致性。著名的DNS也是最终⼀致性的成功例⼦。
强⼀致性算法：1989年就诞⽣了著名的Paxos经典算法（zookeeper就采⽤了Paxos算法的近亲兄弟Zab算法），但由于Paxos算法难以理解、实现和排错，所以不断有⼈尝试优化算法，2013年终于有了重大突破：Raft算法的出现，其中Go语⾔实现的Raft算法就是Etcd，功能类似于zookeeper。
Base的思想：基本可⽤、柔性状态、最终⼀致性，主要针对数据库领域的数据拆分，通过数据分⽚（如Mycat、Amodeba等 ）来提升系统的可⽤性。由于分⽚拆分后会涉及分布式事务，所以接下来看⼀下如何⽤最终⼀致性的思路来实现分布式事务，也就是柔性事务。
3、柔性事务：具体⻅《事务与柔性事务》 。
4、分布式系统的关键Zookeeper
⽬标是解决分布式系统的⼏个问题：集群集中化配置，集群节点动态发现机制，简单可靠的节点Leader选举机制，分布式锁。
ZNode有⼀个ACL访问权限控制列表，提供对节点增删改查的API，提供监听ZNode变化的实时通知接⼝–Watch接⼝。
ZNode类型：持久节点（可以实现配置中⼼）、临时节点（和创建这个节点的客户端会话绑定，可实现集群节点动态发现，可
以实现服务注册中⼼）、时序节点（创建节点时会加上数字后缀，通过选择编号最⼩的ZNode可以实现Leader选举机制）、临时
性时序节点（同时具备临时节点和时序节点的特性，主要⽤于分布式锁的实现）。
paxos和raft分布式一致性算法
Paxos算法和Raft算法—经典的分布式系统一致性问题解决算法
Paxos和Raft都是分布式一致性算法，它们的目标是在分布式系统中保证数据的一致性。
Paxos算法是一种经典的分布式一致性算法，由Leslie Lamport在1998年提出。它使用的是一个基于消息传递的算法，通过在不同的阶段进行消息传递来达成一致性。Paxos算法的基本流程包括：提议者向多个接受者发起提议，接受者对提议进行投票，并将投票结果告知提议者，最终提议者根据接受者的投票结果确定一个值。
Raft算法是由Diego Ongaro和John Ousterhout在2013年提出的，是一种相对较新的分布式一致性算法。
总的来说，Paxos和Raft都是解决分布式一致性问题的有效算法，具有不同的特点和应用场景。
- Paxos算法： Paxos算法是一种基于消息传递的一致性算法，被广泛认为是解决分布式一致性问题最有效的算法之一。它的目标是在分布式系统中就某个值（决议）达成一致。Paxos算法的核心思想是通过多个阶段的投票和提案来达成一致。具体来说，Paxos算法包括三个角色：提议者（Proposer）、接受者（Acceptor）和学习者（Learner）。提议者提出提案，接受者进行投票，学习者学习最终达成的一致值。Paxos算法的实现相对复杂，因此被认为难以理解和实现。
- Raft算法： Raft算法是一种相对于Paxos算法更易理解和实现的分布式一致性算法。Raft算法的设计目标是提供一种更清晰、更模块化的算法，使得分布式系统的一致性问题更容易理解和实现。Raft算法也是基于消息传递的，它将一致性问题分解为几个子问题，如领导者选举、日志复制和安全性等。Raft算法的核心是通过选举一个领导者来协调系统中的操作，并使用心跳机制来维持领导者的地位。相比于Paxos算法，Raft算法的实现更加直观和易于理解。
- 领导者选举：
○ Paxos：没有明确的领导者选举机制。提议者可以随时提出提案，不需要等待其他节点的响应。
○ Raft：引入了领导者选举机制。在Raft中，一个节点可能处于Follower或Candidate状态。当一个节点成为Candidate时，它会开始一个选举过程，通过向其他节点发送请求来尝试成为领导者。如果一个节点在一段时间内没有收到任何响应，它会成为领导者。 - 日志复制：
○ Paxos：在Paxos中，每个节点都有一个独立的日志系统，每个提议者都可以向多个接受者发送提案。每个接受者都可以接受或拒绝提案，并将结果反馈给提议者。提议者根据接收到的反馈来决定最终的提案值。
○ Raft：在Raft中，日志复制是按照一定的规则进行的。领导者负责接收客户端的请求并将这些请求复制到其所有从属节点。从属节点将日志条目复制到其本地日志，并在领导者请求时将日志条目发送给领导者。 - 数据一致性：
○ Paxos：通过确保提议者按照特定的顺序提出提案来确保数据一致性。这确保了所有节点都看到相同的提案顺序，从而确保数据一致性。
○ Raft：通过领导者选举和日志复制机制确保数据一致性。领导者负责接收客户端的请求并将这些请求复制到其所有从属节点。从属节点将日志条目复制到其本地日志，并在领导者请求时将日志条目发送给领导者。 - 容错性：
○ Paxos：Paxos算法具有高度的容错性。即使有节点崩溃或出现故障，其他节点也可以继续正常工作。这是因为每个节点都可以接受或拒绝提案，并将结果反馈给提议者。
○ Raft：Raft算法也具有高度的容错性。即使有节点崩溃或出现故障，其他节点也可以继续正常工作。这是因为每个节点都将其日志条目复制到其从属节点，并确保从属节点在领导者请求时将日志条目发送给领导者。
总的来说，Paxos和Raft都是解决分布式一致性问题的有效算法，具有不同的特点和应用场景。Paxos算法更简单，但Raft算法提供了更强大的领导者选举和日志复制机制，从而提高了系统的稳定性和容错性。
Raft协议
Raft协议是一种用于分布式一致性的共识算法，旨在解决分布式系统中的数据一致性问题。它通过选举领导者（leader）的方式来实现数据的复制和同步。
Raft 算法分布式系统开发首选共识算法，它通过“一切以领导者为准”方式，实现一系列值共识和各节点日志一致。Raft 算法一共涉及三种角色（Follower、Candidate、Leader）和两个过程（Leader 选举和日志复制）。
跟随者（Follower）：默默地收和处理来自 Leader 息，当等待Leader 心跳信息超时时候，就主动站出来，推荐自己当候选人（Candidate）。
候选人（Candidate）：向其他节点发送投票请求，通知其他节点来投票，
如果赢得了大多数（N/2+1）选票，就晋升领导（Leader）。
领导者（Leader）：负责处理客户端请求，进行日志复制等操作，每一轮选举目标就选出一个领导者；领导者会不断地发送心跳信息，通知其他节点我✁领导者，我还活着，你们不要发起新选举，不用找个新领导者来替代我。
- 领导者选举：Raft协议中的节点可以处于三种状态：领导者（leader）、跟随者（follower）和候选者（candidate）。在初始状态下，所有节点都是跟随者。领导者负责接收客户端请求并进行处理。如果跟随者在一定时间内未收到来自领导者的心跳信号，它们将成为候选者并开始选举新的领导者。选举过程中，候选者会发送请求投票的消息给其他节点，获取大多数节点的投票即可成为新的领导者。
- 日志复制：领导者负责接收客户端请求，并将请求以日志条目的形式追加到本地日志中。然后，领导者将该日志条目广播给其他节点，要求它们复制这个日志条目并追加到各自的日志中。一旦领导者收到大多数节点的确认信息，即可将该日志提交，然后应用到状态机中。
- 安全性保证：Raft协议通过保证领导者的一致性来实现安全性。只有具有最新日志的领导者才能向其他节点发送更新请求，从而确保数据的一致性和正确性。
Raft协议相对于其他分布式共识算法（如Paxos）具有更好的可读性和理解性。它将复制状态机的问题抽象成了一种领导者选举和日志复制的机制，并通过限制了节点状态转换的方式来保证了安全性。Raft协议被广泛应用于分布式系统中，如分布式数据库、分布式存储系统等，以确保数据在分布式环境中的一致性。
leader选举和数据一致性
Raft协议通过领导者选举和数据复制来实现数据的一致性。
- 领导者选举：
○ 初始状态下，所有节点都是跟随者（follower）。
○ 如果一个跟随者在一定时间内没有收到来自领导者（leader）的心跳信号，它会转变为候选者（candidate）并发起选举。
○ 候选者会向其他节点发送请求投票的消息，要求其他节点给予支持。
○ 其他节点在收到请求后，如果还没有投票给其他候选者，并且认为该候选者的任期号更高，就会将自己的选票投给该候选者。
○ 候选者需要获得大多数节点的选票（超过半数）才能成为新的领导者。如果没有任何候选者获得足够的选票，那么新的选举将在稍后再次发生。 - 数据一致性：
○ 领导者负责接收客户端请求并将其追加到自己的日志中。这些日志条目包含了待复制和同步的数据。
○ 领导者将日志条目发送给其他节点，要求它们复制同样的日志条目。
○ 其他节点在收到日志条目后，将其追加到自己的日志中，并发送确认信息给领导者。
○ 领导者在收到大多数节点的确认信息后，将该日志条目标记为已提交，并将其应用到状态机中。
○ 一旦该日志条目被应用到状态机中，节点就会根据该日志条目执行相应的操作以保证数据的一致性。
通过领导者选举和数据复制的机制，Raft协议能够实现数据的一致性。选举过程确保了系统中只有一个领导者，从而避免了冲突和数据损坏的可能性。数据复制过程保证了数据在多个节点之间的同步，从而实现了数据的一致性，并且在出现故障或节点变更时能够继续提供服务。