技术本无好坏，在于适当的使用和积累。框架没有固定模式，主要是根据具体业务去设计最适合的框架。
"分布式"基本思想总结
1.系统拆分
大系统小做“。对于一个大的复杂系统，首先想到的就是对其分拆，拆成多个子系统。每个子系统自己的存储/Service/接口层，各个子系统独立开发、测试、部署、运维。从团队管理角度讲，也可以不同团队用自己熟悉的语言体系，团队之间基于接口进行协作，职责清晰，各司其职。
2.子系统拆分
拆成子系统之后，子系统内部又可以分层，分模块。当然，这里“系统“，“子系统“，“层“，“模块“ 都只是一个相对概念。在一个系统里面，某个模块复杂到一定程度，会把它抽出来，单独做成一个系统；而在初期，很大但是简单模块，可能不回拆分，集中在一个系统里面。这就像一个生物组织，自身是在不断成长、演化、有分有合，不断变化发展的。
3.存储拆分
Nosql：对于Nosql数据库，比如MongoDB，其天生就是分布式的，很容易实现数据的分片。
Mysql: 对于Mysql，或者其它关系型数据库，就会设计到分库分表。而分库分表，就会涉及到几个关键性的问题：切分维度，join的处理，分布式事务。不过关系型数据库也有分布式的版本，比如mysqlcluster、mycat、Oracle RAC等。
4.计算拆分
计算拆分分为两种：一是数据拆分：一个大的数据集，拆分成多个小的数据集，并行计算。比如大规模数据归并排序。归并排序：将已有序的子序列合并，得到完全有序的序列；即先使每个子序列有序，再使子序列段间有序。
二是任务拆分：把一个长的任务，拆分成几个环节，各个环节并行计算。Java中多线程的Fork/Join框架，Hadoop中的Map/Reduce，都是计算分拆的典型框架。其思路都是相似的，先分拆计算，再合并结果。分布式的搜索引擎中，数据分拆，分别建索引，查询结果再合并。
5.并发
最常见的就是多线程，尽可能提高程序的并发度。比如多次rpc顺序调用，通过异步rpc转化为并发调用；比如数据分片，你的一个Job要扫描全表，跑几个小时，数据分片，用多线程，性能会加快好几倍。
6.缓存
缓存大家都不陌生，遇到性能问题，大家首先想到的就是缓存。关于缓存，一个关键点就是：缓存的粒度问题。
比如Tweet的架构，缓存的粒度从小到大，有Row Cache, Vector Cache, Fragment Cache, Page Cache。粒度越小，重用性越好，但查询需要多次，需要数据拼装；粒度越大，越容易会失效，任何一个小的地方改动，都可能造成缓存的失效。
7.在线计算 vs. 离线计算 / 同步 vs. 异步
在实际的业务需求中，并不是所有需要都需要完全实时的：比如内部针对产品、运营开发的各种报表查询、分析系统；比如微博的传播，我发了一个微博，我的粉丝延迟几秒才看到，这是可以接受的，因为他并不会注意到晚了几秒；比如搜索引擎的索引，我发了一篇博客，可能几分钟之后，才会被搜索引擎索引到；比如支付宝转帐、提现，也并非这边转出之后，对方立即收到；这类例子很多。这种“非实时也可以接受“的场景，就为架构的设计赢得了充分的回旋余地。因为非实时，我们就可以做异步，比如使用消息队列，比如使用后台的Job，周期性处理某类任务；也因为非实时，我们可以做读写分离，读和写不是完全同步，比如Mysql的Master-Slave。同步的思想是：所有的操作都做完，才返回给用户。异步，不用等所有操作等做完，就相应用户请求。即先相应用户请求，然后慢慢去写数据库，用户体验较好。
8.全量 ＋ 增量
全量/增量其实也是在线/离线的思路：比如搜索引擎的全量索引 ＋ 增量索引，前者是为了吞吐，后者为了实时；比如OceanBase数据库，每次更新存在一个小表里面，定期merge；
9.Push vs. Pull
在所有分布式系统中，都涉及到一个基本问题：节点之间（或者2个子系统之间）的状态通知。比如一个节点状态变更了，要通知另外一个节点，都有2种策略：Push: 节点A状态变了， push给节点B。Pull: 也就是轮询。节点B周期性的去询问节点A的状态。这个问题不光出现在分布式系统中，可以说是编写代码的一个基本问题。对应到面向对象的编程中，也就是常说的“双向关联”这种耦合问题。A调用B，B再回调A，这种情形，在系统开发中经常出现。再复杂一点，多个模块之间，彼此调用，调用关系跟蜘蛛网一样。这种蜘蛛网一样的互相调用就是毫无疑问的紧耦合。这个问题的出现，就和Push/Pull的策略密切相关：A调用B，那逻辑就会写在B这边；B调用A，逻辑就会写在A这边。所以是采用主动调用的pull方式，还是回调的push方式，会严重影响职责在各个模块或者子系统里面的分配。
10.批量
批量其实也是在线/离线的一种思想，把实时问题，转化为一个批量处理的问题，从而降低对系统吞吐量的压力比如Kafka中的批量发消息；比如广告扣费系统中，把多次点击累积在一起扣费；
11.重写轻读 vs 重读轻写
重写轻读，本质就是“空间换时间“。如果计算起来耗时，延迟高，那我们可以提前计算，然后存起来。需要取的时候，直接去取。我们通常对Mysql的用法，都是重读轻写，写的时候，简单；查的时候，做复杂的join计算，返回结果。这样做的好处是容易做到数据的强一致性，不会因为字段冗余，造成数据的不一致。但是性能可能就是问题。而微博的Feeds架构，就是典型的重写轻读。我要去看Feeds，按通常的mysql的做法，我要先去查我关注的所有的人，然后把所有人的消息排序，分页返回。很显然，在大数据量下，这个会很耗时。而如果采用重写轻读，那就为每个人准备一个Feeds，或者说收件箱。某个人发了微博之后，把他的微博扩散到所有人的收件箱，这个扩散是异步的，在后台扩散。这样每个人看自己的Feeds的时候，直接去自己的收件箱取就可以了。
12.读写分离
对传统的单机Mysql数据库，读和写是完全同步的。写进去的内容，立马就可以读到。并且具有一致性。但在很多业务场景下，读和写并不需要完全同步。这个时候，就可以分开存储，写到一个地方，再异步的同步到另一个地方。这样就可以实现读写分离。比如Mysql的Master/Slave就是个典型，Slave上面的数据并不是和Master实时同步的；Slave只Mysql做分布式布置时候的从服务器，Master只Mysql做分布式布置时候的主服务器。详细搜寻关键字（mysql的Master/Slave）再比如各种报表分析，OLTP/OLAP，线上/线下数据分离，线上数据定期同步到Hive集群，再做分析。
词语解释：
OLTP（online transaction processing,在线事务处理）是一类程序，它们简化和管理面向事务的应用，典型的是在大机构中输入和获取数据的事务，应用于银行，机场，超市。IBM的 CICS（客户信息控制系统）可能是使用最规范的OLTP产品。最新的在线事务处理需要支持几个公司的跨网络的事务。基于这个原因，新的OLTP软件使用 客户-服务器模型，事务能在网络中不同平台的计算机上被处理。联机事务处理(OLTP)利用计算机网络，将分布于不同地理位置的业务处理计算机设备或网络与业务管理中心网络连接，以便于在任何一个网络节点上都可以进行统一、实时的业务处理活动或客户服务。工业部门一般将OLTP系统定义为表示一个特定企业机能在一个特定时间点的状态的系统。该类型的系统包括从每分钟处理1到2件事务的小型单机系统一直到每秒钟处理超过30000件事务的大规模群集主机系统。OLTP系统是数据库处理的传统的主要部分。一个联机事务处理数据库典型的特点是，拥有大量的并发用户，这些用户积极地完成实时修改数据的任务。（时序数据库）
OLAP (online analytical processing)在线分析处理，OLAP是利用一种称为多维数据库的技术使用户以不同的角度看取得的数据。这里的关键就是这个多维数据库，多维数据库与我们传统所知的关系数据库不同的地方在于，它不是二维的，关系数据库中规定的表我们可以把它看成是二维的，而这种多维数据库却把数据组织成多维的，OLAP数据库的大小比数据仓库的要小。它可用于数据挖掘等方面，它与传统的关系数据库数据之间是可以互操作的，通过ODBC可以将传统数据库中的数据导入OLAP数据库。
13.动静分离
动静分离的典型例子就是网站的前端，动态的页面，放在web服务器上；静态的css/jss/img，直接放到CDN上，这样既提高性能，也极大的降低服务器压力。按照这个思路，很多大型网站都致力于动态内容的静态化，静态化之后，就可以很容易的缓存。
14.冷热分离
比如定期把mysql中的历史数据，同步到hive。
15.限流
现在很多电商都会有秒杀活动，秒杀的一个特点就是商品很少，但短时间内流量暴增，服务器完全处理不了这么多请求。应对这类问题的一个基本思路就是限流，既然处理不了那么多请求，既然很大多人进去了，也是抢不到的。那索性不要放那么多人进去。这个和我们日常生活中，节假日，某个景点人数过多，限制人流量是同样的道理。
16.服务熔断与降级
服务降级是系统的最后一道保险。在一个复杂系统内部，一个系统往往会调用其它很大系统的服务。在大流量的情况下，我们可能会在保证主流程能正常工作的情况下，对其它服务做降级。所谓降级，也就是当某个服务不可用时，干脆就别让其提供服务了，直接返回一个缺省的结果。虽然这个服务不可用，但它不至于让整个主流程瘫痪，这就可以最大限度的保证核心系统可用。
CAP
Consistency：数据一致性，这个很容易理解，就是没有脏数据。我们知道，在Mysql中有一致性的概念，比如参照完整性约束、事务等。但这里的C主要特指同1份数据的多个备份之间的一致性。
Availability：可用性有2重意思，一个是说稳定性，服务可用，不会挂；另外一个是性能，也就是要快，如果延迟很高，经常超时，那和挂了也就区别不大了。
Partition tolerance(分区容错性)：分区，其实指网络分区。当你把数据从1个物理设备，分到多个物理设备之后，设备之间必然是通过网络进行通信。这就会遇到网络分区，也就是典型的“2将军问题“，网络超时时间不定。学术上有个词，叫“异步通信环境“。
总结：对于一个分布式系统，上面3个，只能同时满足2个。但这个其实不准确，P其实一定存在，是你避免不了的。能做的，其实主要是在C和A之间权衡。比如Mysql它的C最强，A次之，P最弱。如果你为了A，给数据做冗余，比如重写轻读，那C就很难保证；为了P，给数据做分库分表，那就做不了事务；比如Nosql，P最强，可以很好的做数据拆分，但C就不够，做不了事务；比如微博系统，对C的要求降低，就可以加很多缓存，提高A；数据分片，提高P；而支付，交易转帐，对C的要求很高，就不能简单的用Cache来提高性能。
CAP定理：CAP永远不可能同时满足，最多只能同时满足两个，提高其中任意两者的同时，必然要牺牲第三者；在某时刻如果满足AP，分隔的节点同时对外服务但不能相互通信，将导致状态不一致，即不能满足C；如果满足CP，网络分区的情况下为达成C，请求只能一直等待，即不满足A；如果要满足CA，在一定时间内要达到节点状态一致，要求不能出现网络分区，则不能满足P。此三者有点像中国的太极阴阳鱼原理，既相辅相成又相互制约。
1.一致性（Consistency）
如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency) (又叫原子性 atomic、线性一致性 linearizable consistency)说白了就是要种什么因就得什么样的果，如果你种个苹果种子，长出来个西瓜，这就是失去一致性，也就是违反原子性。因为分布式系统比传统的系统更容易导致不一致的现象，要做到这一点要在一致性、复杂度和效率方面做均衡考虑目前一般都是牺牲部分一致性换取更多的可用性。
2.可用性（Availiability）
首先了解高可用性H.A.（High Availability），通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。高可用分为：
①网络高可用：通过匹配冗余的网络设备实现网络设备的冗余，达到高可用的目的。比如冗余的交换机，冗余的路由器等。
②服务器高可用：主要使用的是服务器集群软件或高可用软件来实现。
③存储高可用：主要技术指标是存储切换功能，数据复制功能，数据快照功能等。当一台存储出现故障时，另一台备用的存储可以快速切换，达到存储不停机的目的。
高可用性简单表达=稳定性+抗容灾能力，假设一个节点挂，另一个备份节点要顶上。
服务可用性：所有读写请求在一定时间内得到响应，可终止、不会一直等待。
总结就是要让系统保持运转，尽可能的减少不可用的时间。
3.分区容错性:容忍性（Partition Tolerance）
在网络分区的情况下，被分隔的节点仍能正常对外服务所有处理用户请求的服务器端系统都有可用性的要求。容错设计可以带来高可用性。分布式系统中涉及大量设备，无论是磁盘还是路由，从概率学的角度，随着系统规模增大，部分失败不可以忽略不计。容错设计可以降低大量的维护成本。对于Hadoop这类系统，其设计目标为对超大规模数据集进行长时间的批处理。由于数据规模大，只能采用规模较大的分布式系统方案。而这类系统的批处理计算执行时间很长，如无容错，一个作业甚至可能永远无法完成。网络分区的情况符合该定义，网络丢包的情况也符合以上定义，另外节点宕机，其他节点发往宕机节点的包也将丢失，这种情况同样符合定义。现实情况下我们面对的是一个不可靠的网络、有一定概率宕机的设备，这两个因素都会导致Partition，因而分布式系统实现中P是一个必须项，而不是可选项。P 是必选项，那3选2的选择题不就变成数据一致性(consistency)、服务可用性(availability) 2选1？工程实践中一致性有不同程度，可用性也有不同等级，在保证分区容错性的前提下，放宽约束后可以兼顾一致性和可用性，两者不是非此即彼。分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。
一致性
序列一致性(sequential consistency)：不要求时序一致，A操作先于B操作，在B操作后如果所有调用端读操作得到A操作的结果，满足序列一致性。
最终一致性(eventual consistency)：放宽对时间的要求，在被调完成操作响应后的某个时间点，被调多个节点的数据最终达成一致。
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。但是支付宝系统，就要求数据（银行账户）的强一致性，而且面对大量淘宝用户，可用性要求很高，因此只能牺牲数据的分区冗余。
故障转移和负载均衡
集群系统中来自客户的请求可以进行平均分配. 把相应的进程分发给与之共同承担任务的服务器，从而不影响应用进程的运行,大多数中间件都支持负载均衡，实现负载均衡大大降低了系统的崩溃现象，从而减少对企业带来的损失。
故障转移：软硬件出现故障，能够有其它相关的软硬件设备来承接相关的工作任务，以保障系统正常工作。（数据库单独建在一个服务器上，然后处理建立AB两个服务器处理相同的业务，当一个服务器宕机了，另一个还能工作）
注意点
处理结果的一致性：协调各部分之间的并行处理，确保最终处理结果的一致性。
通信障碍：应对跨网络访问过程中可能存在的信息丢失和通讯延迟，确保信息系统服务水平。
系统整体可靠性优化：确保在单个节点异常情况下系统正确切换与恢复，确保系统整体可靠性。
数据最终一致性：由于其数据分开存放，不同功能并行处理，为了确保系统整体可靠性，往往采用“数据最终一致性”的原则进行设计，需在产品功能设计层面同步予以考虑。
串行、并行
指的是任务的执行方式。串行是指多个任务时，各个任务按顺序执行，完成一个之后才能进行下一个。并行指的是多个任务可以同时执行。异步是多个任务并行的前提条件。
同步、异步
同步就是指一个进程在执行某个请求的时候，若该请求需要一段时间才能返回信息，那么这个进程将会一直等待下去，直到收到返回信息才继续执行下去；异步是指进程不需要一直等下去，而是继续执行下面的操作，不管其他进程的状态。当有消息返回时系统会通知进程进行处理，这样可以提高执行的效率。系统的并发用户增加1万（customer ten thousand，过去一台服务器承载假设为1万用户，现在平均3～5万），是否意味着增加一台机器就能解决问题？答案通常是否定，因为这涉及到系统的应用架构问题----串行系统和并行系统的架构和性能提升的关系：串行系统一般设备越多，性能成一条向下弯曲的曲线，最差情况，可能性能不增反降；而并行分布式系统设备越多，性能是正比例线性增长的直线。
串行系统、并行系统可靠性问题
一个大系统一般都有超过 30 个环节（串行）：如果每个环节都做到 99% 的准确率，最终系统的准确率是 74%;如果每个环节都做到98%的准确率，最终系统的准确率 54%。一个 74% 的系统是可用的（有商业价值的），一个 54% 的系统仅比随机稍好一点，不可用。这就是做大系统的魅力和挑战！而以上描述只是各模块串行系统所遇到的问题。
如果是并行系统，准确率=1-(1-A)^B ，其中A是单个模块准确率，B是并行模块个数如系统中每个模块的准确率是70%，那么3个模块并行，整体准确率=1-0.3^3=97.3%,如果是4个并行，准确率=1-0.3^4=99.19%。5个9或6个9的QoS一定是指数思维的结果，线性思维等于送死。
而对系统单一模块优化，准确性和可用性提升一个百分点，越接近100%，难度越大，投入成本越不可控因此可靠性系统必然选择并行分布式作为架构的基本方法。从数据的存储角度，多份冗余也是可靠性保障的一个方法。分布式存储的冗余备份常规是3份（亚马逊aws就这么干的），古埃及的罗塞塔rosetta石碑用古埃及象形文字、埃及拼音和古希腊文三种文字记录一段历史，就算象形文字缺了一部分，没人能看懂，也能破译补全，这大概也是raid5的思想起源吧。
数据磁盘存储方式（故障转移的一种），raid磁盘冗余阵列
Standalone（独立）
最普遍的单磁盘储存方式。
Cluster（集群）
集群储存是通过将数据分布到集群中各节点的存储方式,提供单一的使用接口与界面,使用户可以方便地对所有数据进行统一使用与管理。
Hot swap（热调换）
用户可以再不关闭系统,不切断电源的情况下取出和更换硬盘,提高系统的恢复能力、拓展性和灵活性。
Raid0
Raid0是所有raid中存储性能最强的阵列形式。其工作原理就是在多个磁盘上分散存取连续的数据,这样,当需要存取数据是多个磁盘可以并排执行,每个磁盘执行属于它自己的那部分数据请求,显著提高磁盘整体存取性能。但是不具备容错能力,适用于低成本、低可靠性的台式系统。
Raid1
又称镜像盘,把一个磁盘的数据镜像到另一个磁盘上,采用镜像容错来提高可靠性,具有raid中最高的数据冗余能力。存数据时会将数据同时写入镜像盘内,读取数据则只从工作盘读出。发生故障时,系统将从镜像盘读取数据,然后再恢复工作盘正确数据。这种阵列方式可靠性极高,但是其容量会减去一半。广泛用于数据要求极严的应用场合,如商业金融、档案管理等领域。只允许一颗硬盘出故障。
Raid0+1
将Raid0和Raid1技术结合在一起,兼顾两者的优势。在数据得到保障的同时,还能提供较强的存储性能。不过至少要求4个或以上的硬盘,也只运行一个磁盘出错。是一种高成本、高可靠性、高存储性能的三高阵列技术。
Raid5
Raid5可以看成是Raid0+1的低成本方案。采用循环偶校验独立存取的阵列方式。将数据和相对应的奇偶校验信息分布存储到组成RAID5的各个磁盘上。当其中一个磁盘数据发生损坏后,利用剩下的磁盘和相应的奇偶校验信息 重新恢复/生成丢失的数据而不影响数据的可用性。至少需要3个或以上的硬盘。适用于大数据量的操作。成本稍高、储存新强、可靠性强的阵列方式。如果Raid5有5块服务器硬盘，那么一般会将3个硬盘作为业务数据存储硬盘，当插入数据时，向三块硬盘平均写入数据。另两块硬盘一块做热备份(实时备份数据可以不用永久存储)，一块为冷备份(类似数据永久存储)
分布式存储架构
1.物理存储采用集中式，存储节点采用多实例的方式，如NFS挂载SAN、NAS等等
NAS：（Network Attached Storage：网络附属存储）按字面简单说就是连接在网络上，具备资料存储功能的装置，因此也称为“网络存储器”。它是一种专用数据存储服务器。它以数据为中心，将存储设备与服务器彻底分离，集中管理数据，从而释放带宽、提高性能、降低总拥有成本、保护投资。其成本远远低于使用服务器存储，而效率却远远高于后者。
2.带有中央控制器的分布式存储
如luster、moosefs、googlefs等等，一般特征是具备2个角色metadata server和storage node，将文件的元数据（描述数据的数据，如文件位置、大小等等）和数据块文件分开存储，其中metadata server除保存文件的元数据外，还维护存储节点的ip、状态等信息。metadata server：元数据服务storage node：存储节点
cluster的典型架构：
MDS--meatadata server
MDT--metadata target
OSS--obj storage server
OST--obj starage target
其中MDT和OST是可以挂在NAS等中央存储上的；可见，luster借鉴了上面中央存储的模式，无论元数据服务还是节点服务都将服务实例和存储分离，但进化了一步，将元数据和数据块分离。luster系统很好解决了数据分布式存储，在超级计算领域Lustre应用广泛，如美国LLNL国家实验室计算机系统、我国的天河超级计算机系统均采用Lustre搭建分布式存储系统。Lustre在全球排名前30个超级计算机系统中有15个在使用。但有一个问题，就是metadata server的SPoF（single point of failure）问题，即单点故障；一旦metadata server挂了，整个集群也就挂了。实际应用中，是有解决方案的，如dell的官网有个pdf，就是采用heart beat和drbd网络raid的方式，启动2个实例，再如和keepalived一起组成故障转移的方案等等。
moosefs：是一种分布式文件系统，包括以下四种角色：
①管理服务器managing server (master)负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复.多节点拷贝。
②元数据日志服务器Metalogger server（Metalogger）负责备份master服务器的变化日志文件，文件类型为changelog_ml.*.mfs以便于在master server出问题的时候接替其进行工作。
③数据存储服务器data servers (chunkservers)负责连接管理服务器,听从管理服务器调度,提供存储空间，并为客户提供数据传输。
④客户机挂载使用client computers通过fuse内核接口挂接远程管理服务器上所管理的数据存储服务器看起来共享的文件系统和本地unix文件系统使用一样的效果。moosefs架构和luster很相似，但进化了一步，mater（也就是metadata server）可以有从机备份了，而且可以多个而且服务实例和存储放在一起，没有像luster，自此服务和数据不离不弃了；其实luster也可以简化成不离不弃模式，moosefs也可以学他搞个后端存储，但随着云计算、追求低成本的趋势，采用NAS这样存储设备就太贵了。
googleFs：简称GFS
是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，可以提供容错功能。它可以给大量的用户提供总体性能较高的服务。
3.存储是去中心化、全对称的架构（non-center or symmetric）
设计思想是采用一致性哈希consistent hash算法（DHT的一种实现，关于一致性hash具体参考后面的链接）来定位文件在存储节点中的位置，从而取消了metadata server的角色。整个系统只有storage node一个角色，不区分元数据和数据块；典型系统如sheepdog，但sheepdog是为满足kvm镜像和类EBS块存储而设计的，不是常规的分布式文件系统，架构如下：
EBS（Elastic Block Store弹性块存储）
是弹性块存储快照恢复为管理员节省了时间，让他们可以专注在其他的增值任务上，比如研发任务。在将一个弹性块存储（EBS）保存到简单存储服务（S3）后，管理员可以通过自动化来进一步简化流程。如果你需要恢复一个EBS快照的话，只需要几个鼠标点击就可以做到。KVM：就是Keyboard Video Mouse的缩写。KVM交换机通过直接连接键盘、视频和鼠标 (KVM) 端口让您能够访问和控制计算机。为了维护存储节点的信息，一般采用P2P技术的totem single ring算法（corosync是一种实现）来维护和更新node路由信息对称架构有一个问题，采用totem single ring算法的存储节点数量有限，因为node数量超过1000，集群内的通信风暴就会产生（此处更正，应该是环太大，令牌传递效率下降，不会产生通信风暴），效率下降，sheepdog提出了一个解决方案，就是在一致性hash环上做嵌套处理。
一致性hash：
1997年由麻省理工学院提出(参见扩展阅读[1])，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题，使得DHT可以在P2P环境中真正得到应用。一致性哈希基本解决了在P2P环境中最为关键的问题——如何在动态的网络拓扑中分布存储和路由。每个节点仅需维护少量相邻节点的信息，并且在节点加入/退出系统时，仅有相关的少量节点参与到拓扑的维护中。所有这一切使得一致性哈希成为第一个实用的DHT算法。但是一致性哈希的路由算法尚有不足之处。在查询过程中，查询消息要经过O(N)步(O(N)表示与N成正比关系，N代表系统内的节点总数)才能到达被查询的节点。不难想象，当系统规模非常大时，节点数量可能超过百万，这样的查询效率显然难以满足使用的需要。换个角度来看，即使用户能够忍受漫长的时延，查询过程中产生的大量消息也会给网络带来不必要的负荷。
4.半对称结构
介于1.2metadata server中央控制和1.3全对称的架构之间还有一种，就是把metadata也做成对称结构，我们可以称半还有一种，就是把metadata也做成对称结构，我们可以称半对称结构，典型应用如fastdfs，淘宝一大牛fishman写的，主要用作图片存储，可以实现排重存储看图，tracker cluster就是metadata server的角色，实现了对称架构设计。国内几个大的网站都使用了fastdfs，在实际使用中，发现storage server之间同步数据较慢。
分布式应用架构
分布式应用架构涉及具体应用场景，设计上除考虑上面的CAP和C10K等等经典分布式理论，还应根据业务进行权衡。基本思路：
1.在做完需求和模块设计后，要对各模块进行解藕Decoupling传统的企业应用设计一般是一条操作从头跑到尾（串行系统），拿视频网站的流程距离，传统应用设计是先上传是视频，然后存储，编码，最后发布一条龙。
2.在进行分布式设计时，先将各模块解藕，通过异步消息通知的方式将各模块链接。
3.最后，要考虑这个应用的压力承载点在哪，根据用户规模估算各模块的并行数量（如本例中的encode压力大，就增加encode模块的并行系统数量）。
架构方面的构建做好业务适用、成本和难度之间的权衡。