Comments on: 某分布式应用实践一致性哈希的一些问题

By: faryang

faryang — Thu, 01 Jul 2010 16:12:49 +0000

存用户位置的MEMCACHE挂掉怎么办？

By: Tim

Tim — Fri, 21 May 2010 01:44:18 +0000

AFAIK， buddy replication只是一个jboss中一个术语 https://www.redhat.com/docs/manuals/jboss/jboss-eap-4.3/doc/cache/Tree_Cache_Guide/Clustered_Cache___Using_Replication-Buddy_Replication.html 意思是用户session数据可以只复制到少数几台机，和本文并没有直接可比性。

By: bright

bright — Thu, 20 May 2010 14:30:55 +0000

是对buddy replication的改进思路吗？

By: crackcell

crackcell — Tue, 02 Mar 2010 02:20:37 +0000

兄台能否透露下最后的解决方案，我也遇到了类似的问题，希望能借鉴一下前人的经验。

By: NoSQL数据库知识图 | Jerry Mouse

NoSQL数据库知识图 | Jerry Mouse — Sat, 13 Feb 2010 04:44:11 +0000

[...] 附1. 一致性哈希分布 [...]

By: Tim

Tim — Tue, 09 Feb 2010 13:21:26 +0000

上面这篇文章相关consistent hashing问题实际已经解决了，在实际环境运行得还不错，至少上线之后几乎不用为单点故障担心了。相关细节也在前几篇comments里面差不多都有表达。由于后续实践解决思路相比dynamo思想也无新的建树，所以就没专门写文描述了。

fcicq: 你的方案实际跟我的第二阶段相似，存在发生单点故障时候，(1)备份节点负载过大的问题，另外(2)如果node0和node5都crash了系统就会部分(20%)用户服务不可用。而用consistent hashing则不存在上述2个缺陷。

By: fcicq

fcicq — Tue, 09 Feb 2010 10:35:17 +0000

Replication with Consistent Hash Rotation.

Example:
node 0 replicate to node 5, 1 to 6 … f to 4.
in CRC32, just add 0xffffffff / 3 = 0×55555555 to the hash & you got the slave node.
(Why / 3 not / 2 ?)

you know (2 nodes) Tokyo Cabinet, memory(master) -> db file(slave, compressed?).
Just Need Some Hacking. haha.

By: gilbert

gilbert — Tue, 09 Feb 2010 09:58:30 +0000

我感觉你这个需求如果想解决，最终还是要进行多种方案的tradeoff，而tradeoff的根据就是尽量支持优先级高的需求，例如稳定性，或者性能。由于这些涉及到很多细节，估计讨论很难深入下去了~~~

By: csh

csh — Tue, 09 Feb 2010 09:56:38 +0000

我是不是可以这么理解，您的这个管session的进程其实相当于 memcached+session操作逻辑，也就是原本在使用memcached场景中，远程业务层的操作逻辑放到这个管session的进程中，并且在session的分布上使用了vnode?

By: Tim

Tim — Tue, 09 Feb 2010 09:47:40 +0000

如果按你所说多进程的方式的话是需要加业务逻辑。
不过我的是单进程多线程，session只是一个数据结构，比如好友列表/黑名单/隐私设置等业务数据，当然由于多线程访问需要加同步锁保护才能访问，不过这些就说远了。
另外如果多进程我觉得用share memory方式更方便，用erlang轻量级进程语言的话用ets(memory db)也比用message传递要好。