1.分布式架构详解1.分布式发展历史1.1单点中心化特点：App、DB、FileServer都部署在一个上面机器。且访问请求少1.2应用服务和数据服务拆分特点：App、DB、FileServer部署在独立的服务器上。且访问请求少1.3使用缓存提高性能特点：数据库中经常访问的数据存储在缓存服务器中，减少数据库访问次数，减轻数据库压力1.4应用服务器集群特点：多台应用服务器外接通过负载均衡提供服务，解决单台服务器处理能力上限问题1.5数据库读写分离特点：数据库读写分离（主从）设计，解决数据库处理压力1.6反向代理CDN加速特点：利用反向代理和CDN加速系统的访问速度1.7分布式文件系统和分布式数据库特点：数据库采用分布式数据库，文件系统采用分布式文件系统。支持分布式数据库的数据库和分布式文件系统是数据库拆分后的最后手段。只有在单表规模非常大的时候才会用到。分库比较常用的方式是业务分库，分库部署不同业务的数据库。在不同机器上2.分布式技术详解1.并发2.分布式大任务拆分成多个任务部署到多台机器对外提供服务3.缺少全局时钟时间统一4.等价一服务部署是在多台机器上都一样，没有任何区别。5.故障肯定会发生。硬盘坏了，CPU也烧了....三、分布式事务1.ACID原子性（Atomicity）：在一个事务（transaction）中所有的操作要么完成要么没有完成，不会在某个环节结束中间。如果事务执行过程中出现错误，将恢复（Rollback）到事务开始前的状态，就好像事务从未执行过一样。一致性：事务开始前和事务结束后，不破坏数据库的完整性。这意味着写入的数据必须完全符合所有预设的规则，包括数据的准确性、序列性，后续的数据库才能自发地完成预定的工作。比如A有500元，B有300元，A转100元给B，无论如何，A和B的总和永远是800元。隔离（Isolation）：数据库允许多个并发事务同时读写它的数据。修改、隔离的能力可以防止多个事务并发执行时交叉执行造成的数据不一致。事务隔离分为不同的级别，包括未提交读（Readuncommitted）、已提交读（readcommitted）、可重复读（repeatableread）和序列化（Serializable）。持久性：事务处理结束后，对数据的修改是永久性的，即使系统出现故障也不会丢失。2.2P/3P2P=TwoPhasecommitTwo-phasecommit（RDBMS（关系型数据库管理系统）常采用这种机制保证强一致性）3P=ThreePhasecommit三阶段提交说明：2P/3P是保证事务ACID(Atomicity,Consistency,Isolation,Persistence)2.12P的两个阶段Phase1：提交事务请求（投票阶段）询问事务是否可以提交Phase2：执行事务提交（commit，rollback）真正提交事务2.23P的三个阶段Phase1:Whethertocommit-询问是否可以做事务commitPhase2:Pre-commit-预提交事务拆分为前两个阶段3.CAP理论一致性（Consistency）：数据的分布式数据库保持一致可用性（Availability）：任何一个节点挂了，其他节点可以继续提供服务分区容错（网络分区）分区容错：一个数据库所在的机器坏了，比如硬盘坏了，数据丢失了。可以添加一台新机器，然后同步其他正常机器的备份数据。CAP理论的特点：CAP只能满足其中的2个BarCA(abandonP):把所有的数据放在一个节点中。满足一致性和可用性。AP（放弃C）：放弃强一致性，用最终一致性来保证。CP（abandonA）：一旦系统出现故障，受影响的服务器需要等待一段时间，恢复期间不能对外提供服务。举例说明CAP理论：有3台机器，分别有3个数据库和2张表，数据都是一样的（Machine1-db1-tbl_person，tbl_orderMachine2-db2-tbl_person，tbl_orderMachine3-db3-tbl_person，tbl_order1）指向向machine1的db1插入数据到表tbl_person和tbl_order时，插入的数据必须同时同步到machine2和machine3，这就是一致性2）其中一台机器宕机时，还能继续对外提供服务world,并重启宕机的机器启动继续服务，这就是可用性3）当machine1的机器坏了，数据全部丢失时，不会有问题，因为machine2和machine3上还有数据，添加另一台机器machine4，把machine2和machine3放在其中同步一台机器的备份数据就可以了，也就是分区容错4.BASE理论基本可用（basiclyavailable），soft状态（softstate），和最终一致性（Eventuallyconsistent）是基本可用的：分布式系统中出现的Faults，允许部分可用性的损失（服务降级，页面降级）软状态：允许分布式系统中的中间状态。并且中间状态不影响系统的可用性。1、这里的中间状态指的是最终一致性，不同数据复制之间的数据更新可以延迟。2、如CAP理论中的例子，当向machine1的db1的表tbl_person和tbl_order插入数据时，同时需要将插入的数据同步到machine2和machine3。当machine3网络出现问题时，同步失败，但过一会网络恢复，同步成功。这种同步失败的状态称为软状态，因为最后同步成功了。最终一致性：数据复制随着时间的推移达到一致性。5.Paxos算法5.1在介绍Paxos算法之前，我们先来看一个关于拜占庭将军问题的小故事。拜占庭帝国是5至15世纪的东罗马帝国。拜占庭现在是土耳其的伊斯坦布尔。我们可以想象，拜占庭军队有很多分支，驻扎在敌人的城外，每个分支都有自己的将军指挥。假设有11位将军，将军只能与通讯员通信。观察敌人后，忠诚的将军们必须制定统一的行动计划——进攻或撤退。但这些将领中有内奸，不愿忠心的将领达成一致，从而影响了统一行动计划的制定和下发。问题来了：将军们必须有一个协议，让所有忠诚的将军都能同意，而少数叛徒不能让忠诚的将军做出错误的计划——让一些将军进攻，而另一些将军撤退。假设有9名忠将，5名判官进攻，4名判官撤退，2名密探判官恶意撤退。虽然结果是错误的撤退，但是这种情况是完全允许的。因为这11位将军仍然保持状态一致性。总结：1）11名将领攻城2）同时进攻（提案、决议）同时撤退（提案、决议）3）无论是撤退还是进攻，都必须有一半的将军同意执行4）如果有叛徒将军们，他们将干扰解决生成5.2接下来介绍一下Paxos算法。GoogleChubby的作者MikeBurrows表示，世界上只有一种共识算法，那就是Paxos，其他算法都有缺陷。Paxos:Majorityresolution（最终解决一致性问题）Paxos算法有三个角色：Proposer,Acceptor,LearnerProposer：Submitter（提案提交者）提交动议（判断是否超过一半），提交proposalforapproval（判断是否超过半数）超过一半)Acceptor:Receiveproposer(proposalreceiver)接受或拒绝proposal，并回复proposer(promise)Learner:如果learner(打酱油)生成了proposal，就会学习proposal。设置1：如果Acceptor不接受提议，那么他必须接受第一个提议。设定二：每个提案必须有一个编号，编号只能增加不能重复。越往后越大。设置3：接受一个大数字的提议。如果小于之前接受的提案编号，则不接受。Setting4:有2种类型的proposals(submittedproposals,approvedproposals)1)Preparestage(proposalsubmission)a)ProposerwantsaproposalV.首先向大多数Acceptor发送一个Preparerequest。Prepare请求的内容是序号Kb)Acceptor收到序号为K的Prepare请求后，检查自己是否处理了Prepare请求。c)如果Acceptor没有接受过任何Prepare请求，则回复ProposerOK，这意味着Acceptor必须接受收到的第一个提议（设置1）d)否则，如果Acceptor之前接受过任何Prepare请求（例如:MaxN),然后比较提案编号,ifKe)ifK>=MaxN,则检查之前是否有通过的提案,如果没有则使用OK回复Proposer,并记录Kf)ifK>=MaxN,然后检查之前是否有批准如果有提案，则回复批准的提案编号和提案内容（例：2）Acceptstage（批准阶段）a)Proposer收到Acceptor半数以上的回复，全部回复OK，并没有附上批准的提案编号和议案内容。然后Proposer继续提交审批请求，不过此时会一并提交提案编号K和提案内容V(b)Proposer收到Acceptor半数以上的回复，回复都OK，以通过的提案编号和提案内容(c)Proposer未收到超过半数的Acceptor回复，则将提案编号K修改为K+1，重新发送编号给Acceptor（重复上面的过程Preparephase)d)Acceptor收到Proposer的Accept请求，如果NumberKe)Acceptor收到Proposer的Accept请求，如果NumberK>=MaxN，则批准该提案，并将批准的提案设置为f)一段时间后，Proposer比较Proposer收到的Accept回复，如果超过一半，流程结束（代表提案通过），并通知Leaner可以学习该提案。g)一段时间后，Proposer比较Proposer收到的Accept回复。如果不超过半数，Proposer将修改提案编号，重新进入Prepare阶段。5.3PaxosExample示例1：场景角色依次提出：proposer：staff1，staff2acceptor：general1，general2，general3（决策者）1）staff1发起提案，派信使发信给3位将军，内容为（第1位）；2）三位将军收到了工作人员1的提议，由于他们之前没有保存过任何号码，所以保存（1号）以免忘记；同时，他们要求送信人将信件取回，内容为（ok）；3）职员1收到至少2位将军的回复，再次向3位将军发送使者，内容为（编号1，攻击时间1）；4）3位将军收到员工1的回复后，发送（编号1，攻击时间1）保存，以免遗忘；同时让信使把信拿回去，内容是（Accepted）；5）工作人员1收到至少2位将军的（Accepted）内容，确认攻击时间已被所有人收到；6）参谋2发起提案，派信使给3位将军，内容为（编号2）；7)3位将军收到员工2的提议，由于(2号)大于(1号)，他们将(2号)保存起来，以免遗忘；并且因为他之前接受过Staff1的提议，所以他让信使带回信，信上写着（编号1，攻击时间1）；8)工作人员2收到了至少2位将军的回复。人员1提议的接受内容被带入，因此人员2不再提出新的攻击时间，并接受人员1提出的时间；示例2：跨场景角色：proposer：staff1,staff2acceptor：general1,general2.General3(decisionmaker)1)Staff1发起提案，发信给3位将军，内容为(编号1));2)3位将军的情况如下：a)将军1和将军2接收职员1将军1和将军2将记录（编号1），如果有其他职员提出较小的人数，则拒绝；同时让信使把信拿回去，内容是（ok）；b)负责通知将军3信号兵被逮捕，所以将军3没有收到参谋1的提议；3）参谋2同时也发起了一个提案，给信号兵发了一封信给3位将军，内容是（编号2）；4)3位将军的情况如下a)将军2和将军3收到了参谋2的提案，将军2和将军3将记录下来（编号2）。如果任何其他工作人员提出较少的人数，将被拒绝；同时让信使把信拿回去，内容是（ok）；b)负责通知将军1的信号兵被捕，所以将军1没有收到参谋2的提议；5）参谋1收到至少2位将军的回复，再次向回复的2位将军发送信号兵，内容为（编号1，攻击时间1）；6）两个将军的情况如下a）将军1收到（编号1，攻击时间1），和自己保存的编号一样，所以把（编号1，攻击时间1）保罗保存;同时让通讯兵把信拿回去，内容是（Accepted）；b)将军2收到了(编号1，攻击时间1)，因为(编号1)比保存的(编号2)小，所以让通讯兵把信带回去，内容是(拒绝，编号2));7)参谋2收到至少2位将军的回复，派信使给回复的2位将军发信，内容为(No.2,AttackTime2)；8）将军2和将军3收到了（编号2，攻击时间2），和自己保存的编号一样，所以保存（编号2，攻击时间2），让信使把信拿回去，内容is(Accepted);9)staff2收到至少2个将军的(Accepted)内容，确认攻击时间已被多数人接受；10)Staff1只收到了1位将军的(Accepted)内容，同时收到了(Rejected,number2)；Staff1重新发起提案，并派人带信给3位将军，内容为是（3号）；11)3位将军的情况如下a)将军1收到职员1的提议，因为（编号3）大于之前保存的（编号1），所以保存（编号3）；既然将军1已经接受了参谋1之前的提议，让信使把信拿回去，内容为（编号1，攻击时间1）；b)General2acceptsAccordingtoStaff1'sproposal，由于（No.3）大于之前保存的（No.2），（No.3）被保存；由于将军2接受了参谋2的提议，因此传信人回信，内容为（2号，攻击时间2）；c)负责通知将军3的通讯兵被捕，所以将军3没有收到参谋1的提议；12)staff1收到了至少2个将军的回复，比较两个回复的数字，选择数字大对应的攻击时间作为最新的proposal；参谋1给再次响应的2位将军发信，内容为（编号3，攻击时间2）；13）收到的将军1和将军2（号码3，攻击时间2）和自己保存的号码相同，所以保存（号码3，攻击时间2），让信使回信，内容为（公认）;14)Staff1已经收到（接受）了至少2位将军的内容，确认攻击时间已经被多数人接受4、ZookeeperZAB协议ZookeeperAutomicBroadcast（ZAB），即Zookeeper原子广播，是经典的Paxos实现术语：quorum：集群一半以上的集合1.ZAB（zookeeper）中的节点分为四种状态:looking:选举Leader的状态（Crashrecoverystate）following:Follower（跟随者）状态，服从Leader命令leading：当前节点为Leader，负责协调。observing：观察者（observer），不参与选举，只读节点。2、ZAB中的两种模式（ZK如何进行选举）崩溃恢复，消息广播1）崩溃恢复的leader挂了，需要选举新的leader。每个服务器都有一票，比如(3,9),Voteforyourself。b.每个服务器为自己投票后，它会为其他仍然可用的服务器投票。例如Server3的(3,9)分别投给Server4和Server5，类比c。比较选票，比较逻辑：先比较Zxid，Zxid相同才比较myid。比较Zxid时，大的为leader；比较myid时，小的是leaded。更改服务器状态（崩溃恢复->数据同步，或崩溃恢复->消息广播）。number)：follower已经接受了leader的更改年号（newepoch）的提议。currentEpoch（比喻：当年）：当前年份lastZxid：历史上最近收到的提案zxid（最大值）history：当前节点收到的交易提案的logZxid数据结构说明：cZxid=0x10000001b64位数据structure高32位：10000Leader循环号+myid的组合低32位：001b交易的自增序列（单调递增序列）只要客户端有请求，就+1。当新的Leader产生时，会从Leader服务器中取出本地日志中最大的事务Zxid，从中读取epoch+1，作为新的epoch，并将低32位置0（保证绝对自id递增）2）消息广播（类似2P提交）a．Leader接受请求后，将这个请求分配给一个全局唯一的64位自增Id（zxid）。b.将zxid作为提案发送给所有关注者。C。当所有的follower收到proposal，想要将proposal写入硬盘后，立即回复leaderACK（OK）。d.当Leader收到合法数量（超过一半）的Acks时，Leader向所有follower发送commit命令。e.follower执行提交命令。注：此阶段ZK集群正式对外提供服务，Leader可以广播消息。如果有新节点加入，则需要进行同步。3)数据同步a．取出leader的最大lastZxid（从本地log日志中）b．找到zxid对应的数据并进行同步（数据同步过程保证所有follower一致）c．只有满足quorum，同步完成，quasi-Leader才能成为realoneleader
