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在容灾、数据分发和同步方面将大行其道。

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