1、分布式系统基础重要要点： 数据库
1 对外提供无状态节点，内部实现具体有状态或者无状态节点逻辑，节点便可以是提供服务，也能够是存储数据。 浏览器
2 拜占庭问题，在分布式系统中的使用，目的是保证服务可用，而不是找出错误的节点，若是。 缓存
3 异经常见状况，机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的TCP。多是收到消息后宕机、也多是处理完成之后机器宕机、处理完成任务后发送确认消息是网络异常。也有多是发出去的消息丢失，或者发送确认消息时丢失。可能先发送出去的数据后收到 服务器
4 分布式状态、成功、失败、超时。超时的状况，不能判断是否成功，原有同上。 网络
5 数据存储在机械硬盘上，随时有可能发生异常，致使数据没有能正确存储。 并发
6 没法归类的异常，好比，系统的处理能力时高、时低，的诡异行为。 负载均衡
7 即便是小几率事件，在天天百万、千万、及以上的运算量时也会上升为大几率事件。 分布式
8 副本提升数据的冗余，提升系统的可用性，可是在使用副本代来好处的同时，也致使维护副本须要成本。如副本的一致性，多个副本一致性，多个副本直接可能到不一致。 性能
9 一致性级别：强一致性、单调一致性，读取最新数据、会话一致性，经过版本读取统一值。最终一致性、弱一致性。 spa
10 分布式系统性能指标：吞吐量、响应延迟、并发量；经常使用单位QPS，即每秒钟的处理能力。高吞吐量会带来低响应、他们之间是相互制约关系。
11 可用性指标：能够服务时间和非服务时间的比率和请求的成功和失败次数来衡量。
12 可扩展性指标：实现能水平扩展，增长低配置的机器便可以实现更大的运算量，和更高的处理能力。
13 一致性指标：实现副本间的一致性能力，一致性须要严格考量是否业务容许。
2、分布式系统原理：
1． 哈希方式，把不一样的值进行哈希运算，映射到，不一样的机器或者节点。考虑冗余的时候能够把多个哈希值映射到同一个地方。哈希的实现方式，取余。其实现扩展时，比较困难，数据分散在不少机器上，扩展的时候要从个机器上获取数据。并且容易出现分布不均有的状况。
常见的哈希，用IP、URL、ID、或者固定的值进行哈希，老是获得相同的结果。
2． 按数据范围分布，好比ID在1~20的在机器A上，ID在21~40的在机器B上，ID在40~60的在机器C上实现，ID在60~100的分布在机器D上，数据分布比较均匀。若是某个节点处理能力有限，能够直接分裂该节点。维护数据分布的元信息，可能出现单点瓶颈。几千机器，每一个机器又划分为N个范围，致使须要维护的数据分布范围元数据过大，致使可能须要几台机器实现。
必定要严格控制元数据量，进可能的减小元数据的存储。
3． 按数据量分布，另外一类经常使用的数据分布方式则是按照数据量分布数据。与哈希方式和按数据范围方式不一样，数据量分布数据与具体的数据特征无关，而是将数据视为一个顺序增加的文件，并将这个文件按照某一较为固定的大小划分为若干数据块（chunk），不一样的数据块分布到不一样的服务器上。与按数据范围分布数据的方式相似的是，按数据量分布数据也须要记录数据块的具体分布状况，并将该分布信息做为元数据使用元数据服务器管理。
因为与具体的数据内容无关，按数据量分布数据的方式通常没有数据倾斜的问题，数据老是被均匀切分并分布到集群中。当集群须要从新负载均衡时，只需经过迁移数据块便可完成。集群扩容也没有太大的限制，只需将部分数据库迁移到新加入的机器上便可以完成扩容。按数据量划分数据的缺点是须要管理较为复杂的元信息，与按范围分布数据的方式相似，当集群规模较大时，元信息的数据量也变得很大，高效的管理元信息成为新的课题。
4． 一致性哈希，构造哈希环，有哈希域[0,10]，则构造3个部分，[1,4)/[4,9)/[9,10),[0,1)/分红了3个部分，这3部分是一个环状，增长机器时，变更的是其附近的节点，分担的是附近节点的压力，其元数据的维护和按数据量分布同样。其将来的扩展，能够实现多个需节点。
5． 构建映射元数据，创建映射表的方式。
6． 副本与数据分布，把一个数据副本分散到多台服务器上。好比应用A的数据，存储在A、B、C ，3台机器上，若是3台机器中，其中一台出现问题，请求被处理到其余2台机器上，若是加机器恢复，还须要从另外2台机器上，Copy数据，又增长了这2台机器的负担。若是咱们有应用A和应用B，各自有3台机器，那么咱们能够把A应用分散在6台机器上，B应用也分散在6台机器上，能够实现相同的数据备份，可是应用存储的数据被分散了。某台机器损害，只是把该机器所承担的负载平均分配到了，另外5台机器上。恢复数据从5台机器恢复，其速度快和给各台服务器的压力都不大，并且能够实现机器损害，更换彻底不影响应用。
其原理是多个机器互为副本，是比较理想的实现负载分压的方式。
7． 分布式计算思想，移动数据不如移动计算，就进计算原则，减小跨进程、跨网络、等跨度较大的实现，把计算所需的资源尽量的靠近。由于可能出现网络、远程机器的瓶颈。
8． 常见分布式系统数据分布方式: GFS、HDFS:按数据量分布；Map reduce 按GFS的数据分布作本地化；BigTable、HBase按数据范围分布；Pnuts按哈希方式或者数据范围分布，能够选择；Dynamo、Cassndra按一致性哈希；Mola、Armor、BigPipe按哈希方式分布；Doris按哈希方式和按数据量分布组合。
3、数据副本协议
1． 副本必定要知足必定的可用性和一致性要求、具体容错能力，即便出现一些问题也能提供可靠服务。
2． 数据副本的基本协议，中心化和去中心化2种基本的副本控制协议。
3． 中心化副本控制协议的基本思路是由一个中心节点协调副本数据的更新、维护副本之间的一致性。中心化副本控制协议的优势是协议相对较为简单，全部的副本相关的控制交由中心节点完成。并发控制将由中心节点完成，从而使得一个分布式并发控制问题，简化为一个单机并发控制问题。控制问题，简化为一个单机并发控制问题。所谓并发控制，即多个节点同时须要修改副本数据时，须要解决“写写”、“读写”等并发冲突。单机系统上经常使用加锁等方式进行并发控制。对于分布式并发控制，加锁也是一个经常使用的方法，但若是没有中心节点统一进行锁管理，就须要彻底分布式化的锁系统，会使得协议很是复杂。中心化副本控制协议的缺点是系统的可用性依赖于中心化节点，当中心节点异常或与中心节点通讯中断时，系统将失去某些服务（一般至少失去更新服务），因此中心化副本控制协议的缺点正是存在必定的停服务时间。即存在单点问题，即便中心化节点是一个集群，也只不过是一个大的单点。
4． 副本数据同步常见问题，1）网络异常，致使副本没有获得数据；2）数据脏读，主节点数据已经更新，可是因为某种缘由，没有获得最新数据；3）增长新节点没有获得主节点数据，而读数据时重新节点读数据致使，没有获得数据。
5． 去中心化副本控制协议没有中心节点，协议中全部的节点都是彻底对等的，节点之间经过平等协商达到一致。从而去中心化协议没有由于中心化节点异常而带来的停服务等问题。然而，没有什么事情是完美的，去中心化协议的最大的缺点是协议过程一般比较复杂。尤为当去中心化协议须要实现强一致性时，协议流程变得复杂且不容易理解。因为流程的复杂，去中心化协议的效率和性能较低。
6． Paxos是惟一在工程中获得应用的强一致性去中心化副本控制协议。ZooKeeper、Chubby，就是该协议的应用。
Zookeeper用Paxos协议选择Leader，用Lease协议控制数据是否有效。用Quorum协议把Leader的数据同步到follow。
Zeekeeper，实现Quorum写入时，若是没有彻底写入成功，则全部的follow机器，反向向Leader写数据，写入数据后follow又向Leader同步数据，保持一致，若是是失败的数据先写入，大家follow同步到原来的数据，相对于回滚；如是是最新的数据先写入Leader则就是完成了最新数据的更新。
7． Megastore，使用的是改进型行Paxos协议。
8． Dynamo / Cassandra使用基于一致性哈希的去中心化协议。Dynamo使用Quorum机制来管理副本。
9． Lease机制是最重要的分布式协议，普遍应用于各类实际的分布式系统中。1）Lease一般定义为：颁发者在必定期限内給予持有者必定权利的协议。2）Lease 表达了颁发者在必定期限内的承诺，只要未过时颁发者必须严格遵照 lease 约定的承诺；3）Lease 的持有者在期限内使用颁发者的承诺，但 lease 一旦过时必须放弃使用或者从新和颁发者续约。4）的影响。中心服务器发出的lease的含义为：在lease的有效期内，中心服务器保证不会修改对应数据的值。5）能够经过版本号、过多上时间、或者到某个固定时间点认为Lease证书失效。
其原理和咱们的Cache同样，好比浏览器缓存道理一致。其要求时间时钟同步，由于数据彻底依赖于期限。
10． 心跳（heartbeat）检测不可靠,假如检测及其Q，被检测机器A，可能因为Q发起检测，可是A的回应被阻塞，致使Q 认为A宕机，阻塞很快恢复，致使根据心跳检测来作判断不可靠；也多是他们之间的网络断开；也多是Q机器自己异常致使认为A机器宕机；若是根据Q的检测结果，来判断极可能出现多个主机的状况。
11． Write-all-read-one（简称WARO）是一种最简单的副本控制规则，顾名思义即在更新时写全部的副本，只有在全部的副本上更新成功，才认为更新成功，从而保证全部的副本一致，这样在读取数据时能够读任一副本上的数据。写多份，读从其中一份读取。
12． quorum协议，其实就是读取成功的副本数大于失败的副本数，大家读取的副本里面必定包含了最新的副本。
13． Mola*和Armor*系统中全部的副本管理都是基于Quorum，即数据在多数副本上更新成功则认为成功。
14． Big Pipe*中的副本管理也是采用了WARO机制。
4、日志技术
1． 日志技术是宕机恢复的主要技术之一。日志技术最初使用在数据库系统中。严格来讲日志技术不是一种分布式系统的技术，但在分布式系统的实践中，却普遍使用了日志技术作宕机恢复，甚至如BigTable等系统将日志保存到一个分布式系统中进一步加强了系统容错能力。
2． 两种比较实用的日志技术Redo Log与No Redo/No undo Log。
3． 数据库的日志主要分为Undo Log、Redo Log、Redo/Undo Log与No Redo/No Undo Log。这四类日志的区别在更新日志文件和数据文件的时间点要求不一样，从而形成性能和效率也不相同。
4． 本节介绍另外一种特殊的日志技术“No Undo/No Redo log”，这种技术也称之为“0/1目录”(0/1 directory)。还有一个主记录，记录当前工做目录，好比老数据在0目录下，新数据在1目录下，咱们访问数据时，经过主纪录，记录当前是工做在那个目录下，若是是工做在目录0下，取目录0数据，反之取1目录数据。
5． MySQL的主从库设计也是基于日志。从库只需经过回放主库的日志，就能够实现与主库的同步。因为从库同步的速度与主库更新的速度没有强约束，这种方式只能实现最终一致性。
6． 在单机上，事务靠日志技术或MVCC等技术实现。
7． 两阶段提交的思路比较简单，在第一阶段，协调者询问全部的参与者是否能够提交事务（请参与者投票），全部参与者向协调者投票。在第二阶段，协调者根据全部参与者的投票结果作出是否事务能够全局提交的决定，并通知全部的参与者执行该决定。在一个两阶段提交流程中，参与者不能改变本身的投票结果。两阶段提交协议的能够全局提交的前提是全部的参与者都赞成提交事务，只要有一个参与者投票选择放弃(abort)事务，则事务必须被放弃。能够这么认为，两阶段提交协议对于这种超时的相关异常也没有很好的容错机制，整个流程只能阻塞在这里，且对于参与者而言流程状态处于未知，参与者即不能提交本地节点上的事务，也不能放弃本地节点事务。
8． 第1、两阶段提交协议的容错能力较差。
9． 第2、两阶段提交协议的性能较差。一次成功的两阶段提交协议流程中，协调者与每一个参与者之间至少须要两轮交互4个消息“prepare”、“vote-commit”、“global-commit”、“确认global-commit”。过多的交互次数会下降性能。另外一方面，协调者须要等待全部的参与者的投票结果，一旦存在较慢的参与者，会影响全局流程执行速度。
10． 顾名思义，MVCC即多个不一样版本的数据实现并发控制的技术，其基本思想是为每次事务生成一个新版本的数据，在读数据时选择不一样版本的数据便可以实现对事务结果的完整性读取。在使用MVCC时，每一个事务都是基于一个已生效的基础版本进行更新，事务能够并行进行。其思想是根据版本号，在多个节点取同一个版本号的数据。
11． MVCC的流程过程很是相似于SVN等版本控制系统的流程，或者说SVN等版本控制系统就是使用的MVCC思想。
5、CAP理论
14 CAP理论的定义很简单，CAP三个字母分别表明了分布式系统中三个相互矛盾的属性：1）Consistency (一致性)：CAP理论中的副本一致性特指强一致性（1.3.4 ）；
2）Availiablity(可用性)：指系统在出现异常时已经能够提供服务；
3）Toleranceto the partition of network (分区容忍)：指系统能够对网络分区，这
种异常状况进行容错处理。
2.CAP理论指出：没法设计一种分布式协议，使得同时彻底具有CAP三个属性，即1)该种协议下的副本始终是强一致性，2)服务始终是可用的，3)协议能够容忍任何网络分区异常；分布式系统协议只能在CAP这三者间全部折中。