k***g 发帖数: 166 | 1 一个可以在不同设备上运行的应用,类似Google Keep那样的,怎样解决Sync的问题?
比如,在手机更改了一些内容,但手机当时是离线的状态
回到家里时,手机连上wifi了,正在更新数据,同时电脑上也做了一些编辑...
这个题有什么可以展开的点吗? |
z****e 发帖数: 54598 | |
r*******k 发帖数: 1423 | 3 没搜到有用的东西
求多几个关键字
【在 z****e 的大作中提到】 : gossip
|
r*******k 发帖数: 1423 | 4 离线的时候就不允许编辑呢?
【在 k***g 的大作中提到】 : 一个可以在不同设备上运行的应用,类似Google Keep那样的,怎样解决Sync的问题? : 比如,在手机更改了一些内容,但手机当时是离线的状态 : 回到家里时,手机连上wifi了,正在更新数据,同时电脑上也做了一些编辑... : 这个题有什么可以展开的点吗?
|
s**********x 发帖数: 120 | 5 不是计算机专业的,个人想法……
标注出修改位置和时间,还有就是对修改进行分类,想
word一样,加字删字是一类,改格式是一类,挪地方是一类,不同类有的有冲突,有的
可以共存,然后同步时就按修改时间先后一个一个处理……好像挪地方可以看成是删除
了再在另一个位置增加……
行外看法…… |
x***y 发帖数: 633 | 6 It's the situation SCM systems face. |
f***s 发帖数: 112 | 7 没太明白,粗浅理解gossip比较适合对响应不是怎么敏感的boolean信息传递吗?譬如
经典例子就是机器的health信息。
在这个问题场景下怎么解决propagation速度不可控的问题?譬如client在欧洲,手机
在美国,当client上传了一些照片,欧洲的服务器要到哪年才能把这个信息传给美国负
责手机同步的服务器?
我理解这样来处理,一套处理文件的系统,blockserver负责上传数据,并且更新meta
server集群中的信息。
meta server集群中记录文件更改情况和时间,按照时间戳来处理冲突(参考g家牛叉的
spanner)
meta server最后将数据按照primary key进行 partition 然后用consistent hashing
存在不同的存储节点上,存储节点上用leader election写在leader,传递给slaves 用
quorum consistency 保证availability。
当meta server更新结束,给一个distributed queue发送更新指令,说明用户和需要更
新的设备信息,在queue的另一端,接收到指令的server提示和设备保持连接的服务器
推送更新服务的信息 参见spdy 长连接。
【在 z****e 的大作中提到】 : gossip
|
z****e 发帖数: 54598 | 8 gossip一个常见应用是天气预报,如果非要用欧洲和美国来做例子的话
所有的天气预报均不可用,因为同样存在
“哪年才能把这个信息传给美国负责手机同步的服务器”
的问题,从欧洲到美国,这有些吃太饱了
你的meta server如果放在欧洲,客户在美国用server,难道没有类似问题?
跨洲的传输丢包那是惊人的多,而且元数据集中同样增加了风险
负责本地区的server群一般都会选择靠近客户近的地方
比如欧洲客户就由北欧的数据中心处理
天朝在宁夏或者东京,澳洲东南亚客户就由悉尼负责
北美就在西雅图或者科罗拉多之类的
amazon之所以全球建数据中心也是为了这个考虑
比较少说南半球客户由北美数据中心负责
除非不得不这么做,以减少响应时间的差异
gossip到底响应有多及时,完全就是一个scale
看怎么实现,原理都是ap系统,实际上现在前端用cp系统的不太多了
做cp会随着nodes数量增长而拖慢进度
如果保存一下需要半分钟才能完成,或者时不时提示无法完成
估计所有人最后都无法忍受这个app
对文档处理可以保存负责的node处理信息,然后对nodes做一级replica
随机在同一区域找2-3个nodes做一级replica,负责拷贝既时的修改信息
然后再做二级replica,区域内replica,最后global replica
which可能永远都不会做,没有必要
这种机制也同样暗示不要用cp系统,否则要上distributed transaction
要弄is和ix锁,会挂
客户端本身可以保留有一些类似cookie的东西以加强server的处理速度
下次比如欧洲的server收到了处理请求
有cookie的话就可以通知server之前的处理在哪个node上
然后直接去那个server把文件给考过来就好
然后server side再用consistent hashing之类的来分区
严格说来跟consistent hashing其实没啥必然联系
meta
hashing
【在 f***s 的大作中提到】 : 没太明白,粗浅理解gossip比较适合对响应不是怎么敏感的boolean信息传递吗?譬如 : 经典例子就是机器的health信息。 : 在这个问题场景下怎么解决propagation速度不可控的问题?譬如client在欧洲,手机 : 在美国,当client上传了一些照片,欧洲的服务器要到哪年才能把这个信息传给美国负 : 责手机同步的服务器? : 我理解这样来处理,一套处理文件的系统,blockserver负责上传数据,并且更新meta : server集群中的信息。 : meta server集群中记录文件更改情况和时间,按照时间戳来处理冲突(参考g家牛叉的 : spanner) : meta server最后将数据按照primary key进行 partition 然后用consistent hashing
|
f***s 发帖数: 112 | 9 对于跨region丢包的问题的确是不可逾越的瓶颈,除了不断retry还真没啥主意。
http://www.quora.com/Dropbox/What-is-Dropboxs-architecture
其实设计方案也不是我的,从drobpox的talk上面抄来改了下,把后台从mysql
horizontal partition 改成了key value系统,仅仅把mysql 底层的innodb 做文件系
统(Facebook抄过来)用primary key和consistent hashing分区和ring management(
从dynamo抄过来)来处理scalability,当不同region出现conflict,用google
spanner处理.
需要解释的是文件业务系统当然是欧洲和美国分开的,但是meta server还是要同步的
,能想到的就是amazon s3中的dual head link list,每一个在欧洲的文件有一个指向
美国本地的pointer,后台有event机制推送同步,当然是eventual consistency.
【在 z****e 的大作中提到】 : gossip一个常见应用是天气预报,如果非要用欧洲和美国来做例子的话 : 所有的天气预报均不可用,因为同样存在 : “哪年才能把这个信息传给美国负责手机同步的服务器” : 的问题,从欧洲到美国,这有些吃太饱了 : 你的meta server如果放在欧洲,客户在美国用server,难道没有类似问题? : 跨洲的传输丢包那是惊人的多,而且元数据集中同样增加了风险 : 负责本地区的server群一般都会选择靠近客户近的地方 : 比如欧洲客户就由北欧的数据中心处理 : 天朝在宁夏或者东京,澳洲东南亚客户就由悉尼负责 : 北美就在西雅图或者科罗拉多之类的
|
z****e 发帖数: 54598 | 10 干脆就不要垮region存就是solution了
美国数据consistent到欧洲去有啥意义
欧洲要用,那就等欧洲那边有client登陆或者有人share给了欧洲的用户之后
再通知美国这边consistent到那边去
meta data做全球consistent还不是一样的慢?
都eventually consistent还需要做globally consistent么?
所有美国欧洲的数据,都consistent到大洋洲亚洲?没有意义
等亚洲大洋洲有人登陆了再copy过去就好了
绝大多数都不会有这种垮洲处理的问题
而且都eventually consistent了,跟gossip没啥本质区别
那既然是ap系统,scale out就好办了
最需要解决的就是如何通过本地的replica来防止当前处理的node挂掉
这在分布式算法里面有不少方法解决
光看阿三的ppt蹦点产品名词是学不会原理的
persistence用什么,其实无所谓,有什么用什么
原理都是相通的,换个名字换点api而已
而且google spanner这种是有版权的,升级时候api不兼容旧的api
到时候就麻烦了,这种事太常见
一般首选还都是apache,战斗的民族比较靠谱
【在 f***s 的大作中提到】 : 对于跨region丢包的问题的确是不可逾越的瓶颈,除了不断retry还真没啥主意。 : http://www.quora.com/Dropbox/What-is-Dropboxs-architecture : 其实设计方案也不是我的,从drobpox的talk上面抄来改了下,把后台从mysql : horizontal partition 改成了key value系统,仅仅把mysql 底层的innodb 做文件系 : 统(Facebook抄过来)用primary key和consistent hashing分区和ring management( : 从dynamo抄过来)来处理scalability,当不同region出现conflict,用google : spanner处理. : 需要解释的是文件业务系统当然是欧洲和美国分开的,但是meta server还是要同步的 : ,能想到的就是amazon s3中的dual head link list,每一个在欧洲的文件有一个指向 : 美国本地的pointer,后台有event机制推送同步,当然是eventual consistency.
|
g*********e 发帖数: 14401 | 11
perforce
【在 k***g 的大作中提到】 : 一个可以在不同设备上运行的应用,类似Google Keep那样的,怎样解决Sync的问题? : 比如,在手机更改了一些内容,但手机当时是离线的状态 : 回到家里时,手机连上wifi了,正在更新数据,同时电脑上也做了一些编辑... : 这个题有什么可以展开的点吗?
|
j**********3 发帖数: 3211 | |