依附大系统【数据实时获取】解决方案

最近公司作为众多外部厂商之一，需要依托一个大型平台系统( 这里简称为Big-S) 给特定用户提供一些服务。

作为外部厂商开发的 Web 应用（这里简称 Small-S），需要提取 Big-S 中的基础数据，包括用户、组织结构、代码表......部分字段到本地数据表中。

融合 Small-S 自己特点，作为搭建 Small-S Web 项目的先决条件。

Small-S 需要做到和 Big-S 的重点基础数据实时一致，重点关注 Big-S 数据交互方面的以下特性:

1. Big-S 提供给外部厂商交互方式大体有三种形式（EJB,WebService,JMS），数据表接近 4000 +。

2. Big-S 提供给外部厂商 Oracle 数据库 DB_Select ,当然 DB_Select 只含有 Select 权限。

至于其中 DB_Select 实时同步 Big-S 哪些数据库、需要怎样负载部署.....这些都不是该关心的事情。

内部进行了几轮 PK，最终确定了比较不错的解决方案，本篇将循序渐进陈述几种提出的方法，给其他同行做参考为主，记录总结为辅。

可能有人会感到疑惑，直接将需要的基础数据一次性抽取过来不行么？

Big-S 中实时也在操作这些数据，抽取过来的数据肯定会和 Big-S 中产生误差，已这样的数据作为基础的 web 项目，等着被领导请去喝茶吧。

1. 使用 Big-S 提供的外部服务

使用 BIg-S 提供的外部服务，获取数据过程为实时处理，而且处理速度也相当不错。

获取数据时，你需要一些前置条件组织请求，才能准确的获取到你需要的数据，比如你需要一个用户信息,前置条件可能是用户ID，组织机构ID......

首先考虑到的是 Small-S 需要扩展业务的时候，得去查找 Big-S 是否有提供类似的服务供你使用，如果有则好。
如果没有呢？告诉 Big-S 去给你定制开发一个？
其次，Small-S 需要做类似的查询功能时，假设查询所有用户信息，这时候你是没有前置条件的。
最后，虽然获取数据响应事件速度是不错的，但 Small-S 需要组织请求、去除不相关的、转换为预期的 Small-S 数据结构对象，这些都耗时耗力。
EJB/WebService 服务的调用、交互规则不是本篇要阐述的重点，有兴趣可以自己看一下。

2. 双数据源配置

使用 Big-S 提供的服务实时获取数据，被众人驳的体无完肤之后。

紧接着有人将目光放在了 Big-S 对外提供的数据库 DB_Select 上面。

具体想法为同时链接 Small-S 和 Big-S DB_Select , 公用同一个数据库资源池。

    <bean id="small-s" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
        <property name="driverClass" value="${smalls.driverClassName}" />
        <property name="jdbcUrl" value="${smalls.url}" />
        <property name="user" value="${smalls.username}" />
        <property name="password" value="${smalls.password}" />
        ........
    </bean>
    <bean id="big-s" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
        <property name="driverClass" value="${bigs.driverClassName}" />
        <property name="jdbcUrl" value="${bigs.url}" />
        <property name="user" value="${bigs.username}" />
        <property name="password" value="${bigs.password}" />
         ......
    </bean>

使用 Spring 可以很轻松的做到双数据库配置，资源池可以使用常见的 C3P0、DPCP....
开发时可以在具体 Dao 层由程序员决定具体需要的数据源自己注入，或做点设计将两个数据源同时注入到父类 dao 中，基类 dao 继承即可。
这时候，只要知道具体业务、具体表名，可以轻松获取到 Big-S 中的数据，这点还是相当满意。
但是基础数据中实时变化的那部分，读取 Big-S 数据同步到 Small-s 中？
做定时任务？时间间隔设置多少合适？间隔当中 Big-S 用户数据发生变化，Small-S 中的用户进行业务操作该怎们办？
这种解决方法提供了一些思路，当最终还是夭折在同步上，耗时耗力。

3. Oracle DB_Link + Synonyms

这个思路提出是一位经验老道的数据库 DBA ，在 Small-S 上建立 DB_LINK 到 Big-S 上，然后在 Small-S 上面建立需要表的同义词。

与视图类似，同义词并不占用实际存储空间，只有在数据字典中保存了同义词的定义，查询 Big-S 表时都是实时数据。

建立数据库链接和同义词过程：

    -- create database link
    create public database link big-s_link
    connect to '用户' identified by '密码'
    using '(description =
            (address_list
            (address = (protocol = tcp)(host = 'ip')(port = '端口'))
            )
            (connect_data =
            (sid = '实例名')
            (server = dedicated)
            )
            )';

   -- create database synonym
   create or replace synonym s_a for b_a@big-s_link;

在实际分析中，Big-S 共有的4000+的数据表，Small-S 顶多会使用到的只有200+。
随义务扩展可以自行选择 Big-S 中的数据表，非常方便进行扩展。
使用这种方式不需要配置两个数据源，只链接 Small-S 的数据库即可。
同义词的使用保证了数据实时一致性，不会因为用户信息错误，而产生利益纠纷。

至此依附 Big-S 数据实时获取解决方法应该来说有了比较不错的落地，至于使用后是什么情况，需要项目上线运行一段时间才能知道。

Big-S 毕竟是大公司，具体我就不提了，而且是多厂商协同，切记相互扯皮，出现问题，在自己方定位问题未果后在去询问对方。

注意对人起码的尊重，说话客气一点，搞好关系，这样会事半功倍。