银行分布式数据库技术路线规划.docx

? ? ? ? ? ? ? ? 银行分布式数据库技术路线规划 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  银行分布式数据库建设路径探讨，希望听听同行的看法 近来行领导听到非常多的人来沟通说分布式数据库如何好如何有价值，银行在分布式数据库的核心诉求究竟是什么？为什么一定要上分布式数据库？有没有其他的技术路线可以满足需求？如果上分布式数据库，需要避免哪些坑？希望能听听同行的经验和看法，让我们也能知道同行是如何想的。 @岳彩波 产品经理： 一、采用分布式系统架构是由于业务需求决定的，若系统要求具备如下特性，便可考虑采用分布式架构来实现： 数据存储的分区容错，冗余 应用的大访问、高性能要求 应用的高可用要求，故障转移 二、 分布式系统遵循几个基本原则： 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% ，难度越大，投入成本越不可控（系统熵永不为零），因此可靠性系统必然选择并行分布式作为架构的基本方法。 @Amygo 数据库管理员： 1）银行在分布式数据库的核心诉求是什么？ 回答：行里有安全可控的技术创新压力；也有业务转型的业务创新压力和合理控制试错成本。 2）为什么一定要上分布式数据库？ 回答：创新就一定要控制试错的成本，及取得更大的行业影响力，要跟上时代的主流，避免技术路线上落后。 3）有没有其他的技术路线可以满足需求？ 回答：不差钱的话，直接上IOE设备，实在不行就上AS400 或S390。 4）如果上分布式数据库，需要避免哪些坑？ 回答：关键选对产品，选对厂商。产品一定要有生态链、行业应用案例和主流成熟的技术；厂商一定要专注做数据库产品研发和做到满足行里随叫随到的服务体验。 @孔再华? 某银行?数据库运维工程师： 现在所有的大行都在实践分布式数据库。 分布式主要解决两个问题。一是性能扩展，弹性伸缩。单机数据库的处理能力是有上限的，尤其是纵向扩展有极限，也不能解决单库的瓶颈。分布式数据库的横向扩展几乎是唯一的解决途径。二是高可用性，单节点的异常不会导致