压力、没时间进行充分测试、含糊不清的规格说明......无论多努力工作，还是会有错误，不过，造成无法挽回失败的，是数据库设计错误还是架构选择错误。 -- Stéphane Faroult，《SQL语言艺术》
针对不同的领域，由于信息资源类型及其存在的状态不同，信息资源整合的需求存在较大差异。 -- 彭洁，《信息资源整合技术》
确定数据分布方案是数据架构设计的难点。越是大系统，数据分布越关键。因此，一线架构师迫切须要建立数据分布策略的大局观。
我们接下来结合案例，讲讲如何运行数据分布的6种具体策略。
15.1. 数据分布的6种策略
所谓分布式系统，不单单是程序的分布，还涉及数据的分布。而且，处理数据分布内容常常更加棘手。
根据系统数据产生、使用、管理等方面的不同特点，常采用不同的数据分布式存储与处理手段。总体而言，可以归纳为以下6种策略：
- 独立
Schema(Separate-schema) - 集中(
Centralized) - 分区(
Partitioned) - 复制(
Replicated) - 子集(
Subset) - 重组(
Reorganized)
15.1.1. 独立Schema(Separate-schema)
当一个大系统由相关的多个小系统组成，且不同小系统具有互不相同的数据库Schema定义，这种情况称为“独立Schema”。
独立Schema方式的理解要点：“Application不同，Schema不同” 。
如果可以，架构师应首选此种数据分布策略，以减少系统之间无谓的相互影响，避免人为的将问题复杂化。
15.1.2. 集中(Centralized)
指一个大系统必须支持来自不同地点的访问，或者该系统由相关的多个小系统组成，而持久集中化数据进行集中化的、统一格式的存储。
该方式的特点可用 “集中存储、分布访问” 来概括。
15.1.3. 分区（Partitioned）
分区方式包含水平分区和垂直分区两种类型。
当系统要为“地域分布广泛的用户”提供“相同的服务”时，常常采用水平分区策略。水平分区的特点可用概括为 “两个相同，两个不同” -- 相同的应用程序、不同的应用部署示例(instance)，项目的数据模型、不同的数据值。
在实践中，水平分区的应用非常广泛，而垂直分区的作用相比之下要小很多。下图说明了垂直分区方式的特点： 不同数据解读的Schema会有“部分字段（Field）”的差异，但可以从同一套总的数据Schema中抽取得到 。
另外，需要特别说明的是，“分区”不是指DBMS支持的“分区”内部机制--后者作为一种透明的内部机制，编程开发人员感觉不到它的存在，常由DBA引入；而当前所讲的“分区”会影响到编程开发人员，或者应用部分工程师，一般由架构师引入。
15.1.4. 复制（Replicated）
在整个分布式系统中，数据保存多个副本，并且以某种机制（实时或快照）保持多个数据副本之间的数据一致性，这就是复制方式的数据分布策略。
15.1.5. 子集(Subset)
“子集”是“复制”的特殊方式，就是某节点因功能或非功能考虑而保存全体数据的一个相对固定的子集。
总体而言，子集方式和复制方式有着非常类似的优点：
- 通过数据“本地化”，提升了数据访问性能
- 数据的专门副本，利于有针对性的进行优化（例如：支持大量写操作的DB副本应减少
Index，而已读为主的DB副本可设更多Index） - 数据的专门副本，便于提高可管理性，加强安全控制
不过，实践中常优先考虑子集方式，因为它与复制方式相比有两大优势：
- 减少了跨机器进行数据传递的开销
- 减低了数据冗余，节省了存储成本
15.1.6. 重组（Reorganized）
业务决定功能，功能决定模型。当遇到数据模型不同时，一般能够从功能差异的角度找到答案。
重组这种数据分布策略，就是不同数据节点因要支持的功能不同，而以不同的Schema保存数据--但本质上这些数据是同源的。于是，重组策略需要进行数据传递，但不是数据的“原样”复制，而是以“重新组织”的格式进行传递或保存。
根据典型的应用场景，重组可以分为两种类型：
- 统计性重组
- 结构性重组
例如，总工时只需要掌握分公司的财务、生产等概况信息，那么就不需要把下面的数据原样复制到总公司节点，而是通过分公司应用对信息进行统计后上报，这叫“统计性重组” -- 数据的重新组织较多的借助了抽取、统计等操作，并形成了新的数据格式。
“结构性重组”的例子，最典型的就是BI系统。生产系统的数据被整合重组，增加各种利于查询的维度信息，并以新的数据Schema保存提供BI应用使用。
15.2. 数据分布策略的大局观
没有大局观，就很难理性选择数据分布的策略。因此，我们来总体对比6种数据分布策略的相同点及不同点。
15.2.1. 6种策略的二维比较图
一图胜千言，再次借助图来揭示“复杂背后的简单”。
根据系统的特点不同，架构师所规划的数据分布策略无非为两种方式：
- 非复制方式
- 复制方式
非复制包括3种具体策略：
- 集中
- 分区
- 独立
Schema
复制方式也包括3种具体策略：
- 复制
- 子集
- 重组
另一个对比视角是：数据节点的Schema是否相同。其中，独立模式和重组两种方式，像它们的名字暗示的那样采用了不同的数据Schema，而集中、分区、复制、子集这4种方式统一使用了相同的数据Schema。
15.2.2. 质量属性方面的效果对比
选择数据分布策略，应特别关注它们在质量属性方面的效果。
下面来整体看看哪些策略分布在可靠性、可伸缩性、通信开销、可管理性，以及数据一致性等方面表现最佳。
- 可靠性冠军：复制 。冗余不利于修改，但有利于可靠性。总体而言，复制方式的数据分布策略是可靠性的冠军。
- 其实，复制方式的可靠性和最终的“复制机制”密切相关，例如每天以快照方式来同步数据，不如实时同步的可靠性高。
- 可伸缩性关键：（水平）分区 。
Scale Up会随着服务规模的增大变得越来越昂贵，而且它是有上限的。对超大规模的系统而言，Scale Out是必由之路。而（水平）分区的数据分布策略非常方便支持Scale Out。- 有的文献上说“复制”方式对可伸缩性的支持也非常高，这种观点只对了一半--当数据以只读式消费为主时，通过复制增加服务能力的效果才好，否则为保证数据一致性而进行的“写复制”会消耗不少资源。
- 通信开销冠军：独立
Schema。独立Schema“得这个奖”是实至名归的。这很容易理解，既然独立Schema方式强调“将一组数据与它关心密切的功能放在一起”的高聚合原则 ，那么覆盖不同功能范围的应用之间就是松耦合的--用于传递数据的通信开销自然就小了。 - 可管理性冠军：独立
Schema。是的，还是它！由专门的数据Schema分别致辞不同的应用功能，它们是相对独立的，便于进行备份、调整、优化等管理活动。- 因此，前面提到过：“如果可以，架构师应首选此种数据分布策略，以减少系统之间无谓的相互影响，避免人为的将问题复杂化。”
- 可管理性冠军（并列）：集中 。为什么会存在“并列冠军”呢？因为从觉得角度评价可管理性是没有实际意义的。对采用了“数据大集中”的超大型系统而言，数据中心的管理工作依然具备挑战性，但相对于分散的存储方式而言可管理性已大有改观。可管理性应该视原始问题的复杂程度而论，是相对的，而不是绝对的。
- 数据一致性冠军：集中 。所有用户面对同样的数据，免去了修改同一数据不同实例的“麻烦”，便于保证数据的一致性。
15.3. 数据分布策略的3条应用原则
现在，我们已经全面了解数据分布的6种策略。下面，我们借助案例介绍数据分布6大策略的3条应用原则：
- 把握系统特点，确定分布策略（合适原则）
- 不同分布策略，可以综合运用（综合原则）
- 从“对吗”、“好吗”两方面进行评估优化（优化原则）
15.3.1. 合适原则
合适的才是最好的。“把握系统特点，确定分布策略” ，这是再明白无误的基本原则了。
医疗信息化中的电子病历可以复制，而各种系统常涉及的身份管理信息最忌讳复制。但为什么呢？
一句话，这是由系统的特点决定的。病历常作为医生诊断和治疗疾病的依据，是很有价值的资料。通过电子病历，可以将医务人员对病人患病经过和治疗所做的文字记录数字化，因此，电子冰雷的基本内容属于只读数据。为解决下列问题，电子病历可采用复制策略（例如在全网设置3个电子病历数据中心）：
- 各医院地域分布广，容易受到各种网络传输问题的干扰
- 如果不能使用专网，还要考虑“跨网络”性能差的问题
相反，身份管理信息不适合采用复制方式。用户信息有很强的修改特性：
- 新用户注册，意味着将有数据
Insert操作 - 用户修改密码或其他信息时，将有
Update操作......
这时，如果采用复制，会造成大量数据同步操作。所以，身份管理信息要集中，电子病历可以通过复制来提升性能和可访问性。
15.3.2. 综合原则：服务受理系统 vs 外线施工管理系统案例
当系统比较复杂是，其数据产生、使用、管理等方向可能很难表现出“压倒性”的特点。此时，就需要考虑综合运用不同数据分布策略。
电信BOSS（业务运营支撑系统）是电信运营商的一体化支持系统，它主要由网络管理、系统管理、计费、营业、账务和客户服务等部分组成。信息资源共享是BOSS规划是的核心问题之一。
其中自己“服务受理系统”和“外线施工管理系统”两个系统所覆盖的业务是相对独立的，各有自己的业务数据，采用“独立Schema”这种数据分布策略非常合适。至于两个系统之间存在互操作的关系，通过远程服务调用等形式支持即可。
单就“S市电信服务受理系统”而言，应采用什么数据分布策略呢？考虑系统欲达成到以下目标：
- 服务受理系统，应提供跨全市各辖区的、统一的服务。这意味着，在全市任何一家营业厅，都应该可以受理任何一个小区的电话开通业务。
- 例如，一个客户在浦东区居住，但在杨浦区上班，服务受理系统必须支持该客户在杨浦区申请开通浦东区某小区的一部固定电话。
- ......
所以，数据应集中。
再考虑“外线施工管理系统”。从业务角度，外线工作还是典型的“划片分管”模式，一般由支局负责。所以，推荐外线施工管理系统“开发一套，多点部署”--数据分布策略是：水平分区 。
总结一下，本例综合应用了3种数据分布策略
- 独立
Schema--服务受理系统和外线施工管理系统的数据相互独立 - 数据集中--服务受理系统
- 水平分区--外线施工管理系统
15.3.3. 优化原则：铃声下载门户案例
架构设计是一个过程，合理的架构往往需求团队甚至外部的意见，因此注重优化原则很重要。一个有用的技巧是：当难以“一步到位”的做出数据分布策略的正确选择，以及还存在质疑时，应从“对吗”、“好吗”两方面进行对比、评估、优化。
关于铃声下载门户的数据存储方案，张、王、李、赵4人分别提出了4种方案：分区、复制、子集、集中，他们各不相让，几乎要吵起来了......
解决分歧、优化设计的方法是从“对吗”、“好吗”两方面进行对比评估。思维过程如下：
- 分区。在功能支持方面，没有任何问题。但是在非功能方面不好，例如没有解决性能问题。
- 复制。在功能支持方面依然没有任何问题，但是太贵，大量并不流行，甚至无人感兴趣的铃声被多次复制是无意义的。
- 子集。在非功能方面有着独有的优势，将部分流行的铃声在多点进行复制存储既促进了性能，又没有增加过多成本。但子集方式必然是一种辅助方式，因为它需要和另一种支持所有铃声保存的策略一起使用。
- 集中。用它和子集策略“搭配”，最为合适。
如此一来，总体的数据分布策略方案呈现出来：集中策略 + 子集策略。
下一节：非功能需求的满足程度对软件项目的成功非常关键......非功能需求分为质量属性和约束两大类。质量属性是软件系统的整体质量品质--所谓整体品质，就是往往和大多数功能都有关，而不是仅仅表现在某个功能“内部”。志宇约束性需求，它们是架构设计中必须遵循的限制，并有可能“衍生”出质量属性需求和功能需求。 -- 温昱，《软件架构设计》
那么非功能需求方面常见的问题是什么呢？......很多《需求规格说明书》中，会通过一个名为“设计原则”的小节来说明非功能需求，列出诸如高可靠性、高可用性、高扩展性等要求。但是很多开发人员根本不去看它，因为这样的定性描述是没有判断标准的，因此这种信息传递是无效的。 -- 徐峰， 《软件需求最佳实践》