对数据库架构的再思考

　　前面在谈PaaS的时候曾经谈到过共享数据库，私有数据库的问题，在这里再谈谈在多业务系统建设过程中的数据架构模式问题。首先来看下传统的数据交换解决方案如下图：

　　业务场景为单独构建的四个业务系统，在四个业务系统中SID数据为需要跨四个应用交互和共享的数据。传统的做法则是对四个应用存在的SID库数据进行数据集成和交换，则后续的每一个业务系统中都有全部的共享基础数据，任何一个应用的SID库数据需要通过数据交换和集成同步四份。在这种情况下：

　　　　优点：应用开发建设简单，完全本地数据操作和事务处理

　　　　缺点：数据同步多份，数据同步的时效性问题，数据本身在同步过程中产生的不一致问题

　　为了解决共享数据同步多份引起的数据不一致问题，我们考虑对共享数据进行集中处理，建立统一的SID共享数据库，即所有的共享数据只保留一份数据拷贝。共享数据以数据服务的方式向外提供能力，如下图：

　　在这种情况下，四个应用的所有SID共享数据全部集中到SID库，对于每个应用中只保留ADB私有数据，即所有的共享数据只保留一份数据拷贝，SID库以共享数据服务的方式向外提供服务。

　　优点：只保留一份数据拷贝，不会有任何数据不一致和数据实时性问题，提供共享数据服务能力可复用

　　　　缺点：单个应用开发的复杂度增加，很多问题转换为跨库问题，分布式事务也导致潜在的数据不一致。

　　我的理解对于第二种模式始终是一种理想情况下的考虑，由于为了保证共享数据的全集中，而带来的大量的跨库分布式事务问题，往往得不偿失。在以上两点思考的基础上考虑一种可折衷的模式，即如下图：

　　在该模式下，数据的共享数据保留两份，即首先是原有的数据产生源头应用中保留一份，同时在SID共享数据库保留一份。原有应用中的数据负责数据的源头管理和维护，SID库仅仅负责数据读操作，将数据查询和读的能力形成可共享的数据服务朝外部其它应用提供。其它应用访问非本应用产生的共享数据时候，都需要通过数据服务查询SID库的数据。在这种模式下：

　　优点：应用开发建设简单，完全本地数据操作和事务处理。对于读操作存在少量的跨库操作，但是不存在分布式事务处理和一致性保持的问题。

　　缺点：数据有两份考虑，可能存在数据的不一致性，但是当前技术可以较好的解决掉。

　　在这种模式下可以看到和传统的MySQL数据库的读写分离思路相当类似。SID库仅仅是一个读库，供所有的应用读，同时为了包括性能读库本身可以扩展为多个读库集群。进行CUD操作的写库还是在原有应用中，可以大量的避免分布式事务的处理问题。

　　在这种模式下的实时性和一致性也较容易保持，例如对于本地应用库中的SID数据可以采用类似读写分离集群中的BinLog日志复制技术，这样可以基本保证SID库的准实时性。虽然不是完全高度实时和一致，但是由于是数据读，本身问题不大。

　　在这个问题考虑清楚后，接下来才是考虑对于单个应用本身的存储和并发量是否单个数据库节点能够支撑的问题，对于这点的考虑又存在单个应用本身的分布式数据库集群架构的考虑。这个在下篇进行思考。