互联网业务快速发展,银行系统架构师如何应对网银等数据强一致性系统的性能问题?

银行互联网业务正在快速发展。互联网业务典型的特征就是高并发,比如说秒杀,天猫上天天有秒杀,京东上天天有抢购,12306到了春节,每张票都是秒杀。这种高并发场景对基础架构的压力,不仅是Web、应用服务器,更重要的是对数据库的考验。

网银系统涉及到的主要业务是交易,是金钱的交易,所有交易数据都必须符合核心系统的对账。它和银行柜面系统涉及到的交易一样重要。数据强一致性是对其的最基本要求。

1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?

2. 怎么解决互联网业务系统数据库层面的扩展能力问题?

3. 互联网业务架构如何选择合适的服务器?

参与217

20同行回答

haizdlhaizdl  技术经理 , 大连
1. 网银系统对数据强一致性有要求,就目前来看,它还没办法实现真正的分布式,集中式架构更符合现实情况。2.高并发场景,前端的Web和应用很容易靠应用负载集群的横向扩展能力来解决。但数据库就没那么好解决了,常见的思路有这么几个:1)数据库缓存剥离为单独的集群缓存。2)NOSQL内存...显示全部

1. 网银系统对数据强一致性有要求,就目前来看,它还没办法实现真正的分布式,集中式架构更符合现实情况。

2.高并发场景,前端的Web和应用很容易靠应用负载集群的横向扩展能力来解决。但数据库就没那么好解决了,常见的思路有这么几个:1)数据库缓存剥离为单独的集群缓存。2)NOSQL内存数据库的应用。3)增加数据库节点的固有处理能力。但是不是说所有业务都能用内存数据库,也不是说所有业务都能剥离缓存,传统方式还是靠增加数据库节点的处理能力。但是这个扩展能力可不像应用集群扩展节点那么容易。

3. X86服务器集群架构代替大型机小型机等重量级服务器的热潮一波接一波,是不是传统小型机上的所有优势都能被X86集群架构代替掉?

对于应用服务器,基本没什么太大的疑问,大部分系统都可以用应用集群方式实现横向扩展,将集中式处理能力转化为分布式处理能力。

但是对于数据库服务器(关系型数据库),尤其是重量型OLTP业务,X86还是不能完美成为替身。

对于传统OLTP业务来讲,尤其是银行的交易业务,数据库的模式并没有因服务器的架构改变而随之发生质变,仅仅是兼容性的支持,融合性的提高,数据的强一致性要求没有丝毫减弱。所以我们不能简单的为了使用X86而迁移?过去用小型机是因为其良好的稳定性、系统的健壮性以及处理能力的强大,去小型机是因为其昂贵的成本以及其独有的封闭性。今天我们用X86是因为其低廉的成本和相对已经得到质的提升的性能,今天成熟的集群技术,良好的X86服务器生态环境,这三者综合的性价比。按照企业宣扬的精神:客户是第一位的,企业自己是第二位的。所以我坚持认为核心系统的选型还是要以质为第一目标,对于非核心系统要以性价比来衡量。

收起
银行 · 2016-01-12
浏览8290
  • 笔者说的很靠谱,接地气,言论都是可以落地的。赞一个
    2016-01-12
  • x86服务器一般不建议用做核心数据库服务器的,据统计,x86服务器单机整体故障率每年2%,x86服务器的可靠性低是核心数据库服务器的最大隐忧。另外,x86服务器更新换代太快,生命周期较短,比如Intel每隔1年半左右更新换代新型号CPU。 还有,数据库一般属于I/O比较繁重的负载类型,众所周知,x86服务器另外一个致命的瓶颈在于I/O处理能力不强,这也是我们普遍看到运行CPU负载(如科学运算)x86服务器的CPU利用率很高,而对于I/O型负载(如数据库)无论如何CPU利用率维持10%左右,无论如何都上不去。
    2016-01-14
  • 银行交易必须同时满足一致性和可用性。唯有确保交易数据的实时强一致性,否则造成金融风险后果是不堪设想的。银行的交易不是简单的金额加减问题,要涉及到客户账,分户账,会计总账等系列后台逻辑数据的变更,所有的账务系统要有相应的规则统一管理。银行交易必须在一个逻辑处理事务单元实时完成并保证ACID。国内还没有听说过哪家大、中、小行勇敢的把核心数据库搬到分布式架构去尝鲜,这个风险不是某行长随便拍板就可以担当的了的。所以,银行系统除了考虑性能,尤其还得考虑系统平台的稳定性、可靠性和安全性。这些正是小型机和IBM 大型机(包括IBM LinuxOne)的强项,这也正是这么多年来它们长盛不衰的原因之一。
    2016-01-14
panjianzhuangpanjianzhuang  系统架构师 , IBM
1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?2002年麻省理工学院MIT的教授在数学上证明了CAP理论,在分布式计算(存储)的架构里,由于网络引起的时延是必然的(Partition Network Toleration),因此对于一个操作在数据一致性(C=Consistency)和数据可用性(A=Availabi...显示全部

1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?

2002年麻省理工学院MIT的教授在数学上证明了CAP理论,在分布式计算(存储)的架构里,由于网络引起的时延是必然的(Partition Network Toleration),因此对于一个操作在数据一致性(C=Consistency)和数据可用性(A=Availability)方面必须取舍一个。

许多互联网的业务类型(电商、搜索引擎等等),可以接受最终的数据弱一致性,而对于金融业需要数据实时强一致性的业务,采用关系型商业数据库集中式架构来满足ACID(代表Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性,是实现实时强一致性的基础)也是历史的正确选择。

分布式计算、集中式计算不是谁替代谁,而是各有不同的用点,各适合不同的业务场景需求。

很多互联网业务对数据不一致性及耦合程度要求低,可以使用无共享分布式计算架构。这种架构中的每一个节点( node)都是独立、自给的,而且整个系统中没有单点竞争。无共享分布式架构在Web 应用开发中尤其受到欢迎。

对于银行核心业务或【网银等有数据强一致性的系统】对数据有着严苛的实时事务完整性的要求,即使在高峰时段也要保持高可用并确保交易能快速完成,因此更注重数据的实时强一致性,采用集中处理架构是一种正确的选择。

2. 怎么解决互联网业务系统数据库层面的扩展能力问题?

数据库层的扩展一般分为横向扩展和纵向扩展,比如对于Oracle数据库,横向扩展可以用Oracle RAC,但是现实问题是,Oracle RAC的节点达到3个以上,整体性能急剧下降,且多个节点之间的通讯的性能消耗和延迟也很大,这也是市面上3节点(包括)以上的Oracle Rac架构不常见的原因。

既然横向扩展有瓶颈,那么我们就应该考虑纵向扩展,这就需要从单台服务器的扩展能力来寻求解决问题的能力。比如,可以选高端的小型机或IBM最新推出的LinuxOne服务器(运行Linux操作系统,全面支持开源,完全开放的主机)。顺便提一下,在LinuxOne服务器上运行z/VM系统(虚拟化的鼻祖,是PowerVM和VMware的爸爸),可以非常方便的实现在线动态横向或纵向扩展。且LinuxOne内部的通信是通过内存交换,特别适合Oracle RAC节点之间的通信,不仅可以很好的缩短交易的响应时间和增加网络吞吐,还可以多一种稳定的心跳途径避开HA“脑裂”。^_^

3. 互联网业务架构如何选择合适的服务器?

如上面所说,不同的业务可以选择不同的架构,各有各的优点,各有各的道,没有哪一种架构可以放之四海皆准。一般来说,前端应用等可以用分布式来部署,属于CPU运算型负载的前端应用服务器,适合用X86架构的服务器或用PowerLinux来做应用整合。对于后端数据库服务器,适合采用集中式部署,数据库是整个系统的核心,一般选型时要考虑服务器的可靠性、I/O吞吐能力、可扩展性和安全性。举个例子来说,IBM高端服务器LinuxOne就特别适合作为数据库服务器或数据库服务器整合。顺便掰扯一下,IBM LinuxOne秉承大型机50年的经典硬件特性,可以运行Linux系统,全面支持OpenStack、KVM等开源技术,CPU最多可以扩展到141颗,内存可扩展到10TB,服务器内部系统I/O总线带宽高达832GB/Sec,安全认证达到EAL5+(民用计算机最高认证),并且价格也跟普通的高端小型机相差不多(真是物美价廉)。

收起
硬件生产 · 2016-01-14
浏览6577
xjsunjiexjsunjie  系统架构师 , CNPC
1. 网银等有数据强一致性要求的系统还是建议选择集中式架构,分布式架构受限于网络时延和应用状态始终保持强一致还是有困难的。例如一个典型的场景,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。2. 怎...显示全部

1. 网银等有数据强一致性要求的系统还是建议选择集中式架构,分布式架构受限于网络时延和应用状态始终保持强一致还是有困难的。例如一个典型的场景,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。

2. 怎么解决互联网业务系统数据库层面的扩展能力问题?

数据库的扩展性,很多传统数据库都有很大提升。比如ORACLE 12C就很更好的解决扩展性问题。而MYSQL在5.5之后的版本,扩展性也有很大的提升。

3. 互联网业务架构如何选择合适的服务器?

这个完全看需求,2路 、4路、8路都可以,很多厂商的服务器也都可以定制,依据跑应用还是跑数据库等做不同的定制化会很好,国产的服务器也可很好的满足这方面需求。

收起
互联网服务 · 2016-01-12
浏览6275
myciciymyciciy  IT顾问 , 某金融科技公司
2. 怎么解决互联网业务系统数据库层面的扩展能力问题?扩展能力问题:一般从两个方面考虑,一个是硬件扩展,一个是软件扩展 硬件扩展一般是遇到了性能问题。简单的说是DB层面出现了瓶颈,一般是遇到了计算能力,IO处理能力不足的问题。需要进行扩展升级扩容,现在的服务器本身硬件配置...显示全部

2. 怎么解决互联网业务系统数据库层面的扩展能力问题?

扩展能力问题:

一般从两个方面考虑,一个是硬件扩展,一个是软件扩展

硬件扩展一般是遇到了性能问题。简单的说是DB层面出现了瓶颈,一般是遇到了计算能力,IO处理能力不足的问题。需要进行扩展升级扩容,现在的服务器本身硬件配置都非常高,CPU和mem一般很难是瓶颈。经常出现问题无非是IO。处理IO瓶颈方法较多,一般常见的升级存储,扩容存储.最简单快速的方法就是采购新的闪存阵列,一劳永逸解决IO层面的问题.

软件扩展就是处理DB层面高并发和高可用,这个还是要根据实际的使用的数据库进行针对性的设计和配置.


收起
银行 · 2016-01-12
浏览6397
myciciymyciciy  IT顾问 , 某金融科技公司
1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?首先对于秒杀类业务场景典型特点的高并发。实际上业务整个系统架构(WEB-> APP-> DB)不是来自最终的后端业务交易,可能在web端或者app端就已经出现了堵塞。都没有机会到db层提交自己的订单交易。所以有时候不...显示全部

1. 网银等有数据强一致性要求的系统选择集中式架构还是分布式架构?

首先对于秒杀类业务场景典型特点的高并发。实际上业务整个系统架构(WEB-> APP-> DB)不是来自最终的后端业务交易,可能在web端或者app端就已经出现了堵塞。都没有机会到db层提交自己的订单交易。所以有时候不是db处理不过来。而是web或者app已经不能承受如此大的高并发了,就像当初的双11.我抢到了商品,结果在支付环节出了问题。选集中式和分布式都有自己的特点和优势,任何一种架构不天生就没有任何缺点。重要的整个架构整体相互协调,尽量避免出现木桶效应。


收起
银行 · 2016-01-12
浏览6562
footfansfootfans  IT顾问 , 吴江农商行
个人觉得银行目前的架构考虑还是以维稳为主,任何形式的上的变化引起的任何不确定性都不能接受。固然从技术层面可以承诺,但是领导决策的时候不是以单一的因素来判定。目前看过去,大多中小银行由于自身的因素,网银还是集中式为其主要结构。...显示全部

个人觉得银行目前的架构考虑还是以维稳为主,任何形式的上的变化引起的任何不确定性都不能接受。固然从技术层面可以承诺,但是领导决策的时候不是以单一的因素来判定。目前看过去,大多中小银行由于自身的因素,网银还是集中式为其主要结构。

收起
银行 · 2016-01-12
浏览6157
zp_ccczp_ccc  高级技术主管 , 国内某金融科技公司
应用层采用分布式架构应该没有问题,后端账务处理,目前分布式架构没有广泛应用,的确很多用户有数据强一致的顾虑,还需要有更多的应用场景给予支撑。另外,在更多关注正常运行时候的性能问题的时候,也需要关注一下,当分布式节点发生问题的时候,对整个性能的影响。...显示全部

应用层采用分布式架构应该没有问题,

后端账务处理,目前分布式架构没有广泛应用,的确很多用户有数据强一致的顾虑,还需要有更多的应用场景给予支撑。

另外,在更多关注正常运行时候的性能问题的时候,也需要关注一下,当分布式节点发生问题的时候,对整个性能的影响。

收起
互联网服务 · 2016-01-12
浏览6234
热心冰块热心冰块  项目经理 , 浪潮INSPUR
分布式用不上,可以应用缓存服务器,没记错这个在互联网公司很普遍,提高前端的访问效率,降低后端的压力显示全部

分布式用不上,可以应用缓存服务器,没记错这个在互联网公司很普遍,提高前端的访问效率,降低后端的压力

收起
系统集成 · 2016-01-12
浏览6289
hello_unixhello_unix  信息技术经理 , 西安
从大银行的参考来看,目前都是数据大集中,分布式的话没有案例,小客户更是不敢选择显示全部

从大银行的参考来看,目前都是数据大集中,分布式的话没有案例,小客户更是不敢选择

收起
互联网服务 · 2016-01-12
浏览6190
gggeeqggggeeqg  系统运维工程师 , 中国银行
借楼提一个问题:针对强一致性的问题,对于DB2来说,可以用高隔离级别(如RR)来保障数据的一致性,但RR级别容易导致出现互锁的现象,特别是业务高峰期,请问有没有一个办法即保障数据一致性,又有尽量减少锁的发生?...显示全部

借楼提一个问题:针对强一致性的问题,对于DB2来说,可以用高隔离级别(如RR)来保障数据的一致性,但RR级别容易导致出现互锁的现象,特别是业务高峰期,请问有没有一个办法即保障数据一致性,又有尽量减少锁的发生?

收起
银行 · 2016-01-12
浏览6556

提问者

haizdl
haizdl101634
技术经理大连
擅长领域: 灾备存储服务器

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2016-01-12
  • 关注会员:24 人
  • 问题浏览:27917
  • 最近回答:2016-01-14
  • X社区推广