银行分布式数据库建设路径探讨？

一、 采用分布式系统架构是由于业务需求决定的，若系统要求具备如下特性，便可考虑采用分布式架构来实现：

1. 数据存储的分区容错，冗余
2. 应用的大访问、高性能要求
3. 应用的高可用要求，故障转移

二、 分布式系统遵循几个基本原则

1、CAP 原理

CAP Theorem ， CAP 原理中，有三个要素：

一致性 (Consistency)
可用性 (Availability)
分区容忍性 (Partition tolerance)

     CAP 原理指的是，在分布式系统中这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数 web 应用，其实并不需要强一致性，因此牺牲一致性而 换取高可用性，是目前多数分布式数据库产品的方向。
    从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
     但 web 应用也有例外，比如支付宝系统，就要求数据（银行账户）的强一致性，而且面对大量淘宝用户，可用性要求很高，因此只能牺牲数据的分区冗余。这一点也曾在和支付宝工程师交流时，得到验证。

2.C10K 问题

     分布式系统另一个理论是 C10K 问题，即系统的并发用户增加 1 万（ customer ten thousand ，过去一台服务器承载， 假设为 1 万用户，现在平均 3 ～ 5 万），是否意味着增加一台机器就能解决问题？答案通常是否定。
    因为这涉及到系统的应用架构问题 ---- 串行系统和并行系统的架构和性能提升的关系：
    串行系统一般设备越多，性能成一条向下弯曲的曲线，最差情况，可能性能不增反降；而并行分布式系统设备越多，性能是正比例线性增长的直线 3. 串行系统和并行系统的可靠性问题。
    一个大系统一般都有超过 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% ，难度越大，投入成本越不可控（系统熵永不为零），因此可靠性系统必然选择并行分布式作为架构的基本方法。