阅读目录
最近公司作为众多外部厂商之一，需要依托一个大型平台系统( 这里简称为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 数据实时获取解决方法应该来说有了比较不错的落地，至于使用后是什么情况，需要项目上线运行一段时间才能知道。