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