i**i
发帖数: 1500 | 1 要求：
北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
中心节点的部分数据。
中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
题的时候，可以临时切换到中心节点上，接替子系统工作。
必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
24小时。
最好实现简单，比如，最好自带同步功能。
use case：
可以认为是一个办公软件，平时只和总部（本地）打交道。有时候出差，和总部有联系
，但是主要还是和出差当地打交道。要是某天当地的服务器挂了，可以连上中心服务器
接着玩。
这个系统支持好几千家公司使用这个办公软件。
问题：
1 有神马公司有类似的功能要求，如何解决的？
2 要是你老人家实现这个功能，如何选择技术？
总结一下目前的选择（以牛逼程度排序）：
1. （还木有） |
w***g
发帖数: 5958 | 2 没看出来为啥需要一个城市运行一个子系统。大家都连北京不就得了？
google doc规模肯定比你大，也没见要在每个城市设点啊。
【在 i**i 的大作中提到】
: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：
|
i**i
发帖数: 1500 | 3 几方面的考虑:
1 子系统是可以独立运行的。
2 假定到北京的网速度时快时慢。
就当是要求好了。
【在 w***g 的大作中提到】
: 没看出来为啥需要一个城市运行一个子系统。大家都连北京不就得了？
: google doc规模肯定比你大，也没见要在每个城市设点啊。
|
w***g
发帖数: 5958 | 4 坐等goodbug等牛人回帖。不过我目测10个包子的奖励有点太少，还不如去掉算了。
【在 i**i 的大作中提到】
: 几方面的考虑:
: 1 子系统是可以独立运行的。
: 2 假定到北京的网速度时快时慢。
: 就当是要求好了。
|
w**z
发帖数: 8232 | 5 一天才同步一次？你这要求太低了吧。MySQL cross DC replication应该在几秒之内。
C*可以设read/write, consistency, 可以基本保证data cross DC consistent.
NNetflix 都做到Dc 间的无缝切换了。
【在 i**i 的大作中提到】
: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：
|
n*w
发帖数: 3393 | 6 any database replication, prefer rmdb transactional replication
【在 i**i 的大作中提到】
: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：
|
i**i
发帖数: 1500 | 7 1. 没有更频繁同步的要求。
2. 非多中心的replication.
数据的局部性很强，并且是保密的。一般来说，在一个地方的数据，其他地方不关心。
在偶尔共享的时候，pub-sub就够用了。
【在 w**z 的大作中提到】
: 一天才同步一次？你这要求太低了吧。MySQL cross DC replication应该在几秒之内。
: C*可以设read/write, consistency, 可以基本保证data cross DC consistent.
: NNetflix 都做到Dc 间的无缝切换了。
|
i**i
发帖数: 1500 | 8 包子算个彩头，几位大牛才不惜的几个包子呢。
还是请大伙评出来“最靠谱”比较刺激。
【在 w***g 的大作中提到】
: 坐等goodbug等牛人回帖。不过我目测10个包子的奖励有点太少，还不如去掉算了。
|
p*****2
发帖数: 21240 | 9 跟wdong一个问题 搞到一起算了 security是另外一个话题了
【在 i**i 的大作中提到】
: 包子算个彩头，几位大牛才不惜的几个包子呢。
: 还是请大伙评出来“最靠谱”比较刺激。
|
p***o
发帖数: 1252 | 10 类似google doc的文件数据直接git最简单, 还可以留历史数据，分部定时往中心
push --mirror就好。
【在 i**i 的大作中提到】
: 1. 没有更频繁同步的要求。
: 2. 非多中心的replication.
: 数据的局部性很强，并且是保密的。一般来说，在一个地方的数据，其他地方不关心。
: 在偶尔共享的时候，pub-sub就够用了。
|
|
|
i**i
发帖数: 1500 | 11 有点意思，算一个答案。不过数据不只是文件，更多的是离散数据。
对pptwo的方案重新理解一下就是: 中心是github，同样支持用户和project。子系统是
一个working directory. 文件是json格式。
子系统独立工作，修改json文件。完事把数据push到中心。中心用fswatch监视文件变
化，对变化的数据更新index.
实际上，数据存在nosql数据库里，文件倒不多。
期待更好答案。
【在 p***o 的大作中提到】
: 类似google doc的文件数据直接git最简单, 还可以留历史数据，分部定时往中心
: push --mirror就好。
|
g*****g
发帖数: 34805 | 12 你这个要求太低，怎么做都行。随便上个RDBMS半夜dump再sync。子系统用中心系统备
份只需要切换DNS。
【在 i**i 的大作中提到】
: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：
|
i**i
发帖数: 1500 | 13 标准答案。
就是记录带修改时间戳。然后把修改过的记录dump到中心。
但是非常难调试，经常莫名其妙不对，莫名其妙又好了。
有高招没？
【在 g*****g 的大作中提到】
: 你这个要求太低，怎么做都行。随便上个RDBMS半夜dump再sync。子系统用中心系统备
: 份只需要切换DNS。
|
g*****g
发帖数: 34805 | 14 不要手写，用数据库自带的就容易。你的子系统是source of truth，半夜做个
snapshot扔到中心系统上import，哪需要merge. 需要merge数据库utility也有一堆。
【在 i**i 的大作中提到】
: 标准答案。
: 就是记录带修改时间戳。然后把修改过的记录dump到中心。
: 但是非常难调试，经常莫名其妙不对，莫名其妙又好了。
: 有高招没？
|
c*********e
发帖数: 16335 | 15 为啥要dump在sync,直接sync不行么？
【在 g*****g 的大作中提到】
: 你这个要求太低，怎么做都行。随便上个RDBMS半夜dump再sync。子系统用中心系统备
: 份只需要切换DNS。
|
c*********e
发帖数: 16335 | 16 我朋友公司是一个小时同步一次。就是手写个sql,没啥难的。这是dba的活，和程序员
没啥关系。
【在 i**i 的大作中提到】
: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：
|
n******n
发帖数: 12088 | 17 同问
【在 c*********e 的大作中提到】
: 为啥要dump在sync,直接sync不行么？
|
c*********e
发帖数: 16335 | 18 有个问题你必须考虑，如果sync的中间突然断电或者失去internet联系了怎么办，要
roll back吗？
【在 i**i 的大作中提到】
: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：
|
w**z
发帖数: 8232 | 19 用MySQL 自带master slave replication 不就行了？
【在 c*********e 的大作中提到】
: 我朋友公司是一个小时同步一次。就是手写个sql,没啥难的。这是dba的活，和程序员
: 没啥关系。
|
i**i
发帖数: 1500 | 20 没有mysql. 用的是一种nosql数据库。 高大上的功能一个也木有。
这里所要求的和master slave正好反向吧。
【在 w**z 的大作中提到】
: 用MySQL 自带master slave replication 不就行了？
|
|
|
i**i
发帖数: 1500 | 21 等数据齐了再merge.
【在 c*********e 的大作中提到】
: 有个问题你必须考虑，如果sync的中间突然断电或者失去internet联系了怎么办，要
: roll back吗？
|
i**i
发帖数: 1500 | 22 子系统的数据量也是很大的，不能完全dump再sync。
直接以record为单位sync就可以接受了。再细的话应用部分就复杂得一塌糊涂了。
【在 c*********e 的大作中提到】
: 为啥要dump在sync,直接sync不行么？
|
g*****g
发帖数: 34805 | 23 如果量很大批量不好做，那就应该走event based呀，就像wwzz说的master slave
replication。如果你不需要merge，子系统是single source of the truth，应该可以
做snapshot然后直接在文件级别上替换中心系统上的backup，那样就很快。
【在 i**i 的大作中提到】
: 子系统的数据量也是很大的，不能完全dump再sync。
: 直接以record为单位sync就可以接受了。再细的话应用部分就复杂得一塌糊涂了。
|
i**i
发帖数: 1500 | 24 master/slave 还是要全部数据复制。每个节点和其他节点的数据最终是要同步的。难
道不是吗？
这里的子系统可以很小，但是中心比较大。
不过倒是可以试试拿子系统的journal file在中心上搞一下，看中心能不能被更新。应
该可行。
【在 g*****g 的大作中提到】
: 如果量很大批量不好做，那就应该走event based呀，就像wwzz说的master slave
: replication。如果你不需要merge，子系统是single source of the truth，应该可以
: 做snapshot然后直接在文件级别上替换中心系统上的backup，那样就很快。
|
n****j
发帖数: 1708 | 25 http://docs.mongodb.org/manual/replication/
每个子系统建一个 DB 做 primary ，中心系统 做所有 DB 的secondary |
i**i
发帖数: 1500 | 26 没看见两个primary的用法。
【在 n****j 的大作中提到】
: http://docs.mongodb.org/manual/replication/
: 每个子系统建一个 DB 做 primary ，中心系统 做所有 DB 的secondary
|
n****j
发帖数: 1708 | 27 为啥要 2 个 primary 啊？primary 和 secondary 是热备份的啊，你还可以设定多个
secondary，甚至可以从 secondary 读，写到 primary。
【在 i**i 的大作中提到】
: 没看见两个primary的用法。
|
h**********c
发帖数: 4120 | 28 这种纸上谈兵，来瞎说说吧
bt two decades ago has accomplished what you want to do in a relexed form
but satisfying plus md5 shaxxx validation.
I also say it is really CHEAP.
【在 i**i 的大作中提到】
: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：
|
k**n
发帖数: 3989 | 29 瞎想的：
中心用mongoDB shard, 每个（或几个）shard server 对应一个地方server（s）。每
夜同步或备分。 这样中心有所有数据， 地方有自己数据。
【在 i**i 的大作中提到】
: 要求：
: 北京、上海和另一个城市运行子系统。各子系统功能完全相同，但是子系统数据只包括
: 中心节点的部分数据。
: 中心节点包含各子系统的所有数据，定时或通过请求与子系统同步。定时情况下，可以
: 每天同步一次。同时，中心节点可以作为单个子系统的临时热备份。当某个子系统有问
: 题的时候，可以临时切换到中心节点上，接替子系统工作。
: 必须可靠，不能在异常情况下留下乱糟糟的一坨垃圾数据，或者中心与子系统失步超过
: 24小时。
: 最好实现简单，比如，最好自带同步功能。
: use case：
|
