|
精华帖 (0) :: 良好帖 (5) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-03-24
楼上的小伙子不错 很谦虚啊 赞一个 javaeye啥时候整体氛围能这样啊。。。
|
| 返回顶楼 | |
|
发表时间：2010-03-24
lishuaibt 写道 楼上的小伙子不错 很谦虚啊 赞一个 javaeye啥时候整体氛围能这样啊。。。
我相信会好的。哈哈 |
| 返回顶楼 | |
|
发表时间：2010-03-28
最后修改：2010-03-28
J-catTeam 写道 seraphim871211 写道 J-catTeam 写道 seraphim871211 写道 J-catTeam 写道 1.一致性hash仅仅是为了不去做数据迁移,但是随之机器的增加会越来越不可用。而且本身的消耗也会增大
这个的依据是什么？ 你好 一致性hash，假设本来应该落在B点的数据，在A，B之间加一台机器，平均有一半的数据会无效。并且A到加的机器点上的数据在B上已经没有用，怎么去清理。随着机器的越来越多，不命中的概率也会越来越多。 虽然说最常用的hash取模不可避免的需要做数据迁移，但是可以选择时间点，比如半夜两点。这个时候访问肯定会很少。 不对的请指教 如果是C、A之间加入节点B，那原来落在CB之间的数据不再找A，而是找B了，这部分数据在A确实是失效。但你说的这个是纯理论。实际中加入B节点之后，CB间的数据（原来命中A上）会逐渐保存到B上（而不是不命中的时候什么都不做），同时A上的数据随着新到数据增加，原来那部分失效数据通过LRU算法将逐渐淘汰掉。所以我觉随着机器增加，不命中的概率不会大幅波动。 事实上，一致性hash就是用来解决存储节点增加导致的命中降低问题的。 实际例子：日本mixi也是逐渐增加到200台以上的memcached服务器集群，用的就是这种方法，并没有你说的问题。 谢谢 ·我只是单纯从理论上做了解释，并没有考虑到很多实际情况。 不觉得有矛盾吗？如果一个问题理论上就不能解决，但实际上是解决了，那肯定是我们对理论理解有偏差。 通常的状态是理论上可以解决，但是由于各种实际情况才会解决不了。 |
| 返回顶楼 | |
|
发表时间：2010-03-28
最后修改：2010-03-28
cx6445 写道 J-catTeam 写道 seraphim871211 写道 J-catTeam 写道 seraphim871211 写道 J-catTeam 写道 1.一致性hash仅仅是为了不去做数据迁移,但是随之机器的增加会越来越不可用。而且本身的消耗也会增大
这个的依据是什么？ 你好 一致性hash，假设本来应该落在B点的数据，在A，B之间加一台机器，平均有一半的数据会无效。并且A到加的机器点上的数据在B上已经没有用，怎么去清理。随着机器的越来越多，不命中的概率也会越来越多。 虽然说最常用的hash取模不可避免的需要做数据迁移，但是可以选择时间点，比如半夜两点。这个时候访问肯定会很少。 不对的请指教 如果是C、A之间加入节点B，那原来落在CB之间的数据不再找A，而是找B了，这部分数据在A确实是失效。但你说的这个是纯理论。实际中加入B节点之后，CB间的数据（原来命中A上）会逐渐保存到B上（而不是不命中的时候什么都不做），同时A上的数据随着新到数据增加，原来那部分失效数据通过LRU算法将逐渐淘汰掉。所以我觉随着机器增加，不命中的概率不会大幅波动。 事实上，一致性hash就是用来解决存储节点增加导致的命中降低问题的。 实际例子：日本mixi也是逐渐增加到200台以上的memcached服务器集群，用的就是这种方法，并没有你说的问题。 谢谢 ·我只是单纯从理论上做了解释，并没有考虑到很多实际情况。 不觉得有矛盾吗？如果一个问题理论上就不能解决，但实际上是解决了，那肯定是我们对理论理解有偏差。 通常的状态是理论上可以解决，但是由于各种实际情况才会解决不了。 不觉得有多大矛盾哈,我说的理论上的缺陷，那位朋友说的对理论上缺陷的在实际中扩展和解决 |
| 返回顶楼 | |
|
发表时间：2010-04-01
seraphim871211 写道 J-catTeam 写道 seraphim871211 写道 J-catTeam 写道 1.一致性hash仅仅是为了不去做数据迁移,但是随之机器的增加会越来越不可用。而且本身的消耗也会增大 这个的依据是什么？ 你好 一致性hash，假设本来应该落在B点的数据，在A，B之间加一台机器，平均有一半的数据会无效。并且A到加的机器点上的数据在B上已经没有用，怎么去清理。随着机器的越来越多，不命中的概率也会越来越多。 虽然说最常用的hash取模不可避免的需要做数据迁移，但是可以选择时间点，比如半夜两点。这个时候访问肯定会很少。 不对的请指教 如果是C、A之间加入节点B，那原来落在CB之间的数据不再找A，而是找B了，这部分数据在A确实是失效。但你说的这个是纯理论。实际中加入B节点之后，CB间的数据（原来命中A上）会逐渐保存到B上（而不是不命中的时候什么都不做），同时A上的数据随着新到数据增加，原来那部分失效数据通过LRU算法将逐渐淘汰掉。所以我觉随着机器增加，不命中的概率不会大幅波动。 事实上，一致性hash就是用来解决存储节点增加导致的命中降低问题的。 实际例子：日本mixi也是逐渐增加到200台以上的memcached服务器集群，用的就是这种方法，并没有你说的问题。 我觉得上述情况不一定会出现。如果节点A的数据因为过期失效后，被淘汰。新数据也会继续插入到A上，数据的key是hash得到的。不会因为是新数据就会插入到后续的节点上。从统计上来说，数据的分布还是平均的。为了进一步避免数据分布不均匀可以使用虚拟节点，不一定要一台物理机器对应一个key。 |
| 返回顶楼 | |
|
发表时间：2010-04-20
虚拟节点跟hash算法可以把哈希失效减到最小,相对与普通hash方法数据迁移时的问题,还是可以接收的....
当然 也是相对来说,如果系统缓存数据量比较稳定,简单的hash取模方法也是十分合适的. |
| 返回顶楼 | |
|
发表时间：2010-04-20
我一直都有一个疑问：就是一旦某台cache server崩溃了（数据量大，或者访问量大）。 数据迁移到下一个节点，导致下一个节点挂掉，如此下去，最后所有崩溃。
这个就不如固定的点的好。 |
| 返回顶楼 | |
|
发表时间：2010-04-25
最后修改：2010-04-25
xiaoyu 写道 我一直都有一个疑问：就是一旦某台cache server崩溃了（数据量大，或者访问量大）。 数据迁移到下一个节点，导致下一个节点挂掉，如此下去，最后所有崩溃。
这个就不如固定的点的好。 这个也是理论上的。 cache客户端使用非同步方式上传数据 cache客户端使用超时失败策略检索数据 cache中的object是软引用或是虚引用。 所以在访问大时会出现大量GC， 使客户端命中失败，节点不会挂掉。 作过700次秒的多线程访问 |
| 返回顶楼 | |
