银行分布式数据库设计与运维中的最佳实践.docx

? ? ? ? ? ? ? ? 银行分布式数据库设计与运维中的最佳实践 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 大数据时代，为应对海量数据的井喷式增长和业务需求的不断增加，分布式数据库应运而生。很多银行企业原本都是传统数据库一体化解决方案，在应对互联网业务的不断深化以及业务量的爆发式增长时遇到了显著瓶颈，但在进行分布式数据库改造时，传统数据库设计与运维经验不一定完全适合。那么，分布式数据库在进行规划设计需要注意些什么呢？实施运维过程中又遇到了什么困难？下面是几个常被问到和需要解决的问题，由银行专家分享实践经验。 1、关于金融级分布式事务技术路线 银行核心业务系统最主要的技术特征就是数据一致性，对于分布式数据库而言，就是分布式事务一致性，在成熟分布式数据库产品出品之前，如何设计和实现分布式事务一致性，各家银行采用了许多不同的策略，从而产生了多个不同技术路线和技术流派，例如分布式柔性事务、分布式强一致性事务等等。 各位专家、各位同仁对自己了解的不同分布式事务一致性技术路线谈谈看法？深入讨论一下。（问题来自@周光明 Peoples Bank of China 软件架构设计师） @孔再华?中国民生银行 数据库运维工程师： 对于金融级的分布式事务要求，其实算是比较明确的。首先是强一致性，这个是和互联网行业不一样的地方，也是分布式数据库的基本要求。 现在不建议金融行业继续掺和自研数据库的事情，因为市场上已经很多分布式数据库产品和案例了。所以现在银行有两种。一种是自己已经推出了分布式案例的，会在自己的选型基础上继续扩展。一种是尚未使用分布式的，会挑选国内的分布式数据库来部署。 那么现在主要谈谈这个第二种。分布式数据库该怎么选型？银行会在保证全局ACID的前提下，也就是强一致性前提下挑选分布式数据库产品。分布式事务的一致性现在已经不需要银行来设计保证了，数据库产品就已经涵盖这个能力。不过每个数据库在这点使用的技术确实不一样，有依赖生成全局事务号的，也有基于全局时钟的，可能还用很多其他全局的组件和服务。这些设计会影响事务的性能，因此需要详细测试才能比较出来。不过我个人认为这个是基础，挑选分布式数据库还有其他很多方面需要考虑。 @wanglaye 某大型金融机构?项目经理： 传统关系型数据库和分布式数据库所提到的“一致性”，个人觉得并不完全等同。分布式数据库一致性包含数据一致性、事务一致性两个维度。 分布式数据库的一致性，分为强一致性、弱一致性、最终一致性。属于哪个一致性等级，与数据库多副本状态下的读写成功所需的最小化副本数有关。银行账户类系统选择强一致性最为保险，互联网公司可能会倾向于选择最终一致性。 2、选择分布式数据库的担忧？ 一直担心分布式数据库的原因如下【简单说几点】： 1、采用分布式数据库，解决了数据分布式存储，则数据的一致性如何保证？若是实时交易性系统，数据并发写访问量大的情况下，依然会出现性能瓶颈【没有办法或者很难将访问关系进行拆分】，故写数据大量集中，而数据要同步到其它存储上，会存在一定的时间延迟。若这是进行大量的读访问【此时可采用分布式】，会存在已存在的数据未同步完成，不能有效访问。故分布式数据库的应用场景在银行中是交易性型系统还是管理型系统？还是分析型系统？案例较少，故一致未确定采用。 2、采用分布式数据库后，系统架构变得较为复杂。首先是设备数量增多，其次数据拆分规则难以确定【技术与业务人员的口径难以得到统一】。还有分布式数据库第三方的技术支持困难。最后是目前市场上分布式数据库没有一个大家公认的领头羊。（问题来自@lyq6666 重庆农村商业银行 IT顾问） @孔再华 中国民生银行 数据库运维工程师： 数据库的一致性一定是要强一致性保证的，金融行业的数据库这是必须的要求。分布式数据库的全局一致性一般通过两阶段提交的方式来实现，基本上就是要求全局一致的提交和回滚。如果有异常发生，数据库内部可以查到全局事务的残留，处理之后也能最终达到一致性。 分布式数据库的性能问题是个很重要的点。大家都知道分布式是为了解决单点的性能才被提出来的。但是他仅仅是为了解决单点的集中式高并发需求，而不是为了复杂查询或者是大查询。因此使用分布式数据库一定要把握好他的应用场景。实时交易系统这种写并发大的情况其实也适合分布式，前提是他们的写是能基于分布式进行分片，能把写操作分散到各自的分片上去完成。读也是一样。分布式不适合的场景就是复杂的关联查询，大量的分布式事务等场景。分布式适合交易型系统，不适合管理类分析类。 分布式最大的痛点就是怎么分片，数据拆分这个是不可避免需要花最大力气的地方。因为这个前提，这里控制不好，后面擦屁股的活儿根本干不完。目前没有领头羊，押注吧。 @wanglaye 某大型金融机构 项目经理： 1、一致性，分为