易坊好文馆

  1. 首页 > 玩科技 >

Reader|Oracle读写分离架构

业务 应用 能力 架构 技术 处理 数据库 Oracle Standby Reader Writer

读写分离是架构分布式系统的一个重要思想 。 不少系统整体处理能力并不能同业务的增长保持同步 ， 因此势必会带来瓶颈 ， 单纯的升级硬件并不能一劳永逸 。 针对业务类型特点 ， 需要从架构模式上进行一系列的调整 ， 比如业务模块的分割 ， 数据库的拆分等等 。
集中式和分布式是两个对立的模式 ， 不同行业的应用特点也决定了架构的思路 。 如互联网行业中一些门户站点 ， 出于技术和成本等方面考虑 ， 更多的采用开源的数据库产品(如MYSQL) ， 由于大部分是典型的读多写少的请求 ， 因此为MYSQL及其复制技术大行其道提供了条件 。 而相对一些传统密集交易型的行业 ， 比如电信业、金融业等 ， 考虑到单点处理能力和可靠性、稳定性等问题 ， 可能更多的采用商用数据库 ， 比如DB2、Oracle等 。
就数据库层面来讲 ， 大部分传统行业核心库采用集中式的架构思路 ， 采用高配的小型机做主机载体 ， 因为数据库本身和主机强大的处理能力 ， 数据库端一般能支撑业务的运转 ， 因此 ， Oracle读写分离式的架构相对MYSQL来讲 ， 相对会少 。
前段时间一直在规划公司新的数据库架构 ， 考虑到我们的业务特点 ， 采用Oracle读写分离的思路 ， Writer DB和Reader DB采用日志复制软件实现实时同步； Writer DB负责交易相关的实时查询和事务处理 ， Reader DB负责只读接入 ， 处理一些非实时的交易明细,报表类的汇总查询等 。 同时 ， 为了满足高可用性和扩展性等要求 ， 对读写端适当做外延 ， 比如Writer DB采用HA或者RAC的架构模式 ， Reader DB可以采用多套 ， 通过负载均衡或者业务分离的方式 ， 有效分担读库的压力 。
对于Shared-nothing的数据库架构模式 ， 核心的一个问题就是读写库的实时同步；另外 ， 虽然Reader DB只负责业务查询 ， 但并不代表数据库在功能上是只读的 。 只读是从应用角度出发 ， 为了保证数据一致和冲突考虑 ， 因为查询业务模块可能需要涉及一些中间处理 ， 如果需要在数据库里面处理(取决与应用需求和设计) ， 所以Reader DB在功能上仍然需要可写 。
下面谈一下数据同步的技术选型问题：
能实现数据实时同步的技术很多 ， 基于OS层(例如VERITAS VVR) ， 基于存储复制(中高端存储大多都支持) ， 基于应用分发或者基于数据库层的技术 。 因为数据同步可能并不是单一的DB整库同步 ， 会涉及到业务数据选择以及多源整合等问题 ， 因此OS复制和存储复制多数情况并不适合做读写分离的技术首选 。
基于日志的Oracle复制技术 ， Oracle自身组件可以实现 ， 同时也有成熟的商业软件 。 选商业的独立产品还是Oracle自身的组件功能 ， 这取决于多方面的因素 。 比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等 。
采用Oracle自身组件功能 ， 无外乎Logical Standby、Stream以及11g的Physical Standby(Active Data Guard) ， 对比来说 ， Stream最灵活 ， 但最不稳定 ， 11g Physical Standby支持恢复与只读并行 ， 但由于并不是日志的逻辑应用机制 ， 在读写分离的场景中最为局限 。 如果技术团队对相关技术掌握足够充分 ， 而选型方案的处理能力又能支撑数据同步的要求 ， 采用Oracle自身的组件完全可行 。
选择商业化的产品 ， 更多出于稳定性、处理能力等考虑 。 市面上成熟的Oracle复制软件也无外乎几种 ， 无论是老牌的Shareplex ， 还是本土DSG公司的RealSync和九桥公司的DDS ， 或是Oracle新贵Goldengate ， 都是可供选择的目标 。 随着GoldenGate被Oracle收购和推广 ， 个人认为GoldenGate在容灾、数据分发和同步方面将大行其道 。
当然 ， 架构好一个可靠的分布式读写分离的系统 ， 还需要应用上做大量设计 ， 不在本文讨论范围内 。
【Reader|Oracle读写分离架构】原文：http://www.easyora.net/blog/oracle_read_write_separated_architecture.html

    推荐阅读


    上一篇：市场|德国一企业入华27年，去年从我国赚走1116.9亿，国人却以为是国企

    下一篇：区块|自主可控96核区块链芯片发布 交易性能提升50倍