Oracle读写分离架构

读写分离是架构分布式系统的一个重要思想。不少系统整体处理能力并不能同业务的增长保持同步,因此势必会带来瓶颈,单纯的升级硬件并不能一劳永逸。针对业务类型特点,需要从架构模式上进行一系列的调整,比如业务模块的分割,数据库的拆分等等。

    集中式和分布式是两个对立的模式,不同行业的应用特点也决定了架构的思路。如互联网行 业中一些门户站点,出于技术和成本等方面考虑,更多的采用开源的数据库产品(如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在容灾、数据分发和同步方面将大行其道。

    当然,架构好一个可靠的分布式读写分离的系统,还需要应用上做大量设计,不在本文讨论范围内。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。