Redian新闻
>
乔峰和萧远山父子相认
avatar
乔峰和萧远山父子相认# Joke - 肚皮舞运动
k*g
1
一个可以在不同设备上运行的应用,类似Google Keep那样的,怎样解决Sync的问题?
比如,在手机更改了一些内容,但手机当时是离线的状态
回到家里时,手机连上wifi了,正在更新数据,同时电脑上也做了一些编辑...
这个题有什么可以展开的点吗?
avatar
w*h
2
我的PD是2013年12月EB-2,后来降级到EB-3。
2018年4月下旬收到RFE,6月1号递交了补充材料(体检报告和J表),6月5号收到USCIS
提示他们会重新处理我的case。
我的问题是7月份EB-3倒退到13年1月份,但是我现在还没有收到485被批的消息。像我
这样的情况会因为排期倒退而影响处理吗?如果EB-3不处理,是否要联系律师马上升级
回EB-2?谢谢。
avatar
x*o
3
h
avatar
z*e
4
gossip
avatar
l*e
5
哈哈哈哈哈哈哈哈
avatar
r*k
6
没搜到有用的东西
求多几个关键字

【在 z****e 的大作中提到】
: gossip
avatar
s*t
7
为什么灰太狼笑起来像王宝强?
avatar
r*k
8
离线的时候就不允许编辑呢?

【在 k***g 的大作中提到】
: 一个可以在不同设备上运行的应用,类似Google Keep那样的,怎样解决Sync的问题?
: 比如,在手机更改了一些内容,但手机当时是离线的状态
: 回到家里时,手机连上wifi了,正在更新数据,同时电脑上也做了一些编辑...
: 这个题有什么可以展开的点吗?

avatar
d*e
9
lol
avatar
s*x
10
不是计算机专业的,个人想法……
标注出修改位置和时间,还有就是对修改进行分类,想
word一样,加字删字是一类,改格式是一类,挪地方是一类,不同类有的有冲突,有的
可以共存,然后同步时就按修改时间先后一个一个处理……好像挪地方可以看成是删除
了再在另一个位置增加……
行外看法……
avatar
M*9
11
hahahahahaha

【在 x****o 的大作中提到】
: h
avatar
x*y
12
It's the situation SCM systems face.
avatar
s*l
13
哈哈哈哈哈哈哈哈
是八个哈字吧
这是哪部搞笑电影还是PS的?
avatar
f*s
14
没太明白,粗浅理解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
avatar
i*0
15
远山的呼唤,很老的电影

【在 s****l 的大作中提到】
: 哈哈哈哈哈哈哈哈
: 是八个哈字吧
: 这是哪部搞笑电影还是PS的?

avatar
z*e
16
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

avatar
H*g
17
这个片子我听说过,没想到是武侠片。

【在 i*****0 的大作中提到】
: 远山的呼唤,很老的电影
avatar
f*s
18
对于跨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群一般都会选择靠近客户近的地方
: 比如欧洲客户就由北欧的数据中心处理
: 天朝在宁夏或者东京,澳洲东南亚客户就由悉尼负责
: 北美就在西雅图或者科罗拉多之类的

avatar
i*0
19
不是卡通片吗?

【在 H********g 的大作中提到】
: 这个片子我听说过,没想到是武侠片。
avatar
z*e
20
干脆就不要垮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.

avatar
c*a
21
其实是av片,父子俩笑完后就一起去玩苍老师去了。

【在 i*****0 的大作中提到】
: 不是卡通片吗?
avatar
g*e
22

perforce

【在 k***g 的大作中提到】
: 一个可以在不同设备上运行的应用,类似Google Keep那样的,怎样解决Sync的问题?
: 比如,在手机更改了一些内容,但手机当时是离线的状态
: 回到家里时,手机连上wifi了,正在更新数据,同时电脑上也做了一些编辑...
: 这个题有什么可以展开的点吗?

avatar
f*p
23
你是从哈这个字拆出来的吧!

【在 c*****a 的大作中提到】
: 其实是av片,父子俩笑完后就一起去玩苍老师去了。
avatar
j*3
24
同问
avatar
t*h
25
镶个苍井空的裸像最好
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。