如果同时将数据写入两个数据库，是不是就打成了同步备份的效果？

[fkbd]

首先将 数据 同时写入A和B数据库
然后在读取时 只读取A数据库
这样做是不是有什么弊端，所以基本没看到有人这么做呢？

相比用其他的软件，感觉这样的方法简单暴力的多。

[ricorico]

1. 删除操作的话，该怎么做呢？
2. 更新操作的话，又该怎么做呢？
3. 数据库称为性能瓶颈的话呢？

[fkbd]

@ricorico 删除和更新也可以同时在两个数据库执行吧。这个同步备份的目的在于程序所在的服务器出现状况的时候，能马上切换到另一个。

[feiandxs]

@ricorico 删除更新和写入可以理解为一个层面的东西，所以反问楼主的点应该是，怎么做到确保一致性呢。。一致性没有就什么都别谈了。
当然伴随而来的就是你的第三点了。。

[xudshen]

大部分数据库都有备份同步功能吧，除非是专门研究这方面，不然就不要造轮子了

[blacktulip]

Master / Slave ，不是楼主的实现方式，不过效果差不多

[em70]

程序效率会有很大问题，小应用可以这样玩

[Tink]

理论来说肯定是能备份的，但是为什么不直接备份数据库呢

[msg7086]

Galera: 你没看到难道怪我咯

还有，你这种在应用层实现的做法是完全错误的。

完全错误，因为你的做法完全依赖执行顺序。如果在多线程下，那么两个线程的执行先后直接会导致一致性问题。

[taogogo]

一旦有一个在写入时网络抖动/故障/升级/重启…

[viator42]

mysql replication, 数据库自己就能干这活的.

[incompatible]

你这样相当于两个数据源 如果不用分布式事务的话，是无法保证一致性的。

在互联网行业，mysql用的比较多，成熟的方案是采用master-slave模式，通过mysql内建的binlog同步的方式来保持slave与master的同步。 在此基础之上，还衍生了读写分离这种减轻数据库压力的性能优化方案。

随手搜了一个文章供参考。 http://blog.csdn.net/mer1234567/article/details/7405775

[SevenJ]

如果就单纯主从这种数据库干的事，为嘛要在应用里头搞

[9hills]

一致性完全没了。。。相信我，你的数据库跑一段时间后，必然出现diff

[evlos]

这个事情交给数据库干就好啦，大部分数据库都自带这个功能。

你自己弄的话会很辛苦，比如一条数据写入数据库 A 的时候是成功的，但是写入 B 失败了。你要侦测这样的错误如果不是从数据库本身做会比较困难。

[9hills]

说到一致性，我厂原来有套存储系统，大约用到两年前才被替换。

这套系统的支持多副本，但是实现方法和lz一样，就是上层业务将数据写入一个cache层，然后cache层复制三份数据发送到不同的副本中，当然由于各种原因，这样显然连最终一致性都保证不了。

我依然能想到当时用户很困惑的问一个问题，为什么同一条记录，第一次访问有，第二次访问（落到另一个副本）就没有了。我们只好灰溜溜的给用户解释，这个系统理论上不是强一致的，而是最终一致的Blabla，但其实最终也不一致。

万万没想到，后面我们终于换了一个强一致的系统，自主研发的。


然后因为一个bug，某些分片的某个副本错误的认为自己没有数据，然后重启集群时因为另外一个bug，强一致到其他分片。。丢了几十亿数据。

[zkd8907]

之前实施Oracle的时候有顾问提到这种技术，建议放在DB层面去处理。比如在Oracle中有一种叫Stream Copy的技术（名字有点忘记了），大致效果是在DB A上执行的所有脚本都会同步传输到DB B中，如果传输过程中出现异常，也会启动相应的事务机制保证下次恢复时的一致性。性能上的话，之前我这里测试一次性INSERT百万条数据的话是可以在约1s的时间内同步（不过这还要取决于服务器性能和网络情况了）

[xiaop]

这样做的意义是什么？

[xcv58]

你想多了。

[SharkIng]

理论上可以，但是写入是需要时间的，如果一段Code同时写入两个数据库所花的时间肯定没有写入一个的有优势，所以为什么要这样做呢？将数据库作为主从数据库然后备份不是更好么？

[cxl008]

不出两天肯定出岔子