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

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

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

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

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

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

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

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

扩展能力问题：

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

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

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

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

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

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

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

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

看到这个题目就是老生常谈了。

是要买便宜的X86还是买高大的上的unix的服务器，如果碰上VMware和其他没有unix服务器产品的厂商，对不起他们会告诉你，我们有太多U2L的方案了。来吧，我帮你设计解决，实际谁用谁知道，从成本和维护角度去考虑。整体算下来一点也不便宜，他们攻击unix无非是拿价格，服务等讲故事罢了。

互联网业务架构重要的是业务的可持续性，一旦发生中断，用户的体验就会非常差，如何解决业务可持续性。架构本身要健壮。怎么健壮。我相信还是要靠硬件设备本身足够高可靠.X86天生的可维护性就非常差就给我们运维人员带来了很大的困扰.