银行跨数据中心数据库双活架构设计的五个难题.docx

? ? ? ? ? ? ? ? 银行跨数据中心数据库双活架构设计的五个难题 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 本文根据社区交流内容整理 难点一：数据库双活，如何解决几十公里延时带来的性能问题？ 分享一： 几十公里的延时主要表现在两方面，一个是存储双写延迟，一个是节点通信延迟。 从存储延时来说首先要做到本地读。这个在GPFS文件系统里是可以做到的。其次是增大缓存，减少同步写的次数。对于数据库里的大对象，最好使用inline的方式放在常规表空间里，或者存放在开启了文件缓存的表空间里。对于数据库日志，一定要设置足够的日志缓冲池，避免因为缓冲池不够发生的同步写。 在通信的延迟上，我们需要做到的是尽量减少通信。所以要想办法解决热点数据问题。同时能够本地访问和缓冲的都要想办法实现。例如推荐采用客户端偏好链接。基于current member来组织表和数据等等。（＠孔再华） 分享二： 我从Oracle数据库层RAC说一下吧，个人比较喜欢用ASM，用ASM可以解决一部分性能问题，之所以说一部分是因为ASM也只能解决读的问题； 由于距离产生的延迟，那么最好的办法就是不缩短距离，这个好像是废话，但是对于Oracle ASM的 redundancy来说其实是可以做到的，比如创建Oracle ASM的磁盘组的时候选择的是Normal redundancy的方式，那么磁盘组就会至少有2个failure group ，而我们可以把2个failure group里的物理盘手工的划分到不同的物理位置，一般双活都有2个机房，那么一个failure group里放一个机房的磁盘，另外一个fialure group里放置另外一个机房的磁盘，这样双活也就实现了，但是随即而来的问题就是物理距离的增加和光信号的衰减和传输的性能降低，Oracle ASM考虑到提升一部分功能，在参数里提供了asm_preferred_read_failure_groups这个参数，也就是说当做物理读的时候每一个机房里的节点（RAC节点）都可以配置自己优先读的“机房” ，这样可以保证“读”不受“距离”的影响，但是“写” 是必须要在双节点都完成的，所以对于ASM来说对于“写”也没有特别好的办法解决距离产生的延迟。当然这个时候如果RAC的节点的使用和划分以及应用层的布置是都慎重考虑的，否则有可能会出现本来业务应该登陆节点1 而因为配置问题却被随机分到了节点2，那这个时候反而适得其反。（＠liuhefromoracle） 分享三： 数据双活和网络延迟的性能问题是一个很难平衡的问题。常见的方案是采用专线连接，更快的服务器，优化的网络基础设施和应用，而且几十公里的距离只能算同城，对于数据双活而言并不是很大的问题，当然也可以选择较近的距离作为数据中心位置。（＠韩成亮） 分享四： 数据写到主服务器，commit时复制到从服务器。复制完毕commit完成。 只有commit有性能问题，是批量操作性质，可以把通信开销降到最低。 但是如果有锁，锁的传递需要时间。 复制时如果从服务器失效，操作应该依然成功，要在主服务器记录从服务器遗漏事务。待从服务器复活，回复遗漏事务。 如果写几千条记录到主服务器，这期间没有复制开销。在commit时复制，产生一个批量传输，开销是很小的。 但是如果主机从机都在录入数据，他们之间是否有重复记录是不易检测的。一个办法是commit时检测，重复数据导致commit失败。如果在恢复遗漏事务时发生重复记录啦，唯一的办法是抛弃重复记录。 所以主从系统需要阶段性一致性检查，如果有不一致数据，以时间戳最新的为准。（＠匿名） 难点二：如何解决热点数据在双活环境的问题？ 分享一： 热点数据是指当前业务频繁访问的数据。如果是单节点数据库，这些数据集中在一起可以提高缓冲池命中率。但是在集群环境恰恰相反！不同数据库成员节点访问同样的热点数据会产生竞争问题。 所以在集群环境，需要考虑热点数据的分布。大的pagesize会存放更多的row，会有更大的概率产生竞争。所以在集群环境，尽量使用小的pagesize， 例如4K。 而对于热点表，我们可用通过在使用分区表等数据库技术来从物理上打散当前的热点数据。例如我们在计费系统的双活环境里面，针对热点的日志表，传统分区表一般使用时间列来组合数据，而我们是用了current member这个变量和序列号组合，做了个隐藏列，实现本地节点插入数据落在自己单独的分区里，同时本地分区也是被轮询使用，彻底打散热点数据。部分定义如下: SERIALIZED_REQUEST BLOB(1048576) INLINE LENGTH 1000 LOGGED NOT COMPACT , CURMEM SMALLINT IMPLICITL