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

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

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

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

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

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

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

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

Galera: 你没看到难道怪我咯

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

这样做的意义是什么？

你想多了。

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

不出两天肯定出岔子

修改数据库 和 备份数据库 这是两个功能
为什么要放在一起。。
分层啊分层

这样做肯定不好。
首先是数据库消耗时间double，你现在可能没有遇到，某些情况下这是不可接受的。
其次是一致性问题。如果没有出错，两个库是完全一致的，看上去很美好。但程序的世界里， 我们得考虑所有可能发生的事情。在第一次写入完成后发生了程序崩溃，系统崩溃，机器断电，网络中断等等问题而导致第二次写入没有成功，就导致了两个库的差异。问题的关键在于， 你这种方案处理这种情况非常麻烦，基本靠人工分析和处理，非常耽误时间。
再次，这样的设计会导致可用性降低。假设单个数据库实例的故障率是P，如果我们只操作一个数据库，那由数据库故障导致的系统不可用概率就是P。这种简单写两个库的方案， 任何一个库故障都会导致系统不可用，其概率是1-(1-P)^2 约等于2P。

相比而言，在存储层去做数据备份和容灾(比如一个非常简单的主从备份)，都不会带来这些问题。

都这样操作，备份软件就没有市场和存在的必要了，也没必要卖十几二十万了！