大型分布式系统理论体系.doc

大型分布式目录高可用性 异常问题 副本 衡量分布式系统的指标 数据分布方式-如何将问题拆解成可以使用多台机器分布式解决 副本与数据分布 副本控制协议 Lease机制 Quorum机制一种简单有效的副本管理机制 日志技术 两阶段提交协议 基于MVCC的分布式事务 Paxos协议 CAP理论 最近尝试接触一些分布式领域相关的知识，以前在学校的时候想当然地认为把程序写好了能跑其它就都不用管了，进了企业才发现根本就不是那回事儿。比如在没有接触服务器之前都是在自己的笔记本上面搭建各种环境，开发、测试、部署都是在笔记本上，运行下觉得逻辑没问题就觉得完事了，但进了企业后经常会碰到些莫名其妙的问题，比如服务器一下子可能就支撑不住了，渐渐地意识到单机的不可靠。现在有同事专门在负责集群这块，自己觉得有必要了解下这方面的知识。刚入门也不知道学什么好，看到些什么就学什么，觉得有必要总结些东西下来，要不这种学法效果会相当糟糕。也欢迎大家推荐些不错的资源或书籍~ 高可用性 英文叫high availability，简称HA。wiki 高可用的定义是Ao = up time / total time，up time = (total_time - down time)， 即Ao = (total_time ?- down_time) / total_time，简单理解就是服务可用的时间占比。 但可用性和up time的含义还不太一样，系统在正常运行时也可能造成不可用的情况，如出现网络故障。 高可用的三个基本原则： 1）减少单点故障，当一个系统或组建出现问题时不会影响到整个系统的正常服务，大体可以理解为系统容错性； 2）可靠的迁移？（reliable crossover）不知道crossover是什么含义，我的理解是业务迁移，即当某个节点不可用时，业务可以平滑地迁移到其他节点； 3）错误检测，当系统出错时能及时发现错误，这其实是运维工作的一部分。 可用性一般用百分比来描述，比如3个9（表示可用性为99.9%）、5个9（99.999%），依次类推~ 高可用系统设计推崇简单设计原则，当一个系统设计地较为复杂时，出错的可能性相对更高。 业界对于高可用问题一般采用冗余的方式来解决，如为提高数据服务高可用，通常会多复制几份数据做备份，当数据服务不可用时能及时切换到备用数据，即节点的failover。 异常问题 分布式系统核心问题之一就是处理各种异常情况，常见的异常情况有以下三种： 1）机器宕机，在大型集群中每日宕机发生的概率为千分之一左右； 2）网络异常（消息丢失、消息乱序、数据错误、不可靠的TCP）； 3）存储数据丢失，节点存储的数据不可被读取或读取出的数据错误。 副本 副本（replica/copy）指在分布式系统中为数据或服务提供的冗余，分为数据副本和服务副本。 对于数据副本指在不同的节点上持久化同一份数据，但出现某一个节点存储的数据丢失时，可以从副本上读到数据。数据副本是分布式系统解决数据丢失异常的唯一手段。 服务副本指数个节点提供某种相同的服务。 副本一致性：分布式系统通过副本控制协议，使得从系统外部读取系统内部各个副本的数据在一定的约束条件下相同。 常见的副本一致性级别： 1）强一致性（strong consistency）：任何时刻任何用户或节点都可以读到最近一次成功更新的副本数据； 2）单调一致性（monotonic consistency）：任何时刻任何用户一旦读到某个数据在某次更新后的值，这个用户不会再读到比这个值更旧的值； 3）会话一致性（session consistency）：任何用户在某一次会话内一旦读到某个数据在某次更新后的值，这个用户在这次会话过程中不会再读到比这个值更旧的值； 4）最终一致性（eventual consistency）：最终一致性要求一旦更新成功，各个副本上的数据最终将达到完全一致的状态，但达到完全一致的状态所需要的时间不能保证； 5）弱一致性（weak consistency）：一旦某个更新成功，用户无法在一个确定时间内读到这次更新的值，且即使在某个副本上读到了新的值，也不能保证在其他副本上可以读到新的值。 衡量分布式系统的指标 1）性能：系统的吞吐能力（在某一时间可以处理的数据总量）、响应延迟（完成某一功能所需要时间）、并发能力（可以同时完成某一功能的能力）； 2）可用性，衡量了系统的容错性，是系统容错能力的体现； 3）可扩展性：通过扩展集群机器规模提高系统性能（吞吐、延迟、并发）、存储容量、计算能力的特征； 4）一致性：使用副本会引发副本一致性的问题 数据分布方式-如何将问题拆解成可以使用多台机器分布式解决 哈希方式：按照数据某一特征计算哈希值，并将哈希值与机器进行映射，从而达到将不