如何保证两份数据的实时同步情况下提高IO性能？

个人认为，同城容灾的数据同步中，保证同步数据的安全与业务系统的IO性能是一对不易调和的矛盾体，相互影响，相互制约，我们只能根据实际情况折中处理。解决这个矛盾体的根本办法个人认为就是提高同步数据链路的质量，增加链路带宽，降低数据链路的传输延迟。

传统数据库场合下，

我认为这个问题不能从根本上解决，而只能是缓解。这种模式下，如果想保证数据的一致性就必然要牺牲掉IO操作的性能。那么最好的方式就是找一个平衡点，一个从业务上可以接受的平衡点。

如果在保证数据一致性的前提下，想提高性能，那么就要解决数据热点争抢的问题。而这个问题在传统数据库模式下无法得到根本解决。但是可以缓解，也就是说减少热点。具体有以下几个考虑点：

第一、从业务层面本身，可以试图去做一些分离，比如业务类型的分离，读写的分离等。

第二、从数据库本身来讲，可以利用其分区技术，只要在数据库设计的时候，最大限度将数据做到可以分区，那么热点数据就会少。

分布式数据库场合下，

其实所谓分布式数据库，最大的优势在于它能够将数据进行切片，在空间上将其物理分离，但是从逻辑层面上，还是一份统一数据。而且其存储方式以及读写方式和传统数据库发生了质的改变。这种模式的数据库可以最大限度解决数据的热点争抢问题。

但是不是所有的业务特点都符合这一模式的数据库，比如对一个耦合性很高的业务操作，如果前一瞬间的写操作和后一瞬间的读操作分布于两个不同的数据中心，那么从客户角度就会感知到这一数据的不一致性，或者是后一个操作的慢。类似于这样的业务，那么还需要从应用导流方面做到前后的一致性。

综上所述，解决这一问题的途径，一方面在于各个层面的新技术支持。更重要的是需要业务、网络、应用、基础架构、数据库多方面的共同努力。需要根据业务的特点，仔细分析其读写特性，据此设计应用架构、网络架构、基础架构以及数据的模式等，设计出一套特殊的解决方案，而不是一个通用架构。这是是一个复杂的系统问题，解决方案只能有特例，而不存在放之四海皆准的通用解决方案。

个人愚见，偏颇之处，请多见谅。

对于同城灾备的数据同步复制，主要基于有几种方式，一种是基于存储自身的功能进行数据同步，基本上是基于磁盘的BLOCK块和扇区的01数据复制；另一种是基于部分第三方数据同步软件做灾备，这类软件或应用主要是逻辑上的复制，如DSG的复制就是基于sql逻辑层面的同步，而不是底层的磁盘所有01数据保持一致。

于是问题就来了，IO差异就很大，基于物理底层的复制带来了较大的IO，占用的性能较大。而逻辑层面的数据同步就占用的IO较少。灾备或双活数据中心最大的问题在于方案与业务应用系统的结合度怎么样，才不会导致出现“大炮打蚊子或机关枪打飞机”的情况。

在保证数据安全的情况下，必须严格按照灾备方案设计要求文档和同步软件产品文档进行操作和优化。IO的性能提升体现在很多环节上，如存储本身的IO性能、光纤交换机的传输性能、裸光纤的速率限制、应用服务器的FC或网卡速率限制等。

数据同步分为存储层的数据同步，这种同步就必须占用高IO。

因为基本都是从硬盘物理块的01数据进行比对和传输，磁盘某个扇区或某个块有数据变化，就会进行同步。对于这类IO大的数据同步就只有用高IO的存储了，需要多少对裸光纤？，用什么样的存储？8GB的光模块还是用其它规格的？都需要根据业务需求来量身定制。

而定一种数据同步就是指令逻辑型的数据实时同步。例如DSG，DSG也就是根据业务运行过程中，对数据库中执行的sql进行抓取，只传送sql指令，从而达到数据库同步的目的，但这类数据实时同步，其实还是存在一些差异，不能完全达到物理块级的完全一致。如一些rowid、sequence等冲突或不一致，有的同步软件甚至对有一些LOB字段支持性都不太友好。优点是同步占用的带宽少。

要保证两地机房数据实时同步又要保障IO性能，就需要整体对同步方案有很深的理解，对关键影响的因素进行优化，对同步策略进行合理的调整，才能达到用户想要的目的。

全闪存阵列

实时同步与提升IO吞吐能力，这是一对长期存在的矛盾。不过，我们从去年开始做了一些有益的尝试，目前看来，效果还是不错的。但是，这里需要强调一下IO的定义应该是针对全系统的，而不仅仅是某一台机器或设备。

主要原理是这样的，实时同步占用了主设备的IO，可以考虑从备设备提供IO吞吐量来进行弥补。

主要使用的技术是数据库的实时同步备库可读功能，如DB2的HADR可读。

主要看读多写多，如果读多可以快慢配置，如果写多就只能快快配置了