银行分布式数据库设计与运维中的最佳实践Word格式.docx
- 文档编号:15701333
- 上传时间:2022-11-15
- 格式:DOCX
- 页数:7
- 大小:75.45KB
银行分布式数据库设计与运维中的最佳实践Word格式.docx
《银行分布式数据库设计与运维中的最佳实践Word格式.docx》由会员分享,可在线阅读,更多相关《银行分布式数据库设计与运维中的最佳实践Word格式.docx(7页珍藏版)》请在冰豆网上搜索。
中国民生银行数据库运维工程师:
对于金融级的分布式事务要求,其实算是比较明确的。
首先是强一致性,这个是和互联网行业不一样的地方,也是分布式数据库的基本要求。
现在不建议金融行业继续掺和自研数据库的事情,因为市场上已经很多分布式数据库产品和案例了。
所以现在银行有两种。
一种是自己已经推出了分布式案例的,会在自己的选型基础上继续扩展。
一种是尚未使用分布式的,会挑选国内的分布式数据库来部署。
那么现在主要谈谈这个第二种。
分布式数据库该怎么选型?
银行会在保证全局ACID的前提下,也就是强一致性前提下挑选分布式数据库产品。
分布式事务的一致性现在已经不需要银行来设计保证了,数据库产品就已经涵盖这个能力。
不过每个数据库在这点使用的技术确实不一样,有依赖生成全局事务号的,也有基于全局时钟的,可能还用很多其他全局的组件和服务。
这些设计会影响事务的性能,因此需要详细测试才能比较出来。
不过我个人认为这个是基础,挑选分布式数据库还有其他很多方面需要考虑。
@wanglaye某大型金融机构
项目经理:
传统关系型数据库和分布式数据库所提到的“一致性”,个人觉得并不完全等同。
分布式数据库一致性包含数据一致性、事务一致性两个维度。
分布式数据库的一致性,分为强一致性、弱一致性、最终一致性。
属于哪个一致性等级,与数据库多副本状态下的读写成功所需的最小化副本数有关。
银行账户类系统选择强一致性最为保险,互联网公司可能会倾向于选择最终一致性。
2、选择分布式数据库的担忧?
一直担心分布式数据库的原因如下【简单说几点】:
1、采用分布式数据库,解决了数据分布式存储,则数据的一致性如何保证?
若是实时交易性系统,数据并发写访问量大的情况下,依然会出现性能瓶颈【没有办法或者很难将访问关系进行拆分】,故写数据大量集中,而数据要同步到其它存储上,会存在一定的时间延迟。
若这是进行大量的读访问【此时可采用分布式】,会存在已存在的数据未同步完成,不能有效访问。
故分布式数据库的应用场景在银行中是交易性型系统还是管理型系统?
还是分析型系统?
案例较少,故一致未确定采用。
2、采用分布式数据库后,系统架构变得较为复杂。
首先是设备数量增多,其次数据拆分规则难以确定【技术与业务人员的口径难以得到统一】。
还有分布式数据库第三方的技术支持困难。
最后是目前市场上分布式数据库没有一个大家公认的领头羊。
(问题来自@lyq6666重庆农村商业银行IT顾问)
@孔再华中国民生银行数据库运维工程师:
数据库的一致性一定是要强一致性保证的,金融行业的数据库这是必须的要求。
分布式数据库的全局一致性一般通过两阶段提交的方式来实现,基本上就是要求全局一致的提交和回滚。
如果有异常发生,数据库内部可以查到全局事务的残留,处理之后也能最终达到一致性。
分布式数据库的性能问题是个很重要的点。
大家都知道分布式是为了解决单点的性能才被提出来的。
但是他仅仅是为了解决单点的集中式高并发需求,而不是为了复杂查询或者是大查询。
因此使用分布式数据库一定要把握好他的应用场景。
实时交易系统这种写并发大的情况其实也适合分布式,前提是他们的写是能基于分布式进行分片,能把写操作分散到各自的分片上去完成。
读也是一样。
分布式不适合的场景就是复杂的关联查询,大量的分布式事务等场景。
分布式适合交易型系统,不适合管理类分析类。
分布式最大的痛点就是怎么分片,数据拆分这个是不可避免需要花最大力气的地方。
因为这个前提,这里控制不好,后面擦屁股的活儿根本干不完。
目前没有领头羊,押注吧。
@wanglaye某大型金融机构项目经理:
1、一致性,分为强一致性、弱一致性、最终一致性。
最常用的一致性协议有paxos、raft。
若采用强一致性,则又分为两种情况:
读写分离、读写不分离。
读写分离情况下,无论读或写都需要大多数副本成功才认为读写成功;
读写不分离情况下,写需要大多数副本写成功才返回成功,读只能读主副本,也能保证读到的数据是最新的。
写并发高的情况,通过合理策略进行数据分片(甚至二次分片),把数据打散,避免热点盘。
在主机配置和网络带宽有限的情况下,写数据量大到一定程度是无法避免性能瓶颈的,事先可以通过分片避免热点盘,事中可以扩容。
所以一般建议根据应用系统的交易量来规划设计数据库,可以一定程度上避免高并发写带来瓶颈。
读并发高的情况,还是选择强一致性的数据库吧。
交易类系统我们选用的是高性能事务型分布式数据库。
分析类系统对实时事务处理要求不高,会选择HBase这类建数仓。
管理类系统,得看是哪类,如果是实时监控类的管理系统对性能要求高可以上,其他的管理系统为了节约成本可以选择普通数据库。
2、系统架构并没有很复杂,反而更利于运维管理,一般分布式数据库都有管理节点和计算节点,对于管理员来说维护复杂度反而下降了,不用每个业务系统维护一套了。
数据分片时,业务和技术听谁的,这个难以回答,每家企业有自己的做事策略。
领头羊当然是有的。
3、从应用和所需处理的数据角度,对银行的各种应用场景进行归类,哪类场景适合用哪类数据库?
选型时要注意哪些关键特性?
(问题来自@fanyqing厦门银行系统架构师)
对银行的各种应用场景进行归类,考虑从两个维度归类:
(1)交易型or分析型:
可以将银行的业务非常粗略地分为交易型场景、分析型场景。
网银、手机银行等属于交易类,数据平台、报表系统属于分析类。
(2)交易规模大or小:
并发量大的业务系统使用分布式数据库,并发量小的系统使用传统数据库(当然也可以使用分布式数据库,看贵行意愿)。
@Amygo分布式事务数据库管理员:
(1)业务类型建议:
分布式事务数据库适合实时关系交易型、业务峰值较大和并发较大的业务场景,从银行考核的角度推荐B类、C类先试点,再考虑A类和核心系统。
(2)具体的业务场景:
以互联网核心中的网联系统、积分系统、理财产品、网贷系统等为主。
(3)选型关键特性:
A、数据一致要求:
支持高性能、透明、实时一致的分布式事务算法,保证事务实时全部提交或全部回滚,严格保障数据的一致性;
支持事务隔离级别ReadCommitted、RepeatableRead、Serializable;
支持悲观锁、智能实时死锁检测、智能实时死锁解除及记录相关日志信息。
B、数据库功能要求:
支持CREATE、TRUNCATE、DROP、ALTER、RENAME、SELECT、INSERT、UPDATE、DELETE等数据库基本操作;
支持透明跨数据分片的JOIN连接;
支持透明跨数据分片的分组计算、排序、分页、聚合函数、控制函数等。
C、水平扩展要求:
具有完备的动态扩容缩容能力,支持可视化在线一键扩容缩容,做到:
在线增加/缩减从存储节点读操作扩容、数据节点跨物理服务器迁移扩容、增加/缩减数据分片的扩展等多种扩容缩容模式,数据节点扩展分布式集群的处理能力和数据容量,且扩容/缩容过程中做到不影响业务访问。
D、业务键分片:
支持智能算法按业务访问需要生成数据分片的分片键、分片类型等,这个涉及到如何确保业务系统性能最佳和数据架构设计最佳。
4、请教专家:
贵公司在分布式数据库应用方面:
主要解决了什么问题?
使用的场景是怎样的?
上线之前需要考虑的因素主要有哪些?
(问题来自@zhangjunpoCBIT数据库运维工程师)
民生银行的分布式核心系统是将直销银行核心系统搬迁上去了,未来会将真正的核心系统也做分布式改造。
当前我行使用的是基于阿里开源的分布式中间件zdal基础上自研的分布式架构,底层采用了开源数据库mysql,通过一主多备实现高可用。
我行采用分布式数据库方案主要是为了解决集中式高并发交易存在性能瓶颈的问题。
通过采用分布式,分摊数据和交易,解决了性能,也分摊了风险。
合理的业务数据分片,严控事务分发,当前一直保持稳定高效运行。
我们避免了分布式事务,从业务层面解决了这个问题。
因此对于其他希望采用分布式数据库的金融企业,上线前主要考虑的因素也是怎么让业务和数据做好分片,怎么避免分布式事务。
然后考虑怎么运维分布式的环境。
5、目前有什么业内用的较多的成熟产品吗?
分布式数据库我测试到现在,其实内心是觉得大家都不成熟。
如果你仔细看业内的使用案例,你会发现大家用的产品都不一样。
这也是和分布式数据库这几年遍地开花有关系。
而且你会发现一个特点,主打分布式数据库好像都是国内的产品。
国外也就一些开源的分布式产品,也都属于半成品。
我们在测试的过程里发现,分布式数据库的瓶颈一般都会在全局事务管理器这类全局统一的集中点,所以哪个数据库能把这些做到轻量级,哪个数据库性能就好点。
6、分布式数据库如何具体实施?
具体如何设计,最大程度避免风险?
(问题来自@feifei7412中信数据库运维工程师)
分布式数据库的实施我觉得分为两方面。
一方面是数据库的对象实施,怎么设计表,怎么选分区键,怎么控制业务访问。
另一方面是数据库架构实施,怎么挑选节点,怎么安排好组件,怎么做多中心部署。
从第一个方面来说,大表选择查询或者关联的条件列作为分布列,小表需要建立成复制表。
减少非分布列条件的大表关联查询,减少分布式事务。
也就是从前到后都要按照分布式的理念去设计。
从架构的角度来说,需要确定好多中心的部署方案,需要确认好集群内部的冗余机制,保证出现单机故障或者单中心故障的情况下,都有冗余措施能够保证数据服务可用,数据不丢失等。
最后做好检查和维护的方案。
保障系统稳定运行。
在设计分布式数据库架构时,要考虑高可用、负载均衡、网络、存储、监控与告警、备份与恢复、灾备、日常运维、应用适配和优化等多方面的方案规划。
尤其需要特别注意网络延时、多应用数据隔离、分布式事务处理、数据归档等难点问题。
@GoldenDB中兴通讯产品经理:
分布式数据库分为横向数据分片分担负荷,纵向主从分片增加可靠性。
业务分片主要是根据业务表的实际规模或者设计规模进行设计,跟业务功能有关。
纵向分布主要是根据同城异地机房的分布来设计,一般一个机房部署1-2个节点,
如果有跑批类的需求,还可以增加分片专门用于跑批。
对于量不大的点,可以在同一个硬件节点部署2个分布式数据库实例来减少投资。
具体情况肯定还是要具体分析。
7、
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 银行 分布式 数据库 设计 中的 最佳 实践