这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 3550 天前的主题，其中的信息可能已经有所发展或是发生改变。
首先将 数据 同时写入A和B数据库
然后在读取时 只读取A数据库
这样做是不是有什么弊端，所以基本没看到有人这么做呢？
相比用其他的软件，感觉这样的方法简单暴力的多。
然后在读取时 只读取A数据库
这样做是不是有什么弊端，所以基本没看到有人这么做呢？
相比用其他的软件，感觉这样的方法简单暴力的多。
 |
1
ricorico 2015-02-26 19:16:28 +08:00  1
1. 删除操作的话，该怎么做呢？
2. 更新操作的话，又该怎么做呢？ 3. 数据库称为性能瓶颈的话呢？ |
 |
2
fkbd OP @ricorico 删除和更新也可以同时在两个数据库执行吧。这个同步备份的目的在于程序所在的服务器出现状况的时候，能马上切换到另一个。
|
 |
3
feiandxs 2015-02-26 19:20:43 +08:00 1
@ricorico 删除更新和写入可以理解为一个层面的东西，所以反问楼主的点应该是，怎么做到确保一致性呢。。一致性没有就什么都别谈了。
当然伴随而来的就是你的第三点了。。 |
 |
4
xudshen 2015-02-26 19:22:05 +08:00 via iPhone 1
大部分数据库都有备份同步功能吧，除非是专门研究这方面，不然就不要造轮子了
|
 |
5
blacktulip 2015-02-26 19:22:37 +08:00 1
Master / Slave ，不是楼主的实现方式，不过效果差不多
|
 |
6
em70 2015-02-26 19:25:22 +08:00 via Android 1
程序效率会有很大问题，小应用可以这样玩
|
 |
7
Tink 2015-02-26 19:33:44 +08:00
理论来说肯定是能备份的，但是为什么不直接备份数据库呢
|
 |
8
msg7086 2015-02-26 22:15:00 +08:00 via iPhone
Galera: 你没看到难道怪我咯
还有，你这种在应用层实现的做法是完全错误的。 完全错误，因为你的做法完全依赖执行顺序。如果在多线程下，那么两个线程的执行先后直接会导致一致性问题。 |
 |
9
taogogo 2015-02-26 22:33:36 +08:00
一旦有一个在写入时网络抖动/故障/升级/重启…
|
 |
10
viator42 2015-02-26 22:40:39 +08:00
mysql replication, 数据库自己就能干这活的.
|
 |
11
incompatible 2015-02-26 22:40:46 +08:00
你这样相当于两个数据源 如果不用分布式事务的话，是无法保证一致性的。
在互联网行业，mysql用的比较多，成熟的方案是采用master-slave模式，通过mysql内建的binlog同步的方式来保持slave与master的同步。 在此基础之上，还衍生了读写分离这种减轻数据库压力的性能优化方案。 随手搜了一个文章供参考。 http://blog.csdn.net/mer1234567/article/details/7405775 |
 |
12
SevenJ 2015-02-26 22:42:58 +08:00
如果就单纯主从这种数据库干的事，为嘛要在应用里头搞
|
 |
13
9hills 2015-02-26 23:52:49 +08:00 via iPad
一致性完全没了。。。相信我，你的数据库跑一段时间后，必然出现diff
|
 |
14
evlos 2015-02-26 23:56:31 +08:00
这个事情交给数据库干就好啦，大部分数据库都自带这个功能。
你自己弄的话会很辛苦，比如一条数据写入数据库 A 的时候是成功的，但是写入 B 失败了。你要侦测这样的错误如果不是从数据库本身做会比较困难。 |
|
15
9hills 2015-02-27 00:03:42 +08:00 via iPad
说到一致性，我厂原来有套存储系统，大约用到两年前才被替换。
这套系统的支持多副本，但是实现方法和lz一样，就是上层业务将数据写入一个cache层，然后cache层复制三份数据发送到不同的副本中，当然由于各种原因，这样显然连最终一致性都保证不了。 我依然能想到当时用户很困惑的问一个问题，为什么同一条记录，第一次访问有，第二次访问（落到另一个副本）就没有了。我们只好灰溜溜的给用户解释，这个系统理论上不是强一致的，而是最终一致的Blabla，但其实最终也不一致。 万万没想到，后面我们终于换了一个强一致的系统，自主研发的。 然后因为一个bug，某些分片的某个副本错误的认为自己没有数据，然后重启集群时因为另外一个bug，强一致到其他分片。。丢了几十亿数据。 |
 |
16
zkd8907 2015-02-27 00:07:11 +08:00
之前实施Oracle的时候有顾问提到这种技术，建议放在DB层面去处理。比如在Oracle中有一种叫Stream Copy的技术（名字有点忘记了），大致效果是在DB A上执行的所有脚本都会同步传输到DB B中，如果传输过程中出现异常，也会启动相应的事务机制保证下次恢复时的一致性。性能上的话，之前我这里测试一次性INSERT百万条数据的话是可以在约1s的时间内同步（不过这还要取决于服务器性能和网络情况了）
|
 |
17
xiaop 2015-02-27 00:49:05 +08:00 via iPhone
这样做的意义是什么？
|
 |
18
xcv58 2015-02-27 01:42:26 +08:00
你想多了。
|
 |
19
SharkIng 2015-02-27 01:59:51 +08:00
理论上可以，但是写入是需要时间的，如果一段Code同时写入两个数据库所花的时间肯定没有写入一个的有优势，所以为什么要这样做呢？将数据库作为主从数据库然后备份不是更好么？
|
 |
20
cxl008 2015-02-27 11:08:13 +08:00
不出两天肯定出岔子
|
 |
21
kzzhr 2015-02-27 11:56:54 +08:00
修改数据库 和 备份数据库 这是两个功能
为什么要放在一起。。 分层啊分层 |
 |
22
duzhe0 2015-02-27 18:05:31 +08:00
这样做肯定不好。
首先是数据库消耗时间double，你现在可能没有遇到，某些情况下这是不可接受的。 其次是一致性问题。如果没有出错，两个库是完全一致的，看上去很美好。但程序的世界里， 我们得考虑所有可能发生的事情。在第一次写入完成后发生了程序崩溃，系统崩溃，机器断电，网络中断等等问题而导致第二次写入没有成功，就导致了两个库的差异。问题的关键在于， 你这种方案处理这种情况非常麻烦，基本靠人工分析和处理，非常耽误时间。 再次，这样的设计会导致可用性降低。假设单个数据库实例的故障率是P，如果我们只操作一个数据库，那由数据库故障导致的系统不可用概率就是P。这种简单写两个库的方案， 任何一个库故障都会导致系统不可用，其概率是1-(1-P)^2 约等于2P。 相比而言，在存储层去做数据备份和容灾(比如一个非常简单的主从备份)，都不会带来这些问题。 |
 |
23
shendancan 2015-03-04 09:02:33 +08:00
都这样操作，备份软件就没有市场和存在的必要了，也没必要卖十几二十万了！
|
Select Language