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

在说这个问题之前，我想先说一下关系型数据库和分布式数据库的两个概念：
数据库的基本理论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实现读写分离，在大部分情况下都可以满足并发和数据存储的要求。不建议对核心系统盲目的上分布式存储架构，如果必须要做，那在做之前要详细的规划好方案，以及应用的改造。