随笔 - 22  文章 - 0 评论 - 136 trackbacks - 19
<2009年3月>
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234

欢迎,第Friend Finder Dating Services位访客
昵称:tmfc
园龄:5年5个月
粉丝:4
关注:0

搜索

 
 

常用链接

我的标签

随笔分类

随笔档案

朋友

积分与排名

  • 积分 - 63130
  • 排名 - 1684

最新评论

阅读排行榜

评论排行榜

推荐排行榜

Hash环

LightCloud使用一致性Hash算法(Consistent Hashing),好处就是当添加新节点的时候不用移动大量数据了。还不知道为什么?Consistent Hashing介绍

一致性Hash算法也不算什么新鲜玩意儿了,凡是分布式系统都不免能见到它的身影,那LightCloud特别之处在哪里呢?好,我们广告之后告诉你……

(可恶的广告)

好,广告之后精彩继续

为了提高可用性,LightCloud使用了数据复制,在正角上场之前,先上一个暖场的,这个暖场的来头还挺大Amazon's Dynamo,先看大屏幕,

图上说了,Key A对应的值会复制三份,分布放在A,B,C节点上(原因不用说了吧),这样做的后果就是系统比较复杂,特别是加入新节点之后,由于Amazon's Dynamo系统本身就设计的比较复杂,这里就不细展开了,有兴趣的同学可以参考链接地址中的论文。

主角上场,主角本身设计的比较简单,还是先看大屏幕

怎么样,有没有看出什么道道来,节点本身复制了,这里是复制了两份,当然你也可以复制三份,第三份甚至可以放在另外的数据中心以提供更高的可靠性。LightCloud的复制用得是底层TokyoTyrant的复制功能,很环保。

解决了复制的问题,还有一个问题就是加入新节点是数据转移的问题,这张图困扰了我很久,大家先仔细品味一下

本来挺简单的一个环,现在变成了两个,上面那个环呢只保存地址,下面那个环才是保存了真正的数据,这样做有什么好处呢?文档也比较简略,没有说清楚,我和作者amix沟通之后,他答应在后续的文档中详细加以说明,留待以后再来分析吧。

和TokyoTyrant通讯

可以通过两种方式和TokyoTyrant通讯:

  •  
    • 使用Tyrant的二进制协议
    • 使用Memcached的协议

默认使用前者,因为是二进制的,而且支持调用Lua扩展,当然如果你愿意,也可以使用Memcached的协议。

posted @ 2009-03-08 20:32 tmfc 阅读(589) 评论(0) 编辑

去年由于工作关系,需要给Memcached选择一种数据压缩算法,参考了2008版的MONSTER OF COMPRESSION,现在2009年度的又新鲜出炉了,有需要的朋友可以去下面看看

MONSTER OF COMPRESSION 2009

由于用于压缩缓存数据,所以重要指标是压缩速度和解压速度,直接参考Ranked on Time of Compression表和Ranked on Time of Decompression

可以发现排在前列的算法就这么几个,而且基本上都是LZ帮派的,其中又以LZ77分舵的气焰最盛,那个速度叫一个块,比7Zip要快15倍,比压缩比最高的NANOZIP要快70多倍。由于MONSTER OF COMPRESSION的压缩测试数据包括非压缩的图片,二进制文件(包括exe和dll),压缩音频,视频等等,LZ帮派基本上压缩率是比较惨的(1G的数据压缩到700多M),但是Memcached缓存的都是什么,都是序列化后的对象,那不就是XML文件吗(当然也可以使用二进制序列化,不在讨论之列)。于是本着认真负责的态度,本人决定测试一下LZ帮的文本压缩能力。

找来找去,去年排名前几的算法,只有QuickLZ(07年还是排名第五的大怪兽今年不知道由于什么原因,没有测试数据)提供了可执行程序(最重要是还有C#版本的库),那就用QuickLZ粗略测试了一下,测试使用了对象序列化后产生的XML文件,具体的成绩已经有些模糊,压缩比应该是在50%左右,这个成绩还真不错,完全可以满足要求。不过最后由于种种原因,没能应用到项目中,所以没法提供更多资料了,大家有兴趣可以自己测试一下实际效果到底如何。

posted @ 2009-03-08 18:52 tmfc 阅读(1552) 评论(3) 编辑