1 分布式选举
http://blog.csdn.net/huangwei19892008/article/details/9004970
bully， 每个机器都知道其他所有机器的编号。 当发现master不工作， 任意机器可发起election，只向编号比它大的发起election； 没收到回复就自己是master、并广播； 有回复的话就自己放弃election、由发回复的继续election过程。
2 一致性hash
在于取模的不同。 如果4台机器， 通常的hash分布， 是将机器顺序编号， 然后将key按4取模； 这样当坏掉或者新增一台机器后，key的 模数会变化，需要迁移的数据量太大大大了。
改为一致性hash的话， 按固定数取模； 当坏掉或者新增机器时，同一key的取模永远不会变化； 坏掉时， 需要迁移的数据只有坏掉机器以前负责的数据； 新增时，只是其中某台机器的一部分数据。
3 一致性hash如何引入权重的概念， 比如某台服务器性能非常好， 想负责多一些数据？
直观想法是将该机器作为两个节点， 参与到一致性hash过程中。
ip1 port1 hashstring1
ip1 port1 hashstring2
ip2 port2 hashstring_ip2
ip3 port3 hashstring_ip3
-----这样配置， 机器1就可能会多负责一些数据、发挥其性能。【hashstring去计算节点的hash值】
虚拟cache服务器： http://blog.csdn.net/x15594/article/details/6270242
==================================
memchache是集中式缓存； 想实现分布式缓存的话， 需要由客户端实现一致性hash， 那么客户端需要知道memcache的机器数？？
客户端可以重新加载或者重启； memcache通过超时失效机制来实现数据的迁走。。
4 分布式锁
锁的创建过程如下描述:
前提:每个锁都需要一个路径来指定(如:/jiacheo/lock)
1.根据指定的路径, 查找zookeeper集群下的这个节点是否存在.(说明已经有锁了)
2. 如果存在, 根据查询者的一些特征数据(如ip地址/hostname), 当前的锁是不是查询者的
3. 如果不是查询者的锁, 则返回null, 说明创建锁失败
4. 如果是查询者的锁, 则把这个锁返回给查询者
5. 如果这个节点不存在, 说明当前没有锁, 那么创建一个临时节点, 并将查询者的特征信息写入这个节点的数据中, 然后返回这个锁.
根据以上5部, 一个分布式的锁就可以创建了.
from： http://www.jiacheo.org/blog/122
需要自己实现集群下文件访问？ 跨主机间的通信， 只能socket了。。？ 那么就需要自定义协议实现这个文件是否存在、创建文件的操作了。
---判断文件是否已经持有锁：给其他广播是否持有锁。。后续挺复杂的？ 必须得有一个leader/master来协调？ 但锁持有者、甚至是当前master持有锁时挂掉， 该如何处理？
如果master永远健康的话， 将master作为锁文件放置的节点即可。
zookeeper。。。？？？
这类缓存系统都无法支持关系数据库的 触发器/存储过程。