企业级大型核心业务系统架构设计 -- 数据库架构 （草稿）

此贴仅为了记录偶的初步设计思想，是为了防止将来忘掉，供个人知识积累用。其实偶希望找一个个人Wiki的，但没有，所以只能通过Blog自己记录一下。

 

企业级大型核心业务系统的特点：

1、业务非常复杂，每个交易将有大量涉及到N多表；

2、每天晚上都会有大量的批处理任务，例如：跑出保单状态，并更新，只能在主数据库中更新，因为需要回写状态；

3、对外提供N多接口，支持N多外围系统的应用，如：呼叫中心、网销等并发非常大的外围系统；

4、提供7X24小时的应用，在上班时间内部用户使用较多，而下班后可能网络用户使用较多，这时要求系统提供7x24服务。

 

对于这些问题数据库架构将是一个非常大的挑战，因为应用服务器可以通过无限的扩展应用服务器来达到压力均衡，如果应用服务器越多对数据库的压力越大，不管怎样数据都必须落地在数据库中，那么数据库的架构就需要：

1、如果采用传统的双机热备架构，即：一台无比强大的小型机支持应用，这样可能出现问题：

     1）单台机器即使满配也可能无法支持应用，例如：595满配就是64颗CPU，单对于支持10000+以上同时在线的系统，如果应用设计稍微不合理（应用非常复杂，难免有设计不是十分合理的情况），那么单台机器将无法支撑；

 

如果不采用双机热备，那么可以采用RAC+DataGuard，RAC可以无限扩展，但偶曾经遇到一次RAC使用的失败例子，其中先出现了内存问题，导致频繁宕机，后面有出现RAC之前同步消耗而外20%的性能，加大的通讯量。此次问题之后放弃使用RAC了，但由于应用的复杂度还不是特别大，因此单机能撑住。但面临单机无法支持的情况，这时只能选择可扩展的架构——RAC。

 

RAC设计中尽量减少各个实例之间的内存数据通讯，通讯的产生就是来自于多台实例中都缓存了同一张表的数据，那么这样表的数据更新了就会出现同步。那么最好是通过应用的方法避免同一张表的数据在多台机器上，因此选择RAC架构，就必须涉及到应用架构的一定调整，偶想到的应用调整：

1、按照模块建立不同的DataSource配置，对于这个模块都采用这个数据源；

2、在Spring配置中为每个模块配置一个父类，避免子类在程序中选择；而且注意这么好的配置肯定只能是生产环境，而测试环境可能还是只有一台机器，那么基于封装变化的设计原则，那么这些数据源的选择就是必须在架构层面控制；

3、ETL、Job都要注意选择特定的机器来执行对应的应用，避免数据表缓存的同步。

注意：数据源的配置需要特殊设计，即将Oracle的链接配置为Service方式，将多台机器的顺序不同，例如：3台机器，A/B/C，那么数据源1的优先顺序为ABC，数据源2的优先级为BCA，数据源3的优先级为CAB。注意：第一台机器的顺序重要，之后的仅是在第一台坏掉的时候自动选择后面的机器，以防止数据库的单点故障。

 

待确认问题：RAC架构的跨Instance的事务是否支持？

问题起因：由于按照模块设定数据源，那么涉及到一个功能要更改多个模块的数据时一个Spring的事务是否可以管理？或者Oracle是否支持多台机器之间的事务？或者是要启动XA？

具体的原因：Spring如果配置多个DataSource，而DataSource的配置可能是在应用服务器（如：WebLogic或WebSphere）上，应用服务器的DataSource可以配置为Service模式，但由于机器的顺序不同，那么一定会配置多个DataSource，那么Spring的事务管理是否支持跨DataSource事务，是否要使用JTA？