26 | 高可用存储架构：集群和分区

1.远距离集群网络延时较高，而且网络出问题的几率加大，导致数据复制的逻辑会比较复杂 2.成本过高，数据全量复制，等于存储多份 所以更好的办法是从业务端对数据做分区，出现地理故障时只形象一部分用户或者功能的使用

数据集群可以做到在不同节点之间复制数据，确保当一个集群断网断电的情况下，仍然有机房可以读取数据，但是在对外提供服务时不仅仅考虑是否能读写数据，还需要考虑读写数据所需的耗时。距离过远意味着耗时较长，如果是搭建专线，成本也会非常高，因而从成本和用户体验两个纬度考量远距离同步集群不适合直接对外提供服务。 对于城市级数据集群出故障，主要还是通过短距异地（网络耗时在十毫秒级别）集群来解决，远距离集群主要还是用于做冷备、数据离线比对等功能。

AWS按照地理分区为region，每个region之间大约相当于跨国分区，当然在很多国家里AWS都有多个region比如us-west-1，us-west-2，就分别位于加利福尼亚和俄勒冈，而us-east-1在弗吉尼亚 每个AWS的region下面又有多个availablility zone简称AZ，就是所谓us-west-2 a，us-west-2 b这样的，AZ基本上是不在同一个城市，距离至少要在数百公里以上，以保证地理级别可用 不同的region级别上数据是很难迁移的，如果有多region的数据同步需求，可能需要联系AWS的工程师来调配资源，而且费用也会很高，但是同region下的AZ级别数据同步是很容易的，费用也很低

既然数据集群就可以做到不同节点之间复制数据，为何不搭建一个远距离分布的集群来应对地理位置级别的故障呢？从以下几个方面来考虑:业务本身、均衡性、容错性、可伸缩性。 业务本身:在这样的一个集群上网络访问的质量是不可控的，导致用户体验差，用户无法忍受就只能放弃。         均衡性:在大规模的情况下算法很难保证各个服务器上的数据分区是均衡的。一个可能是算法本身在大规模的情况下失效了;另一个可能是集群中节点的负载情况时时刻刻在发生变化，分区一直处在调整当中。         容错性:大规模集群中服务器故障是家常便饭，当服务器故障时数据分区需要分配给其他服务器，这就导致了时时刻刻在发生数据迁移，影响正常业务的带宽。         可伸缩性:一是这样的集群Master是瓶颈，系统节点规模有上限;二是增加或删除节点带来数据分区的大面积迁移 总的来说，搭建一个远距离分布的集群来应对地理位置级别的故障是很不实际的方案，它注定不能将均衡性、容错性、可伸缩性这三者的影响控制在有限的范围内，进而影响正常业务的开展。

数据集群与数据分区。 其中数据集群又分数据集中集群和数据分散集群。 数据集中集群需要考虑的是，1）数据复制，2）状态检测，3）故障选举，典型代表zookeeper。 数据分散集群需要考虑的是，1) 均衡性，2）容错性，3）扩展性, 典型代表Hadoop. 数据分区需要考虑的是，1）数据量，2）分区规则，3）复制规则。 其中复制负责有可以分为1）集中式，2）互备式，3）独立式。 拿现在公司业务来说，现在选择的是mongodb，它能支持数据集中式集群（副本集，一主多从）和数据分散集群（数据分片） 公司在四个区（sz，as，us，eu）都有自己的DC中心，数据分区复制规则为集中式，具体表现是备份数据库都在as， 数据集群模式还是采用数据集中集群，虽然mongodb支持数据分散集群的，但是发现由延迟带来的数据复制问题变得非常严重。后来只弄取消这种方案。

我觉得这是我购买的众多课程中，最值的一个，谢谢！

老师讲的很好，但是从架构层面讲技术总有浅尝辄止的感觉，是不是我要从更抽象层面去理解架构。

数据分散集群具有均衡性，容错性，可伸缩性特点，响应比较快。 远距离分布的集群可有如下特点： 1、更容易出现不可用性，具体表现在业务响应慢，数据读/写/复制延迟高 2、一致性也难保证 3、也难保证均衡性，容错性，可伸缩性特点 4、复杂度较近距离的集群呈现指数级增长

老师您好，数据分散集群和分区感觉就是现在各种中间件的分片思想，为啥这里要严格区分分区和分散集群的概念呢？文章的分区我反复看了好几遍感觉本质还是分散集群，只不过文章强调了地理位置要足够远，其实本质还是一样的；

请问数据分散集群不就是分区吗？文章在论述时的分类和层次上是不是有点重合？还是我理解错了呢？请老师指导