核心系统是否适合部署分布式存储，如何设计和实施？

ACID,前面几位专家说的很对，分布式数据库也要保证ACID特性，要不就谈不上数据安全
ORACLE数据库部署分布式存储上，最大的问题不是ORALCE 的问题，数据库本身的机制可以保证ACID，但问题是在于数据存储层的响应速度和性能、可靠性，可维护性是否能够满足数据库的要求，不出现数据问题，导致整库的数据损坏。首先要保证分布式存储的可靠性、可维护性，比如计划外宕机之后带来的数据rebalance，是否可控，是否不影响数据库数据得响应。做失效分析，将数据分布和存储节点分布标准化。

先说结论，如果业务逻辑不改变，我认为现在能看到的分布式存储基本上都不适合银行的核心系统。焦点矛盾在于一致性和时延。

先从理论上探讨。分布式存储也要必须遵循分布式系统的基本理论，逃不掉的CAP。一致性，可用性，分区容忍性，这三者是互相矛盾的，你只能取其二舍其一。但是对于银行的核心系统来说，其实这三者都相当重要，很难舍弃掉其中一项。首先必须是个强一致性的产品，否则数据有可能会出现不一致，对不上账，那肯定是不行的。如果放弃可用性了，你的系统会出现偶尔不可用，想想用户的体验也很差吧。如果分区容忍性有问题，意味着一部分节点坏掉，会牵累整个系统，这也有点难受吧。这样的系统实现了也有扩展性不好的问题。

分布式存储，顾名思义它的节点一定是分开的，节点之间的数据通讯一定是通过某种网络。普通以太网或者光纤网，都无法提供很好的时延。目前看来只有IB网，时延才可以控制得比较好，但这也远远无法和一套本地的存储背板带宽的时延相比。这个时延问题不解决，整体系统的时延只会比它长不会比它短。所以很可能最后是无法满足银行核心系统的需求的。

那我们来看看具体的行业应用，如果按照金融核心系统的特点来看，相对合理的选择也许是强一致性高可用性，但是这样的系统往往性能不好，所以也是有点勉强。

  在其他行业来讲，分布式系统在互联网用得比较早，实践也最多，但这个和应用特点是有关联的。我们看到很多在互联网行业使用的分布式存储产品都是采用最终一致性。这实际上意味着舍弃掉了强一致性。保留了高可用和分区容忍性，结合互联网的应用场景。这样其实是适合的，对互联网和电商行业，焦点矛盾是必须支持更多的并发请求，所以必须有更多的节点分担工作负载，提升系统整体可用性。先让客户把商品装到购物车里，后续可以慢慢的同步数据，“最终实现一致”。

另外，互联网行业的一个强需求是扩展性，他必须要支持这么多的数据量，例如淘宝后面的图片存储系统tfs，他首要解决的问题就是有如此之多的商品图片需要存储，并且能够及时的被各个网页连接所调用。他的数据量绝对值相比银行核心系统，是有数量级的差距。银行的核心系统应该没有这样的需求，分布式系统的这一优势特点也就无从发挥。

分布式存储还有另外一个应用的行业是物联网。同样也是数据数量特别多，但每一条数据倒不是很大，同样，他们也没有强一致性和及时响应的强需求，但是数据的绝对总量非常大，所以分布式存储可以满足，但是这个需求特点和银行核心系统相去甚远。

所以分布式存储即使在一些行业应用比较适合，看起来也比较成功。但是考虑到银行核心系统对于数据一致性的强需求和低时延容忍度，如果现有的业务逻辑不做改变，其实是有点勉强的，要做很多工作，无法拿过来就用。

仅提供经验参考：
核心系统入往往是以数据库为核心的，分布式系统的结构决定了其对数据库系统的IO特性支持不如集中工存储好; 此外，从分面式存储技术可靠性角度相对于已经成熟多年的集中式存储具有明显优势。
因此建议，对于核心数据库系统的存储还是使用集中架构的设备，能通过配置较大容量的SSD提高IO性能。

“分布式存储”指的是什么？Server SAN还是仅仅把存储分到3个以上节点就算分布式存储？
从大趋势上看，IT系统要支持更高的吞吐量、更大的存储空间，同时保持成本上的控制。这就导致目前的趋势是采用更经济实惠的选择。比如，本来用大机的改用开放，本来用AIX改用Linux，本来Power的改用x86.

另外，目前CAP理论下，越来越多的企业，放弃了C,或者说放弃了强一致性，改变自己的业务逻辑。这样，分区就没问题了。

1.关于数据库的存储
数据库是应用系统的核心，因为前端的应用服务器可以大范围扩展，但是应用最终还是得落到数据库层面，数据库的server也可以有一定架构的扩展，但最后还是在磁盘进行数据落地。数据是一个企业（不论是不是银行或者金融）的资产中最重要的部分。
不论是传统数据库还是分布式数据库，存储都是最主要的，如果使用分布式存储，理论上讲可以提升IO性能，从而提高数据库处理效率。但实际生产中对最主要的核心系统，大家都不敢冒险，就是因为怕一旦出问题，搞不定。比如除核心系统之外的一些业务，其实我们都使用SAN存储，光纤交换机可以保证一定效率。SAN存储可视作一种分布式存储吧。一句话，大家都不敢用，是没人保证不出问题，出问题了担不起责任
2.系统性能
刚才说到很多应用服务器都组件集群，现在很多银行也在大范围的进行分布式数据库研究，通过对大数据分而治之的思路提升并发能力，比如中信现银行现在部分业务系统已经上了生产，并且在研究核心系统的分布式下移。很多银行都在进行或者已完成核心系统的主机下移，甚尝试把部分业务下移到开放平台。一句话：提升性能的一个号方法就是分布式，大家都在进行积极探索，个人感觉这是未来发展趋势，但是分布式之后带来的分布式事务管理是一个重要的课题和难点。

在数据库使用分布式存储的难点在于分布式存储的分布式文件系统延时较高，调用其他节点的延时时间，在普通文件读取时还能被人为忍受，但是数据库读取io的超时时间阀值都设定的都非常低，超过20ms都会造成数据库性能下降，超过3秒直接timeout,引起数据库宕机，因此数据库使用分布式存储非常少，如果要在测试环境部署，需要修改阀值，另外需要使用infiniband高效协议和交换机，再不行也要使用光纤网络，普通以太网很难达到架构要求。

在说这个问题之前，我想先说一下关系型数据库和分布式数据库的两个概念：
数据库的基本理论ACID
原子性（Atomic）。整个事务中的所有操作要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
一致性（Consistent）。在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
隔离性（Isolated）。隔离状态执行事务，使它们好像是在给定时间内系统执行的唯一操作。如果有两个事务，运行在相同的时间内，执行相同的功能，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化，为了防止事务操作间的混淆，必须串行化或序列化请求，使得在同一时间仅有一个请求用于同一数据。
持久性（Durable）。在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并不会被回滚。
对于ACID的实现方式主要有两个，一个是日志式的方式（Write ahead logging），几乎所有的数据库系统（MySQL、Oracle等）都基于日志的方式。另外一种是Shadow paging，代表的数据库主要是SQLite，Android或者iOS APP开发的话应该会比较了解，但大型的数据库都不会用到。
分布式数据库的CAP理论
一致性（C）。分布式系统中所有数据备份在同一时刻的值是否相同。
可用性（A）。当集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求（可用性不仅包括读，还有写）。
分区容忍性（P）。集群中的某些节点无法联系后，集群整体是否还能继续进行服务。
从这两种概念我们可以看出，大部分核心系统都不适合分布式存储，像银行的交易系统，大部分都是用的oracle,db2等，mysql都很少用，就是为了稳定在稳定，因为一旦出现问题，损失都是很大的。
就拿现在的核心系统使用oracle来说，在硬件设备允许的情况下，可以增加rac集群的节点，并且可以使用ADG实现读写分离，在大部分情况下都可以满足并发和数据存储的要求。不建议对核心系统盲目的上分布式存储架构，如果必须要做，那在做之前要详细的规划好方案，以及应用的改造。