IT技术博客大学习

Nginx使用Linux内存加速静态文件访问

Elton — Thu, 17 May 2012 23:51:28 +0800

标签： Nginx

Nginx是一个非常出色的静态资源web服务器。如果你嫌它还不够快，可以把放在磁盘中的文件，映射到内存中，减少高并发下的磁盘IO。

先做几个假设。nginx.conf中所配置站点的路径是/home/wwwroot/res，站点所对应文件原始存储路径：/opt/web/res

shell脚本非常简单，思路就是拷贝资源文件到内存中，然后在把网站的静态文件链接指向到内存中即可。具体如下：

#! /bin/bash   
 
res_path="/opt/web/res"  
mem_path="/dev/shm/res"  
lk_path="/home/wwwroot/res"  
 
if [ ! -d "$mem_path" ]; then  
        cp -r "$res_path" "$mem_path"  
fi  
 
if [ ! -L "$lk_path" ]; then  
        ln -s "$mem_path" "$lk_path"  
fi

===================
更新测试数据

利用上述方法，在公司的测试服务器上做了个测试，速度提升明显，速度几乎翻倍。

测试前提：将测试网站的首页全部内容包括html，图片，js，css等所有元素都拷贝到内存中,并且每次用户请求静态资源文件都不会缓存。使用LoadRunner按照200和100并发分别进行压力测试。

测试结果:

在高并发下全部使用磁盘文件200人并发 2分钟平均每次事务响应时间为19.96秒每秒处理事务数为9.26个
使用内存200人并发 2分钟平均每次事务响应时间为11.3秒每秒处理事务数为15.8个
在低并发下全部使用磁盘文件100人并发 2分钟平均每次事务响应时间为10.27秒每秒处理事务数为9.32个
使用内存100人并发 2分钟平均每次事务响应时间为5.84秒每秒处理事务数为16.17个

您可能还对下面的文章感兴趣：

在 MogileFS 中使用 Nginx [2012-03-11 22:19:49]
重负荷nginx的几个关键配置参数 [2012-03-04 17:52:57]
使用nginx记日志 [2012-01-27 18:49:29]
nginx防hashdos模块使用帮助 [2012-01-16 00:03:36]
Nginx 还是 Varnish? [2011-11-23 23:56:28]
检查nginx配置，重载配置以及重启的方法 [2011-11-06 22:33:52]
Varnish VS Nginx测试报告 [2011-10-17 22:40:15]
nginx 使用 ssl [2011-10-14 13:48:26]
nginx的配置文件 [2011-10-12 00:14:03]
使用memc-nginx和srcache-nginx构建高效透明的缓存机制 [2011-10-11 23:47:31]
使用memc-nginx和srcache-nginx模块构建高效透明的缓存机制 [2011-10-04 18:01:01]
解决 nginx 反向代理网页首尾出现神秘字符的问题 [2011-07-18 23:28:37]
Nginx模块开发入门 [2011-07-18 13:36:53]
Nginx+FastCgi+Php 的工作机制 [2011-06-01 13:41:04]
nginx的upstream目前支持5种方式的分配 [2011-01-23 23:03:43]
使用fastcgi_cache加速你的Nginx网站 [2011-01-05 22:44:49]
Nginx源码分析-内存池 [2011-01-05 03:31:14]
深入理解Nginx之调试优化技巧 [2010-12-21 01:57:16]
Nginx源码分析-事件循环 [2010-12-21 01:55:06]
nginx模块开发 [2010-12-21 01:52:06]
Nginx的connections数组 [2010-12-14 21:58:24]
Nginx的master和worker进程间的通信 [2010-12-05 21:29:03]
Nginx启动初始化过程(二) [2010-12-02 22:32:44]
Nginx启动初始化过程（一） [2010-12-02 22:32:15]
Nginx进程管理之worker进程 [2010-12-02 22:31:28]
Nginx进程管理之master进程 [2010-11-28 18:58:18]
nginx.conf控制指定的代理ip和ip访问的设置手记 [2010-10-17 22:21:49]
配置Nginx＋uwsgi更方便地部署python应用 [2010-10-11 00:56:53]
使用 Perl 来开发 Nginx 的模块 [2010-09-26 08:57:47]
nginx在fastcgi模块中转发真实的后端IP [2010-09-01 10:28:26]
当使用 Nginx 做 Hash 时对动态文件和静态文件的处理 [2010-08-02 22:59:10]
解决IE6从Nginx服务器下载图片不Cache的Bug [2010-06-27 22:19:15]
搜狐闪电邮箱的 Nginx/Postfix 使用模式 [2010-06-12 09:43:51]
nginx的upstream目前支持5种方式的分配 [2010-06-03 13:15:43]
Cacti 添加 Nginx 监控 [2010-05-26 13:22:17]
nginx文件类型错误解析漏洞 [2010-05-22 15:14:27]
Nginx的启动、停止、重启、升级操作总结 [2010-05-22 12:58:47]
再提供一种解决Nginx文件类型错误解析漏洞的方法 [2010-05-22 12:55:02]
Nginx 反盗链设置 [2010-05-12 13:21:13]
通过Nginx使全站页面变灰，哀悼玉树地震遇难者 [2010-04-27 13:45:34]
配置nginx [2010-03-29 08:56:55]
nginx mail模块的学习 [2010-03-07 23:29:14]
使用nginx做为hiphop-php的前端服务器 [2010-03-01 13:39:10]
PHP上传文件类型彻底判断方案及PHP＋nginx上传大小彻底控制方案 [2010-01-13 14:09:53]
nginx mail模块的学习 [2010-01-04 16:04:29]
ubuntu 9.10快速安装nginx+php环境手记 [2009-12-24 23:55:20]
nginx upstream 的几种分配方式 [2009-12-11 22:55:59]
Bo-Blog 2.1.1 的 Nginx Rewrite 规则[原创] [2009-11-30 16:21:57]
Nginx(PHP/fastcgi)的PATH_INFO问题 [2009-11-19 09:36:14]
多nginx单php-fpm的配置方法 [2009-11-16 23:15:26]
nginx中对http请求处理的各个阶段分析 [2009-11-15 19:21:08]
nginx源码分析-共享内存 [2009-11-15 19:18:23]
利用nginx secure link module防盗链 [2009-10-29 12:00:02]

基于综合兴趣度的协同过滤推荐算法

标点符 — Thu, 17 May 2012 23:50:22 +0800

标签： 兴趣协同过滤推荐

1 概述

电子商务推荐系统最大的优点在于它能收集用户的兴趣资料和个人信息，根据用户兴趣偏好主动为用户做出个性化推荐。推荐技术指的是如何找出用户感兴趣的商品并列出推荐清单，在用户信息获取差别不大的情况下，推荐技术成为决定一个推荐系统性能的关键，其中推荐算法是推荐技术的核心[1]。

协同过滤技术是实际应用中使用最广泛的推荐技术，包括Amazon.com 在内许多网上书店都在使用协同过滤技术。协同过滤是一种基于用户间关联性的推荐算法，该推荐方法将购买习惯或兴趣相同的用户归类在同一个群体中，同群体内的用户彼此之间可以分享信息，互相推荐商品。应用协同过滤技术的著名的推荐系统包括GroupLens/NetPerceptions[2], Ringo/Firefly[3], Tapestry[4]等。协同过滤技术存在的不足主要表现为最近邻居的准确性问题，即在客户对商品评分数据比较少的时候，单纯地使用客户的注册兴趣信息和评分数据难以准确地确定最近邻居，从而导致推荐质量降低，这种问题是协同过滤技术本身无法克服的，需要对其进行改进。

本文针对协同过滤算法中的最近邻居判断准确性问题，综合显性兴趣度、隐形兴趣度和预测兴趣度3 种用户兴趣指标提出了综合兴趣度的概念，并将这种基于综合兴趣度的协同过滤方法应用于一种图书推荐系统中。实验结果表明，该方法提高了计算用户最近邻居的准确性，进而对推荐系统的推荐质量起到了明显的优化作用。

2 基于综合兴趣度的协同过滤方法

协同过滤方法的关键在于确定用户的最近邻居，确定最近邻居的基础是计算用户之间的相似性，兴趣度是计算用户相似性的重要指标。一般来说，用户相似性计算方法包括余弦相似性、修正的余弦相似性、相关相似性等[5]。传统的兴趣度计算方法主要考虑用户提供的注册信息和显性商品评分，即显性兴趣度，由于显性兴趣不能完整地体现用户真实兴趣，因此上述3 种方法在单纯采用显性兴趣度计算用户相似性方面均存在一定的缺陷[6]。采用余弦相似性度量时，对于未评分商品的兴趣评分都设为0，即兴趣度相同，但事实上用户对未评商品类的兴趣度不可能完全相同。修正的余弦相似性采取了对未评分项目设置平均评分值的改良措施，但仍未有效解决问题。

相关相似性度量仅对都有评分的项目进行度量，这在有共同评分项目较多的情况下较为准确，若在共同评分项目较少时，则偏差可能较大。

在心理学中，人的兴趣包括主观的表述、客观的描述及基于知识和经验有可能发生的兴趣预期。具体到推荐系统中，主观的兴趣表述可以理解为用户在兴趣调查表中主动提供本人的兴趣倾向，这种表述相对固定，属于显性兴趣度。用户的浏览行为反映了用户的实际需要，浏览的行为不断变动往往表示原有兴趣的调整，这是用户兴趣的客观描述，属于隐性兴趣度。

在用户的未评分项目中，用户未来的评分可通过分析项目的特性和用户的兴趣规律进行预测，这是根据已有资料对用户兴趣的合理预期，属于预测兴趣度。一些学者在研究中提到了利用用户浏览行为计算用户隐性兴趣度[7]或用商品间的关联信息预测用户对某些商品的评分情况[8]的思想，但这些方法仅考虑了用户兴趣中的一部分，并没有完整地描述用户兴趣。

因此，本文提出了结合显性兴趣度、隐性兴趣度(统称为已有兴趣度)和预测兴趣度的综合兴趣度的概念，综合兴趣度能使用户间的相似性度量更为准确，更完整地反映用户的兴趣倾向。基于综合兴趣度的协同过滤方法包括以下步骤：

获取用户对商品的兴趣评分，结合对用户浏览行为的分析得到已有兴趣度；

结合已有兴趣度和预测兴趣度，分析用户之间兴趣的相似程度，选取一群与用户有相近兴趣的最近邻居；

从最近邻居感兴趣的商品中，预测用户对某一商品的喜好，最终产生推荐结果。

2.1 已有兴趣度的获取

很多早期的协同过滤系统往往只采用显性兴趣度产生推荐，显性评分的信息一般较为准确，但由于用户注册时一般填写的项目不多，用户有共同显性评分的项目更为稀少，若单独以此进行用户相似程度的比较，误差较大，因此需要综合隐性评分，提高用户间相似程度判定的准确性。已有兴趣度的获取包括显性兴趣度获取和隐性兴趣度获取2 部分。

显性兴趣度来源于用户的显式评分，需要用户有意识地表达自己对商品信息的认同程度。一般的协同过滤推荐方法常用整数值(如1~9 等级)来表示喜欢的不同程度，本算法以规范化成0~1 的兴趣度表示。设Re(i,j)为用户i 对全部n 个商品类中的商品类j 的显性兴趣度，1 表示全部显性兴趣，则有：

隐性兴趣度来源于用户对商品的浏览行为信息。在用户-商品矩阵中，评分数据为用户浏览过该商品的次数，0 表示尚未发生兴趣，次数越多则兴趣越高。隐性兴趣度的获取方法较为简单，可从用户的浏览记录库中得到隐性兴趣度。对于某个商品类的隐性兴趣评分，可用用户浏览的该商品类在其整个浏览记录中的比例表示。设Ri(i,j)表示用户i 对全部n个商品类中的类j 的隐性兴趣度，1 表示全部隐性兴趣，则有：

通过上述的方法得到显性兴趣度和隐性兴趣度后，将两者结合，形成用户的已有兴趣度，以线性关系结合这2 个兴趣度，得到用户i 对商品类j 的已有兴趣度：

其中，α 为显性兴趣度的比重参数，α 取值越大则显性兴趣度越为重要；m 表示在浏览记录数据库中该用户浏览商品的总数。

2.2 综合兴趣度的获取与最近邻居的形成

在获取综合兴趣度之前，首先必须获得预测兴趣度，本文利用商品的属性分类关系和顾客所购物的关联性，建立商品的属性向量表达式和顾客的兴趣向量表达式，从而预测用户对某未评分商品的兴趣度。首先将所有的商品分类，建成一个有阶层的分类树，每个商品属于分类树的最底层中的其中一类，最底层的每一类对应一个商品属性，然后将所有属性构成每个商品的属性向量。属性权重的设定根据商品在分类树中所在的类别与其他类别的分类关系，及类别之间的关联规则。其中，关联规则是根据顾客的购买记录在各层类别中的分布，挖掘每一层中同层类别之间的关联规则。假设在全部n 个商品类中，每个商品类作为特征项，则任一商品类j 可以表示为一个n 维特征向量：

其中， Ps, j 为第s 个特征项的权重，本系统将Ps, j 的取值规定为

其中，C(s)和C( j ) 表示商品类s 和j 的父类；s⇒j 表示s和j 之间存在强关联关系。得到每个类的特征向量后，就得到类间的一种关联关系，通过这种关系，可以利用已评分类预测未评分类。设经用户i 已评分的类集合用Ai 表示，k ∈Ai，未评分商品类m∉Ai，Ri,k 表示用户i 对已评分类k 的兴趣度，那么用户i 对未评分的类j 的预期值Pri,j 为

规范化处理使全部的预期兴趣度为 1，则用户i 对未评类j 的预期兴趣度i, j Rp 为

为了结合已有兴趣度和预期兴趣度，设定系数β (0≤β ≤1)以平衡已有兴趣度与预期兴趣度的比例，得到综合兴趣度：

判别 2 个用户是否是邻居需要比较这2 个用户的兴趣相似性，相似性度量方法常用的有余弦相似性、修正的余弦相似性和相关相似性等。

由于按照本文的方法可得到较为完整的兴趣评分，因此本文采用余弦相似性作为度量方法。设用户i 和用户j 在n维类上的兴趣度分别表示为向量i 和j，则用户i 和用户j 之间的相似性sim(i,j)为

其中， ‘Ri,d 和’Rj,d 分别表示用户i 和用户j 对类d 的兴趣度。

寻找最近邻居的目标就是对每一个用户u，在整个用户空间中查找用户集合D=(d1,d2,…,dk)，使得u ∉D，并且d1 与u 的相似性sim(u,d1)最高，d2 与u 的相似性sim(u,d2)次之，依此类推。

2.3 推荐结果的产生

通过上述的相似性度量方法得到目标用户的最近邻居后，需要利用最近邻居的观点为目标用户产生相应的商品推荐。常用的预测目标用户未评分项目评分的方法是综合最近邻居对未评分项目的评分，作为目标用户对预测项目的评分。

本文采用最频项推荐为目标用户产生Top-N 推荐：在浏览记录库中，扫描目标用户每个最近邻居的浏览记录，对其浏览的商品进行计数，选择出现频率最高且目标用户尚未浏览过的前N 个商品作为推荐内容。设目标用户u 浏览商品的集合为A，最近邻居浏览商品的集合为D，候选推荐商品的集合

C=D-A，候选商品b ∈A，那么候选商品b 对于用户u 的推荐度Recb,u 为

其中， d ,bd CCount∈ Σ为浏览过商品b 的的最近邻居的数目；Sumc为最近邻居总数。

3 实验及结果分析

为了验证本系统的推荐效果，在小范围内进行了实验，用平均绝对偏差作为测量标准对协同过滤推荐的实验结果进行了度量，并通过对比分析验证了基于综合兴趣度的方法的有效性。

3.1 实验过程与评价标准

为了方便测试，实验前系统录入了约 1 000 本计算机书籍，邀请了某公司82 个员工参与实验，实验期为1 个月。实验的前20 天为用户自由浏览时间，系统不产生推荐，要求实验用户进行注册及填写显性评分，实验的后10 天系统为注册用户产生推荐清单，并要求用户对每个推荐书目进行满意程

度反馈。

本文评价协同过滤推荐效果时，采用平均绝对偏差(Mean Absolute Error, MAE)作为测量推荐系统满意度的公式，MAE 用于测量推荐值与实际评价值之间的偏差，可以直观地度量推荐质量，MAE 越小，推荐质量越高[9]。本实验用户u 的平均绝对偏差为

其中，n 为Top-N 的推荐总数； pu,i 为实际评分； qu,i为相应的预测评分。

3.2 实验结果分析

系统得到实验数据后，分别在推荐 Top-10, Top-20 和Top-30 的范围内，将实验用户的推荐结果及其反馈的满意度进行比较，然后分别利用平均绝对偏差公式对基于综合兴趣度的方法和传统的基于显性兴趣度的方法进行计算。计算的结果如表1 所示，对比分析如图1 所示。

从图1 可知，MAE 值在0.12~0.17 之间，表明系统能起到较好的推荐效果，随着Top-N 数量增多，MAE 值呈下降趋势，表明了Top-N 中N 值较大时用户满意度高。

传统的协同过滤方法仅使用显性兴趣度作为用户相似性的计算指标，其计算最近邻居的准确度较低，从实验结果可看出其MAE 值较高，推荐质量不高。

本文的推荐方法使用了综合兴趣度作为用户相似度的计算指标，实验表明在相同条件下MAE 值有了明显的降低，可见基于综合兴趣度的推荐方法能够有效地提高协同推荐系统的推荐质量。

参考文献

[1] Varian R. Recommender Systems[J]. Communications of the ACM,1997, 40(3): 56-58.

[2] Resnick P, Iacovou N, Suchak M. Grouplens: An Open Architecturefor Collaborative Filtering of Netnews[C]//Proc. of the Conference on Computer Supported Cooperative Work. Chapel Hill, NC, USA: [s. n.], 1994: 175-186.

[3] Shardanand U, Maes P. Social Information Filtering: Algorithms for Automating “Word of Mouth”[C]//Proc. of the ACM CHI Conference. Denver, Colorado, USA: [s. n.], 1995.

[4] Goldbergd N D, Oki B M. Using Collaborative Filtering to Weave an Information Apestry[J]. Communications of the ACM, 1992, 35(12): 61-70.

[5] Sarwar B M, karypis G, Konstan J A, et al. Item-based Collaborative Filtering Recommendation Algorithms[C]//Proc. of the 10th International World Wide Web Conf.. Hong Kong, China: [s. n.], 2001: 285-295.

[6] 邓爱林, 朱扬勇, 施伯乐. 基于项目评分预测的协同过滤推荐算法[J]. 软件学报, 2003, 14(9): 1621- 1628.

[7] 陈东林, 聂规划. 基于商品属性隐性评分的协同过滤算法研究[J]. 计算机应用, 2006, 26(4): 966-968.

[8] 白丽君, 刘君强. 一种解决协作过滤中矩阵稀疏性问题的算法[J]. 情报学报, 2005, 24(2): 199-202.

[9] Breese J S, Kadie C. Empirical Analysis of Predictive Algorithms forCollaborative Filtering[C]//Proc. of the Conference on Uncertainty in Artificial Intelligence. Madison, Wisconsin, USA: [s. n.], 1998.

本文作者：秦光洁，张颖 (长安大学信息工程学院，西安 710064)

您可能还对下面的文章感兴趣：

推荐算法Slope One初探 [2012-02-26 22:51:40]
数据驱动销售――个性化推荐引擎 [2011-11-14 00:03:35]
推荐系统的问题 [2010-10-17 08:45:39]
用搜索的倒排轻松搞定“好友的文章”类相关推荐功能 [2010-09-06 08:46:04]
基于关联规则的推荐系统 [2010-02-23 22:29:27]
如何从无到有建立推荐系统 [2009-12-22 14:11:13]
音乐智能推荐 [2009-11-24 09:18:20]

DRBD使MooseFS跑得更安全

zhang — Thu, 17 May 2012 23:49:34 +0800

标签： DRBD MooseFS

之前写过两篇关于MooseFS的相关概念以及操作管理的BLOG，我们可以看到MFS一些好的地方，比如：通过copy数来保证数据的可靠存，当MFS系统中有个别chunkserver宕机发生，也不会影响应用的正常使用；同时，相比ext3它还能节省存储空间。这里说到，“可靠”，并非这个系统就真的如想象一样，和NFS相比的确，多份copy确实可靠了不少，但是它们都有一个共同的问题，那就是主控server的单点问题。MFS系统中，即便有metalogger server的这个作为master的角色，但问题依然存在。下面就说说使用中的体会。

问题：当mfsmaster主机发生问题，按照MFS系统的提供的故障切换方法，mfsmetalogger主机会被提升为mfsmaster，继续提供服务，服务是能够提供，但是，如果你真的实际操作过，就知道后续你要做多少动作。当你的mfsmaster发生变化，意味着你的主机IP已经改变，那么相应所有挂载的client端，必须要重新连接新的master_host重新挂载一次。你可能会认为以下方法可行。

理想中的方法：

1. 将mfsmount命令中的选项-H的参数采用DNS域名的方式，这样域名始终不变而是IP发生变化，这对于使用者来说是透明的，是这样吧？

2. 有的人可能会说，不用这么麻烦，我们可以调换原mfsmaster与mfsmetalogger的IP不就行了吗？但是，实际工作中，你没权这么改，也不能这么做，公司中这些资源都是由专属部分统一管理，你方便了但是给别的同事带来了麻烦。

下面说说目前我们采用的方法，这个方法在我们看来，所使用的技术都是熟悉的而且是可控的；在和田老师商量之后，采用DRBD来做mfsmaster端的高可用。

先来说说上面提到的方法1为什么不行，原因很简单，因为在client端，mfsmount命令执行挂载后，它cache住的是mfsmaster主机的IP地址，这是根源所以在，导致你不能简单靠域名来解决这个变的问题。既然，知道了根源，那么我们的解决办法应该，放到mfsmaster端来思考方法。要求提供mfsmaster服务的主机IP不变，那么自然我们想到采用虚IP这种方式，VIP在两台真实主机间随时准备故障切换，但整个服务对外始终呈现的是一个IP。能够实现这个的需求的，目前市面上流行的方法也不少，比如：keepalive、heartbeat。keepalive从来没接触过，听不少人说keepalive的使用相比heartbeat要简单很多，计划现学又需要时间弄的差多吧又需要一定的精力，有点懒了也不想弄那么多了，把眼前这点东西看住了就不小了。加之之前，所有的MySQL高可用都是用DRBD搭建的，对heartbeat还是比较熟悉的，经过测试之后，最后选择了DRBD+Heartbeat+MFS来实现MooseFS系统的完全高可用。目前DRBD这个方案，也有点我不太特别舒服的地方，就是heartbeat故障切换使用style 1的，并不是基于服务监控，而是通过主机整体网络环境状况判断故障切换，细想想这其中还是有一些不妥的问题。搭过DRBD+Heartbeat+MySQL的，对于记下来要所的MFS的DRBD应用就没什么难度，下面就一些个人觉得有必须提的一些配置。

DRBD

将原有MFS系统中的mfsmetalogger角色去掉，而是将原mfsmetalogger变成现有mfsmaster的备机。

Heartbeat

# cat /etc/ha.d/haresources

mfsmaster-a drbddisk::r0 Filesystem::/dev/drbd0::/mfsconf VIP MFSMaster

#cat /etc/ha.d/resource.d/MFSMaster

/usr/sbin/mfsmaster -c /mfsconf/mfsmaster.cfg $1

MooseFS

将原来/etc目录下的mfsmaster.cfg、mfsexports.cfg配置文件，以及/var/lib/mfs目录下的数据文件，存储到drbd分区上；至于lock文件，在1.7以后将被废除使用，目前我们是1.6的版本，我没有将LOCK_FILE存到drbd分区上，之前在测试的时候，有试过的，当启动mfsmaster服务时，提示不能找到lock文件。其实，当你去查看默认的LOCK_FILE的存放位置时，并不存在的（一个服务启动时，需要创建的这个socket文件，有什么用途呢？除了通信意外，…）。

#vi mfsmaster.cfg

EXPORTS_FILENAME = /mfsconf/mfsexports.cfg

DATA_PATH = /mfsconf

目前，我们的MooseFS主要提供内部备份使用，并没有任何线上使用，这套MFS的HA方案完全符合我们的需要，虽说仅用于备份的MFS，也无需多么高的可靠性，但是这最大的方便是当mfsmaster故障后可以减少很多后续人为的操作，减少了我们你的工作量。:)

您可能还对下面的文章感兴趣：

MooseFS知多少 [2011-02-24 23:02:05]

三国演义的历史人物中谁适合当产品经理

MySQLOPS 数据库与运维自动化技术分享 — Thu, 17 May 2012 23:45:51 +0800

标签： 三国演义产品经理

导读：
昨天彻夜难眠，也许又是每个人的那几天来了，不知道何时养成的毛病，每隔一段时间就会失眠几天。这段时间在策划和组织华东运维技术大会，跟赞助商的市场和销售人员联系沟通，突然发现自己真的属于又傻又天真的IT技术人员，本着互惠互利的方式去开展商务活动，而现实却是对方总是希望以最低廉的代价获得更高的收益，这是我们技术人员与市场/销售人员之间的最大区别，这样的技术会议赞助费用并不高，只有2W足矣，相比他们的营收上亿微不足道，现实是残酷的，除非额外答应让他们分享一个广告性质的主题，这违背我搞华东运维技术大会的原则，为此不得不拒绝。

2012年的经济形势不容乐观，更加悲观的看法是2013年可能经济形势更差，对创业型的公司而言越来越担忧，尤其是那种逐渐丧失竞争力的公司，可能会在这波浪潮中淹没掉，对整个行业而言是好事情，对草根而言是幸事，这样的大环境非常适合草根创业。对待创业的个人态度是：不在创业的路上，就在帮助他人创业的路上。尤其是对XX公司非常担忧，没有太多的资本再折腾了，把握好当下还能咸鱼翻身！

上述描述的一些事情，以及一些不能用文字描述，也不能对外人说的分析和思考，导致我感觉到一种想变革的冲动，为此再去一些历史影片中寻找点安慰、智谋和力量，看二战经典影片、看<<亮剑>>、<<三国演义>>等，今天在知乎上看到有人写 “如果在《三国演义》里面选一个人做产品经理，你会选谁，为什么？”，昨晚我也边看边写了一丁点品三国的话语，不过一早醒来就删除了，周瑜是否适合做产品经理，成为争议最大的人物,个人点评是：三国时期名将，拥有战略家的眼光，卓越的军事指挥才能，能征战沙场的将军；

产品经理人选之一周瑜-@Shoppen：
必须公瑾。产品经理，不是公司战略部经理，所以更看重个人及其团队经营某一领域的能力，而非整体调控。周瑜自身有技术能力（少数能当主将的军师），混过创业团队（下江东），独立带领团队（担任都督守庐江），不被人事行政等所绊（内事不决问张昭），擅于交流（拉拢程普），强于争取资源（说服孙权开战），把握项目进度（趁曹操官渡之时攻打江夏等），对美学有独特的理解和追求（东吴一级古琴师），有把握大规模战役能力（赤壁），有战略眼光（二分天下之计），有个人魅力（95+），而且还是结拜兄弟，不会叛变跳槽。有了公瑾，你还想怎么样？

相关精彩点评：

@kentzhu：这些都是专业技能，此人情商太低，不堪产品经理。比如刚搞出来一个产品立刻被腾讯或创新工场抄袭了，人家比他还做的稍微好，可能立马气死，你要他何用？

@蚂蚁：说也说的是生活啊，里面的人物也是活生生的。何必执著历史的真和假呢。公瑾告诉我们情商对一个pm有多么重要。我们只是从历史或者故事里面得到启发；

@钢盅郭子：诸葛亮自己做产品经理比不上周瑜，但是诸葛亮的优势是可以带一帮产品经理；

产品经理人选之二贾诩-@刘燕翔：

力荐贾诩，一个被忽视的牛人。
别的不说，说说贾诩是怎么帮助张秀将一个微不足道的小公司成功出售给三国第一集团的。

东汉末年，张秀割据宛城。宛城位于东都洛阳和西都长安之间，距离曹操的大本营陈留及后期的根据地许昌都不远。而那时曹操挟天子以令诸侯（顺便提一句，当时贾诩辅佐李傕、郭汜时就建议过挟天子以令诸侯，可惜两个草包听不懂），实力极强。曹操四处兼并，收拾张秀是迟早的事情。所以贾诩很明白，从一开始就制定了出售给曹操的计划，压根就不做上市的白日梦（试问终究有几家公司能上市呢？）。不久，张秀就迎来了曹操的第一次进攻。

第一次进攻，贾诩的策略很简单，投降。张秀想了想，确实也没办法，就投降了。因为张秀也是真想降，所以戏做得很足，曹操信了，还只带了少量随从进入宛城。曹操进来了，贾诩又出了个关门打狗的损招，当晚就反叛了。这一次，曹操损失极为惨重，丧命的包括曹操的贴身警卫队队长典韦、长子曹昂以及侄子曹安国。

没过多久，曹操又回来了。这一次，来势汹汹。贾诩又说，投降吧。张秀疯了。你丫已经诈降过一次了，还杀了人家儿子、侄子和大将，又玩儿这招，有点过分吧。但是贾诩说：你如果第一次就投降，不过是被收购的众多微不足道的小公司之一，以后下场谁知道会怎么样（和鲁肃劝孙权的道理一样），这是第一；第二，曹操现在虽然很强，但人才还是很缺的（最近招人真的好难啊），曹操做梦都想笼络天下人心，无奈长得又没刘备面善；最后，之前我们不过是打了曹操一个措手不及，歪门邪道来不得第二次。

于是，张秀还果真战战兢兢的投降了曹操。没想到，曹操果然代之为上宾，封侯（三国诸多降将之首），善终（这个真不容易）。而贾诩最终也官至三公，善终。

再说说我为什么觉得几个大佬不算好的产品经理。

曹操、刘备和孙权都是创业者，但他们玩儿的是资源整合，在道不在术。

诸葛亮确实牛，但可惜战略上就有问题，隆中对听上去很美好，但却不切实际。说白了，蜀国这家年轻的公司就是被他搞垮的。如果iPhone再好，苹果却亏损得一塌糊涂，我想也不会有这么多人崇拜乔老爷子。

公瑾失在气量，不懂得充分利用外部资源，一心闭门造车。赢了赤壁却失了天下。

司马仲达太阴险了，计谋阴险还可以理解，理想阴险就不大好了。我想，各位CEO都不愿意自己的团队里有很多司马吧？

郭嘉，没啥，我巨喜欢这个人，可惜，死得太早。身体是革命的本钱，公司入职还得交体检报告呢。

说白了，我觉得好的产品经理既要有好的产品战略思维，也要有足够的执行力能够实现（实现与否就是一个零和赢的游戏，没有中间道路）。

精彩点评：

@Grubby：贾诩是一位优秀的COO；

@刘燕翔：也有道理，不过要看怎么定义三国中的“产品”。如果说诸侯就是产品，那么贾诩肯定是一流的产品经理，能把张秀那么个破烂货做得这么好，还卖了个好价钱；

@周阳 Zero：没有几个人感用这个人，太过强力，连曹操都不敢用。100％正确的人说到底，只是因为他谋划的事情少，曹操不太感用，敬而远之，贾诩也知趣，躲着。这种人并不适合在公司里任职，在董事会里混混或许更有意义；

产品经理人选之三鲁肃-@赵研：

首推鲁肃，PM要有能力来协调各方面的资源，鲁肃在沟通协调方面可是能人。
次推郭嘉和田丰，PM应该有超强的理解能力，包括需求层面和技术层面。郭嘉最了解曹操的心思，而田丰对袁绍和冀州集团内部争斗看的都十分透彻。
再推曹操和司马懿，战略家，不解释。
最后推于禁，治军严格的于禁当属执行力超强的典范。
不推诸葛亮，因为做事有侥幸心理，很多时候还固执不懂变通。

产品经理人选之三高顺 — @陈筛成：

我选高顺（吕布手下第一大将，“陷阵营”的创作者）

1，不挑剔公司领导：在吕布这即刚愎自用，又很色的领导手里干活（国内大部分普通老板都是这样的），明明知道是个没有前途的公司，很不容易；

2，不埋怨公司环境：经常换地方，从濮阳、到小沛，到徐州，下邳，每次都是快要倒闭的情况；

3，不搞同事关系，不拉人：陈宫很有私人，虽然表面忠诚，连郝萌造反他都知道；但是高顺从来都是自己做事自己负责；

4，被限制权利，甚至自己的工作组也被剥夺了指挥权，也认真干事：号称“陷阵营”的7百人，竟然也被剥夺权利，那是自己一手带出来的团队啊；

5，产品（陷阵营，一度被评为三国最牛的特种兵）在市场上是杠杠的，能力是超强的：击败过曹操，吕布打败曹操靠的是高顺啊，吓跑过关羽张飞的万人部队，夺走小沛；跟夏侯惇单挑几十回合不分上下，夏侯打累了才被曹性射下了一个眼睛，成为“盲夏侯”；

6，带人是一流的：大战逍遥津的张辽，其实就是他带出来的，当他40多岁的时候，张辽还是个愣头青呢；

7，不会被挖走，不会出卖公司：猎头公司都知道他是个忠诚的人，竟然没人联系他，死的时候，一言不发，曹操都知道此人不会投降，只能杀，而吕布乞降，陈功死前故意炒作；

产品经理人选之四诸葛亮-

@任毅

比较典型的可以选择诸葛亮：
1、诸葛亮对产品有创意有想法，并且形成了整体规划；
2、诸葛亮对产品的运作实施有思路；
3、诸葛亮有很强的人格魅力，能够协调好各方资源；
4、诸葛亮还会选人、用人；
5、诸葛亮人品有保证，敬业！
司马懿也很牛，不过也许做风险投资更适合他，嘿嘿！
荀彧很不错，适合做产品经理；

@pansz 反对选择诸葛亮

产品经理就是一开始设计规划这个产品的，必须有技术能力，更重要的是能把握一手的用户体验。知道用户需要什么。这一点来说，其实还是要选司马。他有自己明确的目标，并且经过一步一步的努力，最后达成了。——所以我认为首选司马懿。

诸葛是搞垮蜀国的元凶，这还有什么可选的。你做产品首先是要自己活，而不是要灭了别人。换句话说，你不需要打压别人的产品销量，只要自己的产品能卖出去就够了。而诸葛亮不顾蜀国国力，盲目多次北伐，直接导致蜀国提前灭亡，谁请他当 PM 只能是脑子进水了。

说到这个，大家应当听说过当年可口跟百事的一个故事：话说当年可口跟百事一共占有了 15% 的饮料份额，他们两者都是 7.5% 左右，每时每刻都在为抢对方的份额打得焦头烂额，有时你 7% 我 8% 就兴高采烈了。

不过后来可口的某人提了个建议，咱不去抢百事的份额，咱们到不喝可乐的人群中去开辟新领地如何？？？——于是后果就是，可口可乐的占有率从 7.5%飙升到 20%-30% 甚至更多。而百事仍然停留在 7%-10% 打转转。

这个事情告诉我们：创造性的提升自己的硬实力更重要，只想着跟别人斗并不是最优方案。有鉴于此，我一向不看好诸葛亮。

产品经理人选之五曹操-@李恩强

曹操是技术型人才转为产品型的人才,所以存在一些缺陷.但是他还是有数据分析,调研等等的一些能力的.
诸葛亮有几点比较符合产品经理的要求.懂怎样做协调配合,懂怎么做分析并给予正确的方法实现.

您可能还对下面的文章感兴趣：

关于产品经理核心专业能力的思考 – 腾讯产品总监蒋宁 [2012-03-31 22:40:03]
什么是互联网产品经理 [2012-03-04 20:39:48]
知心怪蜀黍NO.2 产品经理如何修炼内功 [2011-12-22 22:01:26]
产品感悟 [2011-10-04 18:07:40]
淘宝商城实习三月记：产品经理做什么 [2011-09-26 23:16:17]
由产品经理招人难想到的 [2011-09-04 22:29:25]
产品经理如何行之有效的提高执行力 [2011-08-03 13:27:46]
产品经理你伤不起 [2011-06-23 13:40:43]
给想转行做产品经理的同学 [2011-06-22 00:26:39]
俞军给淘宝产品经理的分享 [2011-03-27 23:52:43]
从编辑到PM [2011-02-16 22:13:42]
产品经理能力模型解说―执行 [2011-02-14 22:42:12]
产品经理能力模型解说―把控 [2011-02-14 22:41:13]
产品经理能力模型解说-学习 [2011-02-13 21:00:47]
产品经理3年沉淀和总结 [2011-01-18 22:03:11]
产品经理之创业公司 [2010-11-04 09:57:36]
再说搜狐的 PM [2010-10-22 00:29:28]
产品经理的素质 [2010-10-07 08:15:48]
浅谈产品经理的基础和能力 [2010-08-17 23:25:29]
产品经理进化史 [2010-08-17 23:20:50]
产品经理，你用多少时间来思考 [2010-08-12 23:25:23]
产品过程 [2010-08-12 04:39:15]
我理解的产品经理 [2010-08-11 10:01:55]
产品经理的“妥协” [2010-08-10 22:32:18]
产品的性格 [2010-08-06 09:41:39]
中国式产品经理（二） [2010-08-02 10:11:11]
中国式产品经理 [2010-07-26 23:41:00]
产品经理怎么和UED打交道 [2010-07-23 00:10:03]
产品经理怎么和猎头打交道 [2010-07-20 09:53:30]
产品经理应该具备的开发知识 [2010-07-19 09:49:27]
产品经理怎么和美工打交道 [2010-06-27 22:30:45]
产品经理怎么和程序员打交道 [2010-06-12 17:58:16]
产品经理怎么和领导打交道 [2010-06-03 13:18:42]
产品经理怎么和产品经理打交道 [2010-06-02 23:05:14]
互联网产品经理，全方位入门，图书推荐 [2010-04-28 15:43:30]
互联网产品经理必读书目 [2010-03-26 14:24:36]
产品经理应该是管理者么 [2009-12-07 12:19:41]

微信架构的启示

Tim — Thu, 17 May 2012 23:44:31 +0800

标签： 微信

腾讯大讲堂中最近分享了周颢演讲的微信技术总监解读微信架构的秘密，看完视频的一些心得。

技术微创新

微信的技术设计上有很多微创新，看起来都很小，但是对于系统的稳定性、用户体验及开发敏捷都具有重要作用。

前轻后重

由于客户端升级不便，从技术设计上尽量利用后端的设计来减少依赖客户端升级的方法。如某个版本新增了群聊功能，按常规思路，需要所有客户端升级才能全部打通。微信采用服务器兼容的方法，在老客户端不升级情况下让其增加群聊的功能，通过在服务端将群聊协议转换成之前旧版兼容的协议返回给老的客户端。

客户端辅助设计

微信客户端做了很多非常规的功能，比如常规的客户端测速方法是登录阶段轮询测试多个IP来选择服务器，这样会带来流量及登录速度双方面的开销，因此微信选择的方法是服务端返回最佳的IP(可能是通过历史数据分析)。客户端另外实现了一些容灾能力的配合，当一个IDC访问出现异常自动选择另外一个IDC。

流量控制

由于大部分无线用户对流量非常敏感，为了防止由于客户端不可预知的bug如死循环导致“偷流量”，服务端增加用户流量实时分析的方法，可以在海量数据下找出流量异常的用户，并给这些用户强制下行终止连接信号。

基础研发的策略

从视频介绍来看，微信的基础研发与业务结合非常紧密，提到的有基础组件比如Client/Server框架，从原理上看类似Twitter Finagle，框架封装了大容量网络通讯及远程调用所需各种功能。此外介绍的一些监控与统计框架也较为先进，可以随时增加监控指标。

大量可复用的基础组件让业务开发非常敏捷，周颢总结的基础研发策略是“实现已有经验的固化”。这和其他一些公司中的基础研发团队思路有所区别。业界中基础研发脱离生产闭门造车的情况并不罕见，一方面业务部门重复低层次开发现象严重，另外一方面基础研发对业务理解欠缺，开发的组件模块与业务结合不紧密，无法被有效利用。因此类似微信这样增强业务团队的力量，在开发业务同时总结抽象更多的基础组件或许是一种更为实用的发展思路。

腾讯海量课程

视频中多次提到腾讯内部的一种海量模型的培训课程，其中的经验或设计模式包括

大系统小做

将一个复杂的大系统分解成多个独立的、小的、简单的任务去完成，“分而治之”。

柔性可用

服务端系统通常不是0与1之间的选择，可以在极端情况下做一定优雅降级，在服务端代码中需要体现这些设计。

Set模型

类似最近讨论的cell架构，按一个服务按用户范围分成不同的小单元，每个小单元(cell/set)具备全部业务服务能力，当一个set发生故障时候，只会影响这一小部分用户。微信架构中所做的补充是，在set之间增加了容错处理，当一个set发生故障时，使用类似一致性哈希的算法，调用方可以自动切换到下一个set来存储，并且将新的位置记录在index上(类似GFS master)，周颢自称是一个简化版的GFS。

微信的协议

里面提到了XMPP和类Sync的自定义协议，里面提到XMPP的缺点是流量大和消息不可靠。但是流量大并非XMPP主要矛盾，可以很简单将其映射成二进制协议。消息ACK也可以添加简单的扩展协议来实现。较繁琐的还是兼容CMWAP网关的设计。

使用XMPP或者简化的XMPP标准协议有很多好处，类似的场景有业界广泛使用的open api基本都使用HTTP及JSON，并不是由于这两种协议优化或高效，而是其简洁并得到广泛的认知。一种标准协议的认知及扩展成本要比一个自定义协议小得多，XMPP流量大的问题可以通过转换协议来实现，比如用binary 1代表login等全部协商协议，2代表message，消息增量获取也可以通过自定义扩展协议来实现。标准协议可以让团队内部及新人的认知成本降低，每一个参与者都很容易想到代码及架构改进建议。而且微信目前也在构建开放平台，自定义协议在开放方面必然具备一些局限。

其他

分布式理论

从微信的分享也看到，指导业界不同背景的团队(不管大小)的分布式理论主要还是Google及Amazon系列论文，对互联网技术的发展具有深远影响。微信借鉴了Quorum及Merkle tree的理论，创造了一种自定义的做法，用于实现一种分布式递增发生器。

不过分布式递增算法其实有更简单的实现方法，twitter也有相关的公开博文，由于视频相关背景介绍比较简短，可能大家解决的需求具有差异，就不展开了。

监控

数千的监控项，可以在分钟发现系统的异常

敏捷

每天20个后台变更

技术传承

从视频和PPT来看，微信的技术体系是从头搭建的，可能有不少利用qqmail时代的基础代码，但与深圳团队并不存在太大技术沿袭或者传承关系。从另外一个角度也看到微信技术团队的战斗力。

新人力量

一位毕业生的创意：按SET分布,全量数据从2G减到200K(具体的情况待了解)

另外一个新特性，漂流瓶及摇一摇，据说也是2个月的本科毕业生一周完成，而且上线后运行稳定。

存储

上图中可扩展设计中字段配置表的做法感觉略显繁琐，目前大部分NoSQL产品的schema free方式可能更易于维护。

产品驱动

如图，其中“允许发布十分钟前的变更”这样做法通常在大型团队通常会引起广泛质疑，单纯学习这种形式并非正解，如何在互联网产品上实现敏捷值得产品和研发进一步思考。

您可能还对下面的文章感兴趣：

很抱歉，暂时没有......

rsync 的核心算法

陈皓 — Thu, 17 May 2012 23:40:23 +0800

标签： rsync

rsync是unix/linux下同步文件的一个高效算法，它能同步更新两处计算机的文件与目录，并适当利用查找文件中的不同块以减少数据传输。rsync中一项与其他大部分类似程序或协定中所未见的重要特性是镜像是只对有变更的部分进行传送。rsync可拷贝／显示目录属性，以及拷贝文件，并可选择性的压缩以及递归拷贝。rsync利用由澳洲电脑程式师Andrew Tridgell发明的算法。这里不介绍其使用方法，只介绍其核心算法。我们可以看到，Unix下的东西，一个命令，一个工具都有很多很精妙的东西，怎么学也学不完，这就是Unix的文化啊。

本来不想写这篇文章的，因为原先发现有很多中文blog都说了这个算法，但是看了一下，发现这些中文blog要么翻译国外文章翻译地非常料，要么就是介绍这个算法介绍得很乱让人看不懂，所以反而让我觉得我应该写下这篇文章，因为别人没搞好。(当然，我成文比较仓促，可能会有一些错误，请指正)

问题

首先，我们先来想一下rsync要解决的问题，如果我们要同步的文件只想传不同的部分，我们就需要对两边的文件做diff，但是这两个问题在两台不同的机器上，无法做diff。如果我们做diff，就要把一个文件传到另一台机器上做diff，但这样一来，我们就传了整个文件，这与我们只想传输不同部的初衷相背。

于是我们就要想一个办法，让这两边的文件见不到面，但还能知道它们间有什么不同。这就出现了rsync的算法。

算法

rsync的算法如下：(假设我们同步源文件名为fileSrc，同步目的文件叫fileDst)

1)首先，我们会把fileDst的文件平均切分成若干个小块，比如每块512个字节(最后一块会小于这个数)，然后对每块计算两个checksum，

一个叫rolling checksum，是弱checksum，32位的checksum，其使用的是Mark Adler发明的adler-32算法，

另一个是强checksum，128位的，以前用md4，现在用md5 hash算法。

为什么要这样？因为若干年前的硬件上跑md4的算法太慢了，所以，我们需要一个快算法来鉴别文件块的不同，但是弱的adler32算法碰撞概率太高了，所以我们还要引入强的checksum算法。

2)CheckSum算法。同步目标端会把fileDst的一个checksum列表传给同步源，这个列表里包括了三个东西，rolling checksum(32bits)，md5 checksume(128bits)，文件块编号。

我估计你猜到了同步源机器拿到了这个列表后，会对fileSrc做同样的checksum，然后和fileDst的checksum做对比，这样就知道哪些文件块改变了。

但是，聪明的你一定会有以下两个疑问：

如果我fileSrc这边在文件中间加了一个字符，这样后面的文件块就完全和fileDst这边的不一样了，但理论上来说，我只需要传一个字符就好了。

如果这个checksum列表特别长，而我的两边的相同的文件块可能并不是一样的顺序，那就需要查找，线性的查找起来应该特别慢吧。

很好，让我们来看一下同步源端的算法。

3)checksum查找算法。同步源端拿到fileDst的checksum数组后，会把这个数据存到一个hash table中，用rolling checksum做hash，以便获得O(1)时间复杂度的查找性能。这个hash table是16bits的，所以，hash table的尺寸是2的16次方，对rolling checksum的hash会被散列到0 - 2^16 - 1中的某个值。(对于hash table，如果你不清楚，请回去看你大学时的数据结构那本教科书)

顺便说一下，我在网上看到很多文章说，“要对rolling checksum做排序”(比如这篇和这篇)，这两篇文章都引用并翻译了原版的这篇文章，但是他们都理解错了，不是排序，就是把fileDst的checksum数据，按rolling checksum做存到2^16的hash table中，当然会发生碰撞，把碰撞的做成一个链接就好了。这就是原文中所说的第二步。

4)比对算法。这是最关键的算法，细节如下：

4.1)取fileSrc的第一个文件块(我们假设的是512个长度)，也就是从fileSrc的第1个字节到第512个字节，取出来后做rolling checksum计算。计算好的值到hash表中查。

4.2)如果查到了，说明发现在fileDst中有潜在相同的文件块，于是就再比较md5的checksum，因为rolling checksume太弱了，可能发生碰撞。于是还要算md5的128bits的checksum，这样一来，我们就有 2^-(32+128) = 2^-160的概率发生碰撞，这太小了可以忽略。如果rolling checksum和md5 checksum都相同，这说明在fileDst中有相同的块，我们需要记下这一块在fileDst下的文件编号。

4.3)如果fileSrc的rolling checksum 没有在hash table中找到，那就不用算md5 checksum了。表示这一块中有不同的信息。总之，只要rolling checksum 或 md5 checksum 其中有一个在fileDst的checksum hash表中找不到匹配项，那么就会触发算法对fileSrc的rolling动作。于是，算法会住后step 1个字节，取fileSrc中字节2-513的文件块要做checksum，go to (4.1) - 现在你明白什么叫rolling checksum了吧。

4.4)这样，我们就可以找出fileSrc相邻两次匹配中的那些文本字符，这些就是我们要往同步目标端传的文件内容了。

图示

怎么，你没看懂？好吧，我送佛送上西，画个图给你看看。

这样，最终，在同步源这端，我们的rsync算法可能会得到下面这个样子的一个数据数组，图中，红色块表示在目标端已匹配上，不用传输(注：我专门在其中显示了两块chunk #5)，而白色的地方就是需要传输的内容(注意：这些白色的块是不定长的)，这样，同步源这端把这个数组(白色的就是实际内容，红色的就放一个标号)压缩传到目的端，在目的端的rsync会根据这个表重新生成文件，这样，同步完成。

最后想说一下，对于某些压缩文件使用rsync传输可能会传得更多，因为被压缩后的文件可能会非常的不同。对此，对于gzip和bzip2这样的命令，记得开启 “rsyncalbe” 模式。

(全文完，转载时请注明作者和出处)

您可能还对下面的文章感兴趣：

puppet使用rsync来同步文件教程 [2012-02-26 23:33:04]
rsync主动同步代码 [2012-01-24 13:50:41]
SHELL TIPS: rsync 和 crontab 变量 [2011-06-10 13:57:53]
Dropbox差异同步算法rsync及其改进算法原理 [2010-11-13 09:05:03]
rsync自动输入密码实现数据备份 [2010-07-15 08:46:24]
使用 rsync 或 unison 备份或同步支持 ssh 的 web 主机 [2010-01-08 12:06:44]

HBase中如何开发LoadBalance插件

莫问 — Thu, 17 May 2012 23:34:55 +0800

标签： HBase LoadBalance

HBase 中的LoadBalancer策略控制了如何在集群启动时Assign所有用户Region到各个RegionServer上，以及如何定期检查Region分布情况并重新调整Region位置的。这些工作在0.92之前的版本中都是在HBase Master内核中实现的，开发人员如果希望扩展自己的LoadBalancer插件，只能Hack源码，但这随着社区版本的升级，Hack工作必须移植到新的版本中。幸好在0.92版本中，HBase将LoadBalancer策略从Master内核中抽取了出来，开放了LoadBalancer Interface，允许开发者根据自己的业务特定扩展自己的LoadBalancer插件。

定制LoadBalancer插件需要两个步骤：

继承org.apache.hadoop.hbase.master.LoadBalancer Interface，实现自己的LoadBalancer Class

在hbase-site.xml中增加配置项，使得定制的LoadBalancer生效

hbase.master.loadbalancer.class

{your custom loadbalancer class name}

因此，开发LoadBalancer插件的前提准备工作便是清楚了解org.apache.hadoop.hbase.master.LoadBalancer这个Interface：

public interface LoadBalancer extends Configurable {

/**

* Set the current cluster status.  This allows a LoadBalancer to map host name to a server

* @param st

*/

public void setClusterStatus(ClusterStatus st);

//这个方法一般参考org.apache.hadoop.hbase.master.DefaultLoadBalancer即可，无需定制

/**

* Set the master service.

* @param masterServices

*/

public void setMasterServices(MasterServices masterServices);

//这个方法一般参考org.apache.hadoop.hbase.master.DefaultLoadBalancer即可，无需定制

/**

* Perform the major balance operation

* @param clusterState

* @return List of plans

*/

public List balanceCluster(Map> clusterState);

//这个方法是HBase Master内部的balancer线程定期执行调用，用来定期检查并ReBalance集群

/**

* Perform a Round Robin assignment of regions.

* @param regions

* @param servers

* @return Map of servername to regioninfos

*/

public Map> roundRobinAssignment(List regions, List servers);

//这个方法是HBase Master在启动时调用的，用来批量调度所有用户Region到RegionServer上(hbase.master.startup.retainassign设置为false时生效，与retainAssignment互斥)

/**

* Assign regions to the previously hosting region server

* @param regions

* @param servers

* @return List of plans

*/

public Map> retainAssignment(Map regions, List servers);

//这个方法是HBase Master在启动时调用的，可以保持上次集群中Region的分布位置不变(hbase.master.startup.retainassign设置为true时生效，与roundRobinAssignment互斥)

/**

* Sync assign a region

* @param regions

* @param servers

* @return Map regioninfos to servernames

*/

public Map immediateAssignment(List regions, List servers);

// 这个方法用来立即将目标regions进行assign，主要是要快速assign，可以暂时忽略均衡问题，交由balancer线程后续定期rebalance解决

/**

* Get a random region server from the list

* @param servers

* @return Servername

*/

public ServerName randomAssignment(List servers);

// 这个方法是在随机assign一个region时被调用，从当前live的regionservers中选取一个随机的server作为assignregion的目标，

}

在熟悉了LoadBalancer接口之后，我们可以开始创建一个自定义的LoadBalancer Class，实现定制化的Balance策略。HBase中默认的Balance策略是RegionServer级别的，即保证每个RegionServer中的Region数量均衡，但没有考虑到每个Table内部的Regions在所有RegionServers中的均衡，下图可以清晰的描述这个问题：

由上图可以看出，各个RegionServer中的Regions数量是均衡的，但是每个Table内部都是不均衡的，因此各个Table的访问者很容易出现局部访问热点。我们定制Table Level的LoadBalancer不仅要实现RegionServer级别的Balance，同时也要实现Table级别的Balance，如下图所示：

由上图可以看出，不仅RegionServer间保持均衡，每个Table内部的Region也是均匀分布的。具体实现TableLevelLoadBalancer是，要重点关注LoadBalancer Interface中的以下几个主要方法：

Map> roundRobinAssignment(List, List)，HBase Master启动时将各个用户Table的Regions依次均匀assign到各个RegionServer中，这个可以参考DefaultLoadBalancer中的实现

Map> retainAssignment(Map regions, List servers), HBase Master启动时如果发现hbase.master.startup.retainassign设为true了，则不会进行roundRobinAssignment，而是调用这个方法保持上一次集群的region assign方案，这个方法也可以参考DefaultLoadBalancer中的实现

List balanceCluster(Map> clusterState)，HBase Master中Balancer线程定期调用这个方法来进行ReBalance，这个方法是我们需要重点关注的，也是定制的关键，在这个方法中，我们主要进行了2个步骤：

遍历当前各个table的regions在RegionServer中的分布情况，计算出各个table在每个RegionServer中应该的均匀region数量

重新遍历当前各个table的regions在RegionServer中的分布情况，对于每个Table，根据第一步的计算出的均匀负载值，生成RegionPlan List，将每个RegionServer中超出均匀负载的region移到低于均匀负载的RegionServer中。在这个步骤中，同样需要保证每个RegionServer中总的Region数量是均衡的，这需要算法实现保证，稍有算法基础的开发人员应该可以很容易做到，这里就不细说了。

Map immediateAssignment(List regions, List servers)，这个方法是用来快速assign region的，无需考虑复杂因素，因此这个方法也可以参考DefaultLoadBalancer中的实现，无需定制

ServerName randomAssignment(List servers), 这个方法是随机选择一个Live的RegionServer来作为assign的目标，因此这个方法也可以参考DefaultLoadBalancer中的实现

至于LoadBalancer Interface中的其他几个方法，都是设置环境和配置信息的，因此完全拷贝DefaultLoadBalancer中的实现即可。

本文主要介绍了HBase 0.92中如何开发LoadBalancer插件的方法，以及我们如何定制Table-Level的LoadBalancer插件。此外，还有一些其他的LoadBalancer插件思路也是不错的选择，例如：基于Region I/O负载的LoadBalancer插件，以及基于HDFS Block Locality的LoadBalancer插件，我们后续将进行更多的尝试和介绍

您可能还对下面的文章感兴趣：

关于HBase的一些零碎事 [2012-03-25 20:50:39]
HBase性能优化方法总结 [2012-03-11 22:39:14]
HBase在数据统计应用中的使用心得 [2012-01-27 18:44:39]
记录碰到的HBase问题 [2011-10-25 13:36:23]
hbase运维 [2011-08-22 12:22:03]
HBase随机写以及随机读性能测试 [2011-08-17 13:48:20]
HBase Java客户端编程 [2011-07-24 14:59:57]
关于HBase的一些零碎事 [2011-06-20 13:41:39]
HBase性能调优 [2011-06-15 14:13:05]
Cassandra和HBase主要设计思路对比 [2011-06-02 23:03:08]
HBase二级索引与Join [2011-06-01 13:29:51]
菜鸟谈HBase之写速度篇 [2011-05-08 22:50:26]
HFile存储格式 [2011-02-28 23:15:03]
hbase介绍 [2011-01-29 22:36:10]
HBase技术介绍 [2011-01-18 22:18:09]

一个检查偶发连接失败的脚本

Thu, 17 May 2012 23:34:16 +0800

标签： 连接失败

情景：

从机器A到机器B发起连接，连接超时时间设置为1s，有一定概率的连接失败的情况，使用下面脚本来测试，不断连接，放过成功的连接，只显示失败的连接，并且显示连接失败的时间，脚本如下：

while :; do r=`nc -z -v -w 1 10.79.40.43 11231 2>&1 | grep -v succe`;if [ "x$r" != "x" ]; then d=`date +"%H:%M"`;echo -n "$d "; echo $r; fi ; done

您可能还对下面的文章感兴趣：

很抱歉，暂时没有......

Linux下常用I/O模型

kimi — Thu, 17 May 2012 23:31:49 +0800

标签： IO

简介

Linux异步I/O是Linux内核中提供的一个相当新的增强。它是2.6版本内核的一个标准特性，异步非阻塞I/O背后的基本思想是允许进程发起很多I/O操作，而不用阻塞或等待任何操作完成。稍后或在接收到I/O操作完成的通知时，进程就可以检索I/O操作的结果。

这并不是一个详尽的介绍，但是我们将试图介绍最常用的一些模型来解释它们与异步I/O之间的区别。下图给出了同步和异步模型，以及阻塞和非阻塞的模型。

每个I/O模型都有自己的使用模式，它们对于特定的应用程序都有自己的优点。本节将简要对其一一进行介绍。

同步阻塞I/O

最常用的一个模型是同步阻塞I/O模型。在这个模型中，用户空间的应用程序执行一个系统调用，这会导致应用程序阻塞。这意味着应用程序会一直阻塞，直到系统调用完成为止(数据传输完成或发生错误)。调用应用程序处于一种不再消费 CPU 而只是简单等待响应的状态，因此从处理的角度来看，这是非常有效的。

下图给出了传统的阻塞I/O模型，这也是目前应用程序中最为常用的一种模型。其行为非常容易理解，其用法对于典型的应用程序来说都非常有效。在调用 read 系统调用时，应用程序会阻塞并对内核进行上下文切换。然后会触发读操作，当响应返回时(从我们正在从中读取的设备中返回)，数据就被移动到用户空间的缓冲区中。然后应用程序就会解除阻塞(read 调用返回)。

从应用程序的角度来说，read 调用会延续很长时间。实际上，在内核执行读操作和其他工作时，应用程序的确会被阻塞。

同步非阻塞I/O

同步阻塞I/O的一种效率稍低的变种是同步非阻塞I/O。在这种模型中，设备是以非阻塞的形式打开的。这意味着I/O操作不会立即完成，read 操作可能会返回一个错误代码，说明这个命令不能立即满足(EAGAIN 或 EWOULDBLOCK)，如下图所示。

非阻塞的实现是I/O命令可能并不会立即满足，需要应用程序调用许多次来等待操作完成。这可能效率不高，因为在很多情况下，当内核执行这个命令时，应用程序必须要进行忙碌等待，直到数据可用为止，或者试图执行其他工作。正如图 3 所示的一样，这个方法可以引入I/O操作的延时，因为数据在内核中变为可用到用户调用 read 返回数据之间存在一定的间隔，这会导致整体数据吞吐量的降低。

异步阻塞I/O

另外一个阻塞解决方案是带有阻塞通知的非阻塞I/O。在这种模型中，配置的是非阻塞I/O，然后使用阻塞 select 系统调用来确定一个I/O描述符何时有操作。使 select 调用非常有趣的是它可以用来为多个描述符提供通知，而不仅仅为一个描述符提供通知。对于每个提示符来说，我们可以请求这个描述符可以写数据、有读数据可用以及是否发生错误的通知。

select 调用的主要问题是它的效率不是非常高。尽管这是异步通知使用的一种方便模型，但是对于高性能的I/O操作来说不建议使用。

异步非阻塞I/O

最后，异步非阻塞I/O模型是一种处理与I/O重叠进行的模型。读请求会立即返回，说明 read 请求已经成功发起了。在后台完成读操作时，应用程序然后会执行其他处理操作。当 read 的响应到达时，就会产生一个信号或执行一个基于线程的回调函数来完成这次I/O处理过程

在一个进程中为了执行多个I/O请求而对计算操作和I/O处理进行重叠处理的能力利用了处理速度与I/O速度之间的差异。当一个或多个I/O请求挂起时，CPU 可以执行其他任务；或者更为常见的是，在发起其他I/O的同时对已经完成的I/O进行操作。

您可能还对下面的文章感兴趣：

Linux操作系统内核3.3版本I/O Stack的流图 [2012-05-14 22:32:06]
Fio压测工具和io队列深度理解和误区 [2012-03-11 22:18:53]
Clojure世界：文件IO [2012-03-04 17:48:11]
在Oracle中如何调整 I/O 相关的等待 [2011-12-18 23:20:49]
MySQL Tuning之浅析I/O优化 [2011-10-25 13:32:48]
关于IO的同步,异步,阻塞,非阻塞 [2011-08-03 13:53:03]
通过『iostat -dx 1』命令监控IO性能 [2011-07-14 23:51:28]
Linux服务器性能评估 [2011-07-01 14:05:07]
查看 CPU, Memory, I/O and NetFlow [2011-06-23 13:49:53]
数据库如何抵抗随机IO：问题、方法与现实 [2011-06-02 00:10:39]
小文件优化之道-文件成组 [2011-06-01 13:45:44]
提升磁盘IO性能的几个技巧 [2011-05-17 09:26:15]
disktop per设备per应用层面的IO读写统计 [2011-05-17 08:46:38]
梦幻西游服务器 IO 问题 [2011-04-01 13:27:44]
blktrace 深度了解linux系统的IO运作 [2011-02-22 07:36:53]
I/O模型-读书笔记 [2011-02-22 07:35:40]
Unix IO模型学习 [2011-01-29 22:24:29]
ioprofile调查应用IO情况的利器 [2011-01-16 22:37:20]
梦幻西游服务器 IO 的一点优化 [2010-12-28 20:52:49]
oracle数据库的CPU/IO信息采集 [2010-11-07 22:42:09]
Linux下获取IO压力数据 [2010-06-23 13:02:43]

弃用NoSQL数据库 CouchDB再见了

MySQLOPS 数据库与运维自动化技术分享 — Thu, 17 May 2012 23:30:39 +0800

标签： CouchDB NoSQL

【导读】

2012年5月10日，Sauce Labs公司的首席架构师Steven Hazel，写了一篇关于弃用NoSQL数据库CouchDB产品，介绍他们将Couch数据库的数据迁移到MySQL数据库平台中。

在Sauce Lab(酱油实验室)里，我们刚刚庆祝完成一个重大项目—将最后的CouchDB数据库转变为MySQL数据库，以提高服务正常运行时间和可靠性。由于大部分无故停机的是由于CouchDB数据库宕机引起的，因此完成这种迁移是我们一个重要的里程碑。

CouchDB数据库开始时，是一个非常宝贵的经验，在1.2版本时它的可靠性还是可以的。但我们的服务对可靠性要求非常高，于是最终决定：这种转变是前进中最有效的方式。

一旦决使用MySQL（具体而言，是Percona的基于InnoDB存储引擎的XtraDB存储引擎，），我们就重构了数据库抽象层，并迁移了所有各种类型的数据库。在过去几个月，迁移完成后，我们的服务正常运行时间大大提高了。

这篇文章介绍了我们使用CouchDB数据库的经验，以及在哪里遇到了麻烦。我也谈了这方面的经验，如何影响了我们对NoSQL数据库的整体观点，以及在熟悉了NoSQL数据库后，如何积极权衡对MySQL数据库的安装配置。

首先，我们是如何陷入困境？

所有的事情都在变的伟大。

自2008年开始我们第一次启动Sauce Lab，我们认为我们正在建立与当今运行的服务非常不同的东西。我们高兴地尝试NoSQL数据库，使用MySQL关系数据库的设计者多年来从来没有想过的方式。CouchDB的似乎很适合我们的需要。

我们原来的产品为客户的利益着想而设计了一个有特色的用于存储数据的REST API，该计划彻底废弃了曾有的CouchDB的RESTful API。这让我们得到了一个原型并匆忙的运行。 CouchDB是新鲜事物且尚未有过什么实际使用，但这并不重要，因为我们数据库I / O需求很少，应用程序自然具有水平扩展性，且产品是容错的。只要保持复制正常且在出错时重试就可以很容易地弥补稳定性的鸿沟。这样难道会出问题吗？

可能出错的地方

随着这家小公司的成长，我们逐渐了解到客户所面临的问题，我们的产品也经历了几个重大变化.随着时间的推移严格按照用户对数据进行分区意义不大。我们变得越来越依靠数据库的I/O性能。通常，我们觉得自己使用CouchDB与最初设想非常不同，更与大多数web应用程序使用数据库的方式不同。虽然这仍是一种合理的使用方式，但我们曾经相信的附加安全性正随着产品的升级而慢慢消失，而那恰恰是我们所需要的。

Sauce Lab比一般web应用程序对可靠性要求更高。如果我们对一个单一请求处理失败，就代表了对一个客户检验的失败，并影响他们的整个架构。随着时间的推移，CouchDB数据库的可靠性越来越糟糕。我们不停的更换硬件设备，改变使用CouchDB数据库的方式。我们改变了软件架构，使其对数据库和数据库I / O操作减少。不过，最后我们决定，最好的方法还是更换数据库产品。

到此为止我都没有讲CouchDB的具体缺点，这是一个年轻的数据库，可靠性和性能问题是可以预期的。因为我们对传统的关系型数据库没有偏爱，但在某种程度上，CouchDB数据库还是太糟糕了。我们深信，NoSQL数据库是未来。 只是我们不相信NoSQL数据库是现在。

我们真心喜欢CouchDB数据库的一些事

无模式。这是美妙的 。，模式甚至有何用？他们只是毫无理由的把事情变复杂。有时你需要对数据增加约束，数据库模式改变非常难。然后CouchDB数据库对文档，增加新的字段非常简单。
非关系型。关系型数据库发展出解决问题的原则是：数据的完整性是至关重要的，而可用性则无关紧要。在很多在现代Web应用程序数据库层中毫无意义的功能。有6种连接方式的事务查询起初是很吸引人的，但是当你需要扩展(scale)时就会令你陷入困境。从一开始阻止这些发生通常是很容易的。

No SQL。这是2012年，大多数查询从代码运行，而不是由坐在控制台的人类。为什么我们仍在用非常接近奇怪的COBOL语言构建的代码查询我们的数据库呢？且这些被组建的代码不得不在每一次查询时重新解析。像SQL注入攻击这样的东西根本不应该存在。他们是将你的数据库API看作编程语言而不是一个协议的后果，它是这个自20世纪70年代起经深思熟虑设计的漏洞的核心；
HTTP API。无论在任何地方，只要符合HTTP（或者run curl)协议，就可以方便的查询数据库；
始终一致性，只追加文件格式。这样做数据库备份仅作文件复制，简单且无后顾之忧；
JavaScript是作为一个视图/查询语言，被人熟知且广泛使用；
任意计算出的值上的索引似乎是一个有巨大潜能的功能。我们从来没有找到一个真正智慧的方式使用它们，虽然它只是简单的通过电子邮件的域名做用户索引。
最后值得指出，即使在挑战其查询和维护索引能力的压力之下，CouchDB数据库从未丢失任何数据。

使用CouchDB时我们遇到的问题

可用性：

在我们最初的设置中，磁盘缓慢的性能使CouchDB正在运行的查询周期性的失败。后来用更快的RAID配置后性能会有所改善，但随着负荷的增加，问题回来了。相比而言，Percona在这一负荷水平完全胜任：mysqld使用CPU资源非常少，几乎没有任何慢查询，cache使用效率足够高以至于几乎没有磁盘读写，在RAID 10下我们的写负载是一个非常舒适的小百分比。

视图有时会丢失索引，而且在正常工作前还有几次重加索引失败的情况。偶尔他们会进入一种无休止重加索引的状态，直到我们彻底删除视图文件并重新启动CouchDB。而对此我们非常痛苦。最后一件事重新编制索引的惊喜是，我们作为一个小团队已经采取一个巨大的任务列表和战斗力，以打动潜在的大客户的需要。Surprise reindexing exercises were the last thing we needed as a small team already taking on a giant task list and fighting to impress potential big customers.

损坏的视图(Views)有时会阻止所有工作的视图，直到这个视图文件已被删除，在这个时候，视图索引消耗时间做重启和一些不可靠的工作。不知道多少次我们中的一员在凌晨4点被监控系统唤醒，因为数据库未经许可因突然变成一个简单的键/值存储而当掉。
压缩(Compaction)有时会没有任何提示的终止，有时还不得不被删除残留的文件使其重新运行。这在我们提高了磁盘容量报警上线之前导致了一些可怕的情况，因为我们发现这一点时，由于做压缩，磁盘仅剩下非常小的空间。
在早期版本中，我们遇到了有关文件句柄使用的三、四个错误。 Bug reports快速修复了他们，并在1.0.2版本中更新了有关代码。

性能：

真的还有一件事要在这里说，那个CouchDB的视图查询的性能问题，并没有达到我们曾经期望的与MySQL索引查询大致相等的性能级别。这不是一个巨大的惊喜或者一个巨大的问题，但是哇塞(but wow)，现在很多事情更快了，我们的数据库机器是负担减少了许多。

维护问题：

当CouchDB出错时，会使所有正在运行的查询出错。其中包括复制和压缩，所以我们需要脚本来检查这些进程，并在必要时重新启动它们。
视图索引仅在查询时才更新-插入操作不会更新索引。这意味着你必须写一个脚本来定期查看你的视图，除非你想在一段时间无人问津时他们变的出奇的慢。在实践中，我们总是倾向于不通过插入操作更新索引来获得提高性能的可能。但是写一些可靠的脚本监控数据的索引是机警(tricky)的。
用于压缩的简单的复制收集器可以花大量时间查看长期的文档。当一个数据库既有长期文件又有短期文件时这尤其是个坏消息：压缩需要很长时间，但急需控制住磁盘使用率。另外，你不得不自己运行压缩和监测，以确保它的工作是有意义的。压缩应该是自动化和分代(generational)的。

未实现的诺言：

CouchDB的设计看起来对像自动分片等NoSQL的主要功能非常完美，但事实并不是这样。
映射化简（MapReduce）只能在一台机器上运行有何意义？我们原本以为这是为分布式查询而设计的功能。
我们从来没有清楚过CouchDB开发人员对其核心用途的考虑。我们看到了发展的重点是集所有功能于一身的应用程序服务，然后是大规模多方向移动应用程序的复制。两个都是有趣的想法，但不是我们所需要的。

（我们被告知在最近发布的CouchDB 1.2，这些问题已经解决。）

我们能够有效发挥CouchDB的性能，并随着时间的推移，我们了解到各种的维修问题的脚本方式。但我们担心CouchDB好像被和我们不同的用法所吸引着，这是最终最终迫使我们做数据库转换的导火索。我们谈到了一些可能的选择，和最终的一个典型解决方案。

MySQL，原始的NoSQL数据库

那么，为什么不能切换到另一个像MongoDB面向文档的数据库或其他NoSQL数据库呢？我们曾经对MongoDB非常感兴趣，但在做一些研究和听到褒贬不一的评论后，我们得出结论：同CouchDB一样，它也有很多相同的问题使我们的工作受到影响。其他NoSQL数据库往往一样不同的，像CouchDB与MySQL之间一样区别很大。

） -因此很难选择 -而且对我们还有很多不熟悉的事情。鉴于对MySQL的经验，我们知道这它能足够满足我们的需求，很难证明其他的选择同样适合。

我们很熟悉MySQL的缺点：别的咱不说，光它的配置就很麻烦（提示：优化性能中最重要的设置是innodb_buffer_pool_size），存储引擎的选择，以及除了面向SQl,分析执行查询SQL语句的时间花费。经验丰富的MySQL用户期望写出很多强制索引子句。

另一方面，InnoDB存储引擎整体来看还是非常强大的。在过去十年中，它已经在一些最大的互联网公司大量使用，而且变得越来越强壮。几乎所有的数据库在底层是都建立在相同的基本B-树算法、散列和类似InnoDB存储引擎的缓存。在尊重基本原理的前提下，任何新的数据库管理系统对在真实环境性能和和靠性的突破都是非常艰难的。但也许未必一定这样：Percona的前瞻性思维的键/值接口是一个可靠的InnoDB存储引擎如何成为真正的NoSQL架构的很好的例子。

刚换到MySQL数据库时，我们对它还像原始存储引擎一样。现在我们将使用MySQL，开发出之前NoSQL全部功能的方法。

我们设法将CouchDB的模型层(model layer)移植到MySQL中且对代码库的影响最小。对大多数使用模型的代码(model-using code)，使用MySQL看起来和使用CouchDB的完全一样。除了它的速度更快，而且这样的数据库从未出错。
我们不使用外键，或者多语句事务，到目前为止也未使用join。一旦我们需时，我们已经准备好横向扩展(horizontally scale)。（不过，这将需要一段时间！自从分片被发明的时期过后，硬件已经发展的更加强大，而且那些日子你可以仅靠单一的写主库运行很长的时间。）
我们的所有表都含有一个TEXT的字段用以存储JSON，我们的模型层为了大多数需求而悄悄将对待他们像真正的列一样。这个主意就像Rails 的ActiveRecord ::商店。虽不是和MySQL的功能设置非常完美融合， MySQL不能真正操作这些JSON列 - 但它仍然是一个伟大的想法，让我们向无模式数据库更加紧密。

这是一个已证明的可靠的数据库存储引擎和给我们很多NoSQL数据库优点的架构的组合，这种设置工作过去一两个月了，我们发现它非常难于达到最好的两个世界的途径。

英文地址：http://saucelabs.com/blog/index.php/2012/05/goodbye-couchdb/

您可能还对下面的文章感兴趣：

《big data glossary》之MapReduce [2012-02-01 18:05:05]
Oracle NoSQL Database [2011-11-21 00:17:40]
hbase运维 [2011-08-22 12:22:03]
让Redis使用TCMalloc，实现高性能NOSql服务器 [2011-07-30 21:21:19]
从Megastore看RDBMS和NOSQL系统结合 [2011-06-23 13:43:08]
Membase基础教程 [2011-06-01 23:42:28]
Using MySQL as a NoSQL [2011-05-25 12:37:53]
关于NoSQL的思考：为什么我们要优化存储的写性能 [2011-02-16 22:17:22]
SQL到NOSQL的思维转变 [2011-01-29 22:33:24]
NoSQL or Relational ? [2011-01-20 22:21:58]
梦幻西游服务器的优化 [2011-01-06 22:30:19]
NoSQL数据库:MongoDB初探 [2010-12-23 22:32:45]
Handler-Socket Plugin for MySQL [2010-11-24 00:09:27]
分享会-高性能nosql数据库redis [2010-11-21 19:54:16]
我对技术方向的一些反思 [2010-09-12 23:43:56]
Cassandra运维之道 v0.2 [2010-08-15 09:38:27]
Twitter停用Cassandra原因分析 [2010-07-12 14:35:45]
Key-Value小数据库tmdb发布：原理和实现 [2010-07-12 14:32:14]
54chen解读NoSQL技术代表之作Dynamo [2010-06-24 09:51:10]
Cassandra运维之道 [2010-06-24 09:38:31]
Cassandra之Token [2010-06-20 23:51:01]
转：NoSQL生态系统 [2010-06-01 13:00:37]
数据库程序开发原则：不要删除数据 [2010-06-01 10:01:37]
SQL vs NoSQL：数据库并发写入性能比拼 [2010-04-29 13:48:49]
Oracle or MySQL ? [2010-04-27 23:28:15]
NoSQL漫谈 [2010-04-22 10:57:00]
MySQL vs NoSQL 效率与成本之争 [2010-03-18 09:03:12]
NoSQL，关系数据库终结者？ [2009-12-17 09:12:02]

IT技术博客大学习

Nginx使用Linux内存加速静态文件访问

基于综合兴趣度的协同过滤推荐算法

DRBD使MooseFS跑得更安全

三国演义的历史人物中 谁适合当产品经理

产品经理人选之四诸葛亮-

@任毅

产品经理人选之五曹操-@李恩强

微信架构的启示

技术微创新

基础研发的策略

腾讯海量课程

微信的协议

其他

产品驱动

rsync 的核心算法

问题

算法

图示

HBase中如何开发LoadBalance插件

一个检查偶发连接失败的脚本

Linux下常用I/O模型

弃用NoSQL数据库 CouchDB再见了

三国演义的历史人物中谁适合当产品经理