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 | |
