乔峰和萧远山父子相认# Joke - 肚皮舞运动
k*g
1 楼
一个可以在不同设备上运行的应用，类似Google Keep那样的，怎样解决Sync的问题？
比如，在手机更改了一些内容，但手机当时是离线的状态
回到家里时，手机连上wifi了，正在更新数据，同时电脑上也做了一些编辑...
这个题有什么可以展开的点吗？
比如，在手机更改了一些内容，但手机当时是离线的状态
回到家里时，手机连上wifi了，正在更新数据，同时电脑上也做了一些编辑...
这个题有什么可以展开的点吗？
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？谢谢。
2018年4月下旬收到RFE，6月1号递交了补充材料（体检报告和J表），6月5号收到USCIS
提示他们会重新处理我的case。
我的问题是7月份EB-3倒退到13年1月份，但是我现在还没有收到485被批的消息。像我
这样的情况会因为排期倒退而影响处理吗？如果EB-3不处理，是否要联系律师马上升级
回EB-2？谢谢。
x*o
3 楼
h
z*e
4 楼
gossip
l*e
5 楼
哈哈哈哈哈哈哈哈
r*k
6 楼
没搜到有用的东西
求多几个关键字
【在 z****e 的大作中提到】
: gossip
求多几个关键字
【在 z****e 的大作中提到】
: gossip
s*t
7 楼
为什么灰太狼笑起来像王宝强？
r*k
8 楼
离线的时候就不允许编辑呢？
【在 k***g 的大作中提到】
: 一个可以在不同设备上运行的应用，类似Google Keep那样的，怎样解决Sync的问题？
: 比如，在手机更改了一些内容，但手机当时是离线的状态
: 回到家里时，手机连上wifi了，正在更新数据，同时电脑上也做了一些编辑...
: 这个题有什么可以展开的点吗？
【在 k***g 的大作中提到】
: 一个可以在不同设备上运行的应用，类似Google Keep那样的，怎样解决Sync的问题？
: 比如，在手机更改了一些内容，但手机当时是离线的状态
: 回到家里时，手机连上wifi了，正在更新数据，同时电脑上也做了一些编辑...
: 这个题有什么可以展开的点吗？
d*e
9 楼
lol
s*x
10 楼
不是计算机专业的，个人想法……
标注出修改位置和时间，还有就是对修改进行分类，想
word一样，加字删字是一类，改格式是一类，挪地方是一类，不同类有的有冲突，有的
可以共存，然后同步时就按修改时间先后一个一个处理……好像挪地方可以看成是删除
了再在另一个位置增加……
行外看法……
标注出修改位置和时间，还有就是对修改进行分类，想
word一样，加字删字是一类，改格式是一类，挪地方是一类，不同类有的有冲突，有的
可以共存，然后同步时就按修改时间先后一个一个处理……好像挪地方可以看成是删除
了再在另一个位置增加……
行外看法……
M*9
11 楼
hahahahahaha
【在 x****o 的大作中提到】
: h
【在 x****o 的大作中提到】
: h
x*y
12 楼
It's the situation SCM systems face.
s*l
13 楼
哈哈哈哈哈哈哈哈
是八个哈字吧
这是哪部搞笑电影还是PS的？
是八个哈字吧
这是哪部搞笑电影还是PS的？
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
经典例子就是机器的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
i*0
15 楼
远山的呼唤，很老的电影
【在 s****l 的大作中提到】
: 哈哈哈哈哈哈哈哈
: 是八个哈字吧
: 这是哪部搞笑电影还是PS的？
【在 s****l 的大作中提到】
: 哈哈哈哈哈哈哈哈
: 是八个哈字吧
: 这是哪部搞笑电影还是PS的？
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
所有的天气预报均不可用，因为同样存在
“哪年才能把这个信息传给美国负责手机同步的服务器”
的问题，从欧洲到美国，这有些吃太饱了
你的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
H*g
17 楼
这个片子我听说过，没想到是武侠片。
【在 i*****0 的大作中提到】
: 远山的呼唤，很老的电影
【在 i*****0 的大作中提到】
: 远山的呼唤，很老的电影
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群一般都会选择靠近客户近的地方
: 比如欧洲客户就由北欧的数据中心处理
: 天朝在宁夏或者东京，澳洲东南亚客户就由悉尼负责
: 北美就在西雅图或者科罗拉多之类的
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群一般都会选择靠近客户近的地方
: 比如欧洲客户就由北欧的数据中心处理
: 天朝在宁夏或者东京，澳洲东南亚客户就由悉尼负责
: 北美就在西雅图或者科罗拉多之类的
i*0
19 楼
不是卡通片吗？
【在 H********g 的大作中提到】
: 这个片子我听说过，没想到是武侠片。
【在 H********g 的大作中提到】
: 这个片子我听说过，没想到是武侠片。
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.
美国数据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.
c*a
21 楼
其实是av片，父子俩笑完后就一起去玩苍老师去了。
【在 i*****0 的大作中提到】
: 不是卡通片吗？
【在 i*****0 的大作中提到】
: 不是卡通片吗？
g*e
22 楼
perforce
【在 k***g 的大作中提到】
: 一个可以在不同设备上运行的应用，类似Google Keep那样的，怎样解决Sync的问题？
: 比如，在手机更改了一些内容，但手机当时是离线的状态
: 回到家里时，手机连上wifi了，正在更新数据，同时电脑上也做了一些编辑...
: 这个题有什么可以展开的点吗？
f*p
23 楼
你是从哈这个字拆出来的吧！
【在 c*****a 的大作中提到】
: 其实是av片，父子俩笑完后就一起去玩苍老师去了。
【在 c*****a 的大作中提到】
: 其实是av片，父子俩笑完后就一起去玩苍老师去了。
j*3
24 楼
同问
t*h
25 楼
镶个苍井空的裸像最好
相关阅读