d***n 发帖数: 832 | 1 之前一点都不了解,看过之后明白不少
http://www.youtube.com/watch?v=2RfBHqDWa60&list=PLZPOM6MLuuhEVj
Summary
Like a file system, except distributed & replicated
Build distributed coordination, data structures, etc.
High-availability, reliability
Automatic session failover, keep-alive
Writes via leader, in memory reads (fast) |
J****3 发帖数: 427 | |
p*****3 发帖数: 488 | |
d***n 发帖数: 832 | 4 三爷这个贴的非常经典
再来贴一个关于multi-paxos的入门贴,是一位berkley的小姑娘(看起来是华裔)写的,
刚毕业一年多
Multi-Paxos
http://amberonrails.com/paxosmulti-paxos-algorithm/
感觉学习zookeeper看我说的这个视频
再加正式文档入门完全够了 |
d***n 发帖数: 832 | 5 顺便说一下,发明paxos的大牛Leslie现在微软研究院
google chubby的作者说这是唯一work的consensus算法
http://the-paper-trail.org/blog/consensus-protocols-two-phase-c |
z****e 发帖数: 54598 | 6 也是最简单的consensus算法
其实只要说是voting system
应该所有人都能想到是这么一回事
【在 d***n 的大作中提到】 : 顺便说一下,发明paxos的大牛Leslie现在微软研究院 : google chubby的作者说这是唯一work的consensus算法 : http://the-paper-trail.org/blog/consensus-protocols-two-phase-c
|
g**e 发帖数: 6127 | 7 zookeeper支持高并发,能做resource locking么?amzn内部几个principal engineer
自己实现了一套基于paxos的distributed locking系统,这玩意不支持高并发,只能用
来做role locking.
【在 z****e 的大作中提到】 : 也是最简单的consensus算法 : 其实只要说是voting system : 应该所有人都能想到是这么一回事
|
z****e 发帖数: 54598 | 8 不知道啊,新东西我也在学习,你们搞定后记得share一下经验啊
engineer
【在 g**e 的大作中提到】 : zookeeper支持高并发,能做resource locking么?amzn内部几个principal engineer : 自己实现了一套基于paxos的distributed locking系统,这玩意不支持高并发,只能用 : 来做role locking.
|
|
z****e 发帖数: 54598 | |
g**e 发帖数: 6127 | 10 http://zookeeper.apache.org/doc/trunk/zookeeperOver.html#Perfor
这一类voting system不容易支持高并发写操作,server越多,需要同步的write越多。
另外一个问题是death spiral,没详细读文档不知他们怎么解决的。假设有非常多的
client连到zookeeper,这时候it挂了,再次重启的时候除了要恢复以前的状态(比如把
znode读到内存中),还要处理大量的client reconnect请求,很容易直接把service再
次弄挂掉,循环往复
能用
【在 z****e 的大作中提到】 : 不知道啊,新东西我也在学习,你们搞定后记得share一下经验啊 : : engineer
|
|
|
s********k 发帖数: 6180 | 11 这个是不是就是类似当年AWS那次挂掉的原因,某个主要节点挂掉,其他的节点拼命去
同步结果congest了导致crash
【在 g**e 的大作中提到】 : http://zookeeper.apache.org/doc/trunk/zookeeperOver.html#Perfor : 这一类voting system不容易支持高并发写操作,server越多,需要同步的write越多。 : 另外一个问题是death spiral,没详细读文档不知他们怎么解决的。假设有非常多的 : client连到zookeeper,这时候it挂了,再次重启的时候除了要恢复以前的状态(比如把 : znode读到内存中),还要处理大量的client reconnect请求,很容易直接把service再 : 次弄挂掉,循环往复 : : 能用
|
z****e 发帖数: 54598 | 12 我昨天跟周边的人讨论了一下
我们是这么做的
用zookepper一个管一个cluster
但是我们同时部署多个zookeeper
然后如果需要voting system的话
分派下去,一个独立的zookeeper拿到之后,锁住,取结果,释放锁,反馈
最后master node拿到所有结果之后,reduce
只要收集到一定程度的结果,就返回
这样就不依赖一个zookeeper的实现,而是变成一小块一小块
【在 g**e 的大作中提到】 : http://zookeeper.apache.org/doc/trunk/zookeeperOver.html#Perfor : 这一类voting system不容易支持高并发写操作,server越多,需要同步的write越多。 : 另外一个问题是death spiral,没详细读文档不知他们怎么解决的。假设有非常多的 : client连到zookeeper,这时候it挂了,再次重启的时候除了要恢复以前的状态(比如把 : znode读到内存中),还要处理大量的client reconnect请求,很容易直接把service再 : 次弄挂掉,循环往复 : : 能用
|
t**r 发帖数: 3428 | |
s*****r 发帖数: 43070 | 14 zookeeper相当于一个小型的meata data DB,主要拿来当configuration server用的,
不需要支持高并发,最大要求是稳定实时,你在一个zookeeper server上加了meta
data,其他server应该马上就有这个configuration
高并发不一定会有heavy resource locking,抢火车票是经典的resource locking问题
,大家一起发贴发微信,每个action只lock个人的resource,不是啥大问题,如果DB扛
不住就sharding
paxos拿来解决distributed db的transaction locking,比传统的two phase locking
要有效。
【在 z****e 的大作中提到】 : 不知道啊,新东西我也在学习,你们搞定后记得share一下经验啊 : : engineer
|
d********i 发帖数: 582 | |
r****c 发帖数: 2585 | 16 恩 其实有些physical limit不能老靠db解决,如日你一个single shared counter,又
要写在数据库里,又要支持几万qps,就要另想法子了,在application level上解决。 |
a***w 发帖数: 168 | 17 正解, zk解决的问题是high availability, 不是high concurrency
locking
【在 s*****r 的大作中提到】 : zookeeper相当于一个小型的meata data DB,主要拿来当configuration server用的, : 不需要支持高并发,最大要求是稳定实时,你在一个zookeeper server上加了meta : data,其他server应该马上就有这个configuration : 高并发不一定会有heavy resource locking,抢火车票是经典的resource locking问题 : ,大家一起发贴发微信,每个action只lock个人的resource,不是啥大问题,如果DB扛 : 不住就sharding : paxos拿来解决distributed db的transaction locking,比传统的two phase locking : 要有效。
|
t****d 发帖数: 423 | |
j**********3 发帖数: 3211 | |
w*****x 发帖数: 11 | |
s**********a 发帖数: 37 | |
l****6 发帖数: 1180 | |