Category Archives: 系统架构

一个 gossip 协议满足下面的条件： 1、协议的核心涉及到周期性的、成对的、进程之间的交互。 2、这些交互的信息有一个确定的大小。 3、在交互时，至少一个 agent 的状态改变来反应另一个的状态。 4、不需要可靠的通信。 5、交互的频率低，同令一些典型协议相比，协议的代价可以忽略。 6、对端节点的选择是随机的，节点可以从完整的节点列表选择或者从邻居节点来选择。

redis 确实是个很强的程序，才 1 万多行代码。 http://www.cnblogs.com/lovecindywang/archive/2011/01/12/1933972.html sds.c 是操作字符串的封装文件，首先是一个结构体 sdshdr，然后是 buf。。

本文来自这里：http://timyang.net/data/redis-misunderstanding/。 花点时间研究下。

原文在这里：http://robbin.javaeye.com/blog/524977 随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

Maildir 和 mailbox 应该是最常见的传统的邮箱格式，一个是将用户邮件全部存放于一个文件之中，另一个则将邮件以单个文件的形式存放，一个邮件夹对应磁盘一个目录，而一封邮件对应一个文件，在小规模的应用中 Maildir 大概是没有问题的，但是在海量用户规模和长时间积累的情况下，Maildir 存在很多问题： 1、无法以活跃用户、最热邮件来做区分服务： 在传统的 Maildir 中，所有用户都是平等的，这意味着用户如果长期不登陆，那么它将与经常登录的活跃用户使用同样的存储空间，这明显对于活跃用户不公平； 海量空间甚至不限空间邮箱的出现使得用户很少删除邮件，传统的 Maildir 格式将用户一个邮件夹下的所有邮件都放于同一个磁盘目录，很明显的缺点是：不利于扩容；而且考虑到区分服务的要求，应该将用户很久以前的邮件放到廉价的存储设备上。 2、限制了对新功能的添加： 邮件不止是邮件，很显然会不断添加新功能：比如标签、搜索、会话邮件模式、代办邮件等，在单纯的 Maildir 中是难以做到的。 3、大量实时和随机的存储访问可能导致较高的故障率： 对邮件可能的操作最主要的是打开读取和删除，高峰时类似删除这样的操作应该考虑延迟处理，这可以减少删除操作对存储访问的随机性。如不能区分冷热邮件，此问题会更严重。 4、用户邮件数据过于集中，增加了对存储管理调整的难度和频度： 如果存储设备发生故障，一批用户的所有邮件可能都会受到影响，再实行区分服务和分冷热存储之后，可以将运营重点放在活跃用户和最新收到的邮件上。 因此需要一个高效稳定的系统来达到这样的目标：存储邮件的索引信息（主要是位置和状态）以及较高访问频率的信息；在系统中区分出活跃用户与不活跃用户、新邮件与归档的老邮件；邮件投递时能自动根据配置来将邮件投递到可用的设备上；能根据不同指标（主要是距离当前时刻的时间）来将邮件以不同格式存储，达到尽量节省存储老邮件空间的目的；存储可以线性增长并尽量被顺序访问。

http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/ 为什么需要这种 key-value 系统，而不是传统的关系数据库？同时谈到了一些很有价值的开源软件。 需要知道的几个概念：DHT、Kad、Paxos、Google 三大核心技术等。 十分有价值的一篇文章，作者对当前的key-value store作了整理和归纳和对比，并提出了一下看法。 Baidu 是 Hypertable 的赞助商。