有的是用来『负载均衡』，
有的是用来读写分离（一个应用就写A节点，另外一个应用就是读B节点），
还有的是不同的模块读写不同的节点等等就不一一列举了。
在这个架构下大家都找到了符合自己企业自身的使用方式和方法还是比较灵活的。这些都开发和运维为自己业务量身定做的架构，最符合自己情况。这种下如果让企业放弃原来最适配的架构，那么原本语法兼容、性能兼容等难度较大的基础上又增加了架构适配。
正因为以上这些优点和这些优点所对应的痛点，让用户在经历了这些年分库分表和sharding的架构在经历过数据一致性的问题、业务连续性的中断和应用连接适配的苦恼以后重新审时度势从数据架构上来看待究竟哪种架构能最大限度的满足要求解决痛点。最后发现似乎当初的才是最合适的。所以在国产数据库中不乏有仿造RAC架构的改进。有涉及的包括但不限于以下：达梦、金仓、崖山、Cantian等等。
Oracle的安装现在可以做到一键安装，但是ADG会稍微复杂一点。唯独到了RAC这里安装其实是比较麻烦的。因为实实在在的要和存储打交道，要有多路径软件等工作要做。这是RAC安装中最难的一步。可见难就难在数据库和存储的高度融合。我个人观点Oracle在RAC上的技术，是后来软硬一体（一体机）的基础。
