Image by idg.com.au via CrunchBase

来自 Sun 的大牛 Andy Bechtolsheim (Sun创始人之一)在 HPTS 2009 上做了题为 Memory Technologies for Data Intensive Computing 的演讲。其中对硬件趋势的演绎很有参考价值。

摩尔定律在未来十年内仍然有效。但是对物理磁盘来说某些方面是需要修改的--速度得不到质上的飞跃了 :)

传统 2.5 寸物理磁盘，能够提供 180 个写 IOPS，320 个读 IOPS，平均一个 IOPS 的价格是 $1（这里指价格处以 IOPS 的平均值，不是累积)。而现在主流 SSD 能够提供 8000 个写 IOPS ，3.5万个读 IOPS，每个IOPS 的成本大约是 $0.1。从性价比上看，SSD 的优势逐渐明显。根据来自 NetApp 的信息，SSD 目前一 GB 大约 $3，而磁盘则为 $ 0.10

而实际上，要想达到百万级别的 IOPS 并非易事，I/O 控制器的处理能力毕竟还有限。SSD 写能力仍然是目前的一大问题，随着时间而写能力下降，"均匀磨损算法"(Wear leveling algorithms)目前也不够完美。

密度每年翻倍，内部延时在未来几年将以每年 50% 的速度减小(现在小于100 usec，磁盘则是大于 5000 usec)，而传输能力将每年翻倍。成本也将每年减少 50%。这些都是好事情。未来几年，是 SSD 的天下。而传统物理磁盘将成为磁带，SSD 将成为磁盘。(Disk is Tape，Flash is Disk。这话不是我说的，这是 Jim Gray 的名言)

Tape is Dead
Disk is Tape
Flash is Disk
RAM Locality is King
--Jim Gray 2006

--EOF--

延伸观看：MySQLConf 09: Andreas von Bechtolsheim, "The Solid State Storage Revolution"

最早注意到这个现象是每次我 BLOG 更新之后，在大约 5 分钟左右，通过 Google 的 BlogSearch 就可以看到内容。这个倒很容易理解，因为我用的 Movable Type 在发布文章的时候会自动通知一下 Google 服务器。接到通知之后，Google 能够较快的把信息合并(Merge)到当前的索引中，但是应该还没加上非常严格的排序(Sort)，这是个很经典的处理技巧。

不过，Google 获得信息绝大部分是通过爬虫"抓取"，也就是"拉"(Pull)数据，只有少部分是用户"推送"(Push)的。这就导致 Google 在信息处理上节拍总要慢一点。Google 的目标是处理地球上的所有信息，无远弗届，但信息的及时性或许是最难解决的。

而 Facebook / Twitter / FriendFeed 等具备面向"实时信息流"(Real Time Lifestreaming)功能的网络应用，大部分信息都是用户"推送"上来的，所以也有天然的优势触及这五分钟之内的数据，并经过简单的局部计算之后呈现给用户。得到"即时"信息似乎是人的天性（另一个侧面的印证是人们无法摆脱手机而全部使用 IM 和电子邮件），所以五分钟之内的数据处理能力是对普通用户来说有着难以言明的吸引力。

"五分钟"只是个大致的说法，相信随着技术的发展，会缩短到三分钟，乃至更短。但这部分始终是 Google 无法完全覆盖的地方，技术没办法打败时间，这也是信息暗网的也无法解决的问题。最终我们发现，信息处理的巨人和信息处理的快刀手一起相处的比较融洽。

--EOF--

注：很明显，这个"五分钟"问题和我之前说的关于 I/O 的五分钟问题是不搭界的。

昨天在 Twitter 上发了一句对"群"这个玩意儿的牢骚，引来了不少朋友的回复，大部分朋友对"群"还是深恶痛绝的，云风随后写了一篇《关于"群"的那些破事》叙述网易泡泡的群功能出炉的来龙去脉。

经常看到有讨论技术的人会开很多 QQ 群，然后一大堆人加入，我最不屑这样的讨论技术的方式，我不相信有谁通过 IM 群学会了很多东西，当然，他们浪费了很多宝贵时间我倒是深信不疑的。所以不乏偏激的说：

"喜欢用群的人都是喜欢用开会来消磨时间的。他们享受群，认为那东西理所当然的是"好"的沟通工具。我也赞同群里面90%都是一些垃圾信息的说法。小笑话、新闻链接、有趣的小图片占据了这 90% 的大部分内容。"

这样的说法如果也在内部会议上提出的话，估计也要像 Tim Yang 那样遭受一片嘘声。（我不排除有人把"群"用的出神入化，比如昨天就有一位互联网大佬给我讲述他当年用群的功能做推广的案例，但这只是个例）。Twitter 上就有不少人不同意我的说法：

"吾之蜜糖彼之砒霜，QQ 群用的人那么多，凭什么说人家烂？不适合罢了"

也有朋友给出了建议:

• 建议用临时会话，说话完正事就退出。(refer)
• 群的成员不应该是固定的。（refer)
• 做个Twitter进化的桌面IM...

现在的群，如果非要继续沿用的话，改进的余地还有很大。产品经理请注意，下面是可以给你带来业绩的地方：学习 Twitter 风格的对话模式，针对每一条信息有上下文，便于群内的参与者能够知道信息的指向(这是非常关键的一点，否则就是乱七八糟胡乱抢话筒的会议而已)。第二，设计一个可以将"会议"记录发送到指定电子邮件的功能(这应该并不复杂)。学学 Gtalk 的优点应该不难吧?

欣喜的看到网易已经用不许员工上班时间用群了，这是个伟大的决定。

--EOF--

（注：众多推友对此文亦有贡献)

Wear Leveling

很多人对 SSD 的误解是：既然你可擦写次数有限制，比如 200 万次，那么不是没几天不久坏掉了，怎么说使用寿命还比物理硬盘长呢?

Wear Leveling 是有效提升 SSD 的 MTBF (Mean Time Between Failures)的一种技术手段。我们都知道木桶原理，对 SSD 硬盘也是这样，如果不停的对某个 Cell 擦写，那肯定很快就报废。 Wear Leveling 的基本思想就是利用算法保持所有的可擦写单位的次数是近似均匀的，这样就把写次数均匀的分散到各个 Cell 上。

Wear Leveling 翻译似乎还没有统一，有翻做均匀磨损、磨损分级、换位写入等。

对 Wear Leveling 粗略一点的描述大致是：假设更新某个数据块，假定8KB ，而可擦写块(erase block)是 256 KB，那么定位到当前数据位置后，将找个没写过或者写过次数更少的可擦写数据块写入，并不是对原来的位置反复更新。Wear Leveling 算法的效率直接影响 SSD 的寿命。

而 8K 到 256 KB 这个过程实际上是加大了 I/O 操作，称之为 Write Amplification (写放大)。当然 SSD 厂家另有其他技术尽量减少写的频率。

为什么 SSD 写入速度相对较慢?

用一句话解释：擦写块(erase block)比较大。

很明显这样做的目的是减少擦写次数，提升 SSD 寿命。但也影响了数据写入速度。

为什么 SSD 容量是 2 的幂次? 比如 32GB，64GB

这个我也不甚了了，猜测是因为 erase block 多数是 2 的幂次的缘故。物理硬盘的尺寸由来我也不甚清楚。

SSD 的擦写次数是不是致命的瓶颈 ?

这个问题太容易给用户带来疑惑。个人认为要依赖应用的特点和设计。对于合适类型的数据，基本不是问题。但对于某些特定的数据类型，那可能是灾难(比如数据库的 Redo Log)。

SSD 会给数据库应用的银弹么?

是曙光，但不会是银弹。对于密集写入的数据库应用来说，SSD 可能不会带来更多的好处。但是对于密集读的应用，那是有可能带来数量级上的性能提升。在未来若干年内，好的数据库应用仍然严重依赖于设计人员的能力和数据库管理员的优化技巧。

此外，还要期待数据库厂商针对 SSD 进行软件级别的优化。

是否从现在选择 SSD ?

典型的废话答案应该是：这取决于你的具体情况。

要看性价比，EMC 最早引入的 SSD ，性能是普通硬盘的 30 倍，价格大约也是 30 倍。而现在，在企业级市场，SSD 已经降到大约 10 倍普通硬盘的价格。如果再低一些，那绝对是比较有吸引力的。

--EOF--

其中观点仅供参考。SSD 有风险，玩家谨慎操作。而这篇文章中的有些观念有实效性，细节也可能不够准确。

Note: 这里的 SSD ，是说面向企业应用而不是面向个人消费品的。

再增加一个图：

A: 动态连接器（dynamic linker）决定使用哪个操作系统 ABI (Application Binary Interface) 库的。LD_ASSUME_KERNE 的值要设定为操作系统版本号。比如 2.4.1 。更多参见 Metalink 文档：433292.1 。

Linux 有些版本的严重 Bug：GLIBC: calloc() Breaks when Application Runs with Locked Process Address Space

补充：在 Glibc-2.5-20 以上版本修复。各发行商有单独的版本。RHEL 4.x 中在 4.7 以上修复。不过 RHEL 4.7 Kernel 也有问题。

RHEL 5 特性几个值得关注的点

其中一个是 Root device MPIO support，尽管可能没有人会在根设备用 MPIO. 另外一个是 I/O-AT 的支持，I/O-AT 是 Intel 的网络加速技术. 第三个是 Dynamically switchable per-queue I/O schedulers 。

零星记录的一点东西，以后想到什么再补充。 另外，推荐一下 hutuworm 同学的 BLOG 。很有嚼头。

--EOF--

对比了一些文章，决定还是用 nginx-fcgi 这个脚本。作者是 Daniel Dominik Rudnicki 。这个脚本要比顺子文中提到的要好一点。

该脚本中用到如下的 Perl 模块。所以使用前要确保相关 Perl 模块已经存在。要不，手工下载安装一下。

• perl-FCGI
• perl-Getopt
• perl-IO
• perl-Socket

使用命令示意：

/usr/local/nginx/nginx-fcgi -S /tmp/fastcgi.sock -l /var/log/nginx/nginx-fcgi.log
-pid /var/run/nginx-fcgi.pid

网上常见的那个脚本必须要显示的指定最为后台进程跑。不是很完善的方法。

注意事项：不能用 root 用户执行(会提示). 要用与 Nginx 相同身份的用户执行。否则可能会在 Nginx Log 中提示 Permision Denied 。

Nginx 中配置好 Log 格式：

log_format  main          '$remote_addr - [$time_local] "$request" ' 
                          '$status $body_bytes_sent "$http_referer"'  
                          '"$http_user_agent" $http_x_forwarded_for';

相对应的 Awstats 中 Log 格式为：

LogFormat = "%host - %time1 %methodurl %code %bytesd %refererquot %uaquot" 

其他的配置参考一下Sunnyu 的 "为了Awstats给Nginx添加FastCGI方式的Perl支持" 应该就成了。

BTW: 应该说，Nginx 能够有效抵挡搜索引擎爬虫对网站的影响。对于 Apache 来说，这是个很大的进步。

--EOF--

更新：如果手工写脚本做 Nginx 日志 logrotate 的话，注意不要简单的用 mv 命令, cp 然后 echo ''> 的方式更好。

推荐： Sina 张宴的 Nginx 0.7.x + PHP 5.2.6（FastCGI）搭建胜过Apache十倍的Web服务器（第4版），这是目前关于 Nginx 最详细的实践文章。

fsck -- file system consistency check

如果有可能，不要手工运行 fsck 命令。关于人为调用 fsck "修复" 系统而引起更大灾难的实例已经有很多了。

Unix 的 rm 命令问题

rm 命令可能是最容易给 Unix 使用者带来麻烦的一个命令，但我想这个命令带来的问题几率可能并不如 fsck 那么高。所以放到第二位。另请请参考我以前写的 如何避免 Unix 环境中的 'rm -rf' 灾难 这个帖子。

crontab -r -- 不经提示删除了 cron 内容

这条命令我从来没用过，是网友留言提示的，看来他深受其苦，或许还有同病相怜的人。

source ~/.bash_history

The source command sends the contents of a text file to the Unix shell. 我相信如果有人运行了这样的命令，肯定是命令行自动补全惹得错 :)

或许还有很多命令是尽量不要运行的，话说回来，在 Unix 系统里面运行每个命令都需要谨慎。IBM dw 上这篇关于系统管理员的"懒惰"我倒是挺认同的，无为而治。

上面提到的 Unix ，包括 GNU/Linux，具体的 Shell 具体对待。

--EOF--

还有个老生常谈的提醒：不要在 root 用户下做日常操作。

下载 AIX 5L Expansion Pack CD 中的 rsync，这个版本稍微有点低。其实也足够了，不过如果和更高版本混用的话，会报告另外一个错误：

sync: connection unexpectedly closed (24 bytes read so far)
rsync error: error in rsync protocol data stream (code 12) ...

在 AIX 上 rsync 需要依赖 Popt--A C library for parsing command line parameters，通过 rpm 命令安装即可. 现在的 AIX 系统默认应该就有安装 rpm （AIX-rpm) 工具包的.

在维基百科上 有 对 rsync 算法的介绍。简单的理解是这么回事：待传送的文件被分成若干定长的文件段，然后对每个文件段做个 "Rolling Checksum"，加上一个强 MD4 校验码, 传送这些信息给接收方, 接收方查找本地类似文件--定长的每个文件段, 对比 Rolling Checksum 与 MD4, 然后传送差异(Delta)数据.

rsync 1996 年才被搞出来，最初是用来对付在低速网络连接上传送差异化文件的。

我一直比较好奇的是 Oracle 的 Data Guard 用什么算法保证所有的归档能无差错传送到远地(?)。

--EOF--

以前介绍过 GNU 核心工具，不过没介绍那份有趣的 GNU Core Utilities FAQ，前两天又重新读了一遍。多少有点新内容。比如那个比较经典的问题，“Linux 下 df 与 du 显示的为什么不一样" (我自己就遇到过一次)，在 FAQ 上更新了很有权威性的线索: df and du report different information。

我这里补充一下的是，在比较大的文件系统上，保留给超级用户的数据块也可能会产生混淆。默认是 5%，如果文件系统比较大，这里的浪费还是比较惊人的，需要就实际情况作权衡。这个也会对 df 的显示有影响。如果创建文件系统的时候需要修改，用"-m"参数指定特定的百分数。

虽说差不多每天都在用 Unix ，但是总有无数知识盲点.

--EOF--

在那本著名的 Unix 痛恨者手册 上，rm 问题也作为一个罪状而提出。的确，Unix/Linux 的这个 rm 的 -f 参数是系统管理员（SA)乃至数据库管理员(DBA)最容易引发系统灾难的导火索。

如何避免这样的灾难发生呢?

如果一个人能不犯任何误操作就好了。但这是不可能的。我相信肯定有很多 DBA 或 SA 到现在也没烦过这样的错误，但不要忘了墨菲定律的诅咒。

1.有安全的 rm 命令麽?

一种比较理想的是如果编译源代码的时候把这个 -f 选项去掉，肯定能让不少人少犯错误。不过搜索了整个网络，好像还真没有具体如何操作的。Sun 的 Solaris 10 对 rm 作了一点改进处理，"rm -rf /" 是不允许的。可惜的是 "rm -rf *"类似的操作是没限制的。另外，对于其他系统也不可用。或许，将来 GNU/Linux 能有改进。

2.Alias 方式

第二个方式是在 Profile 层次上设置命令别名( alias ).

alias rm="rm -i"

3.替代命令

第三个方法是使用替代命令。如用一个 del 命令来替代 rm. 这个就要挑战用户的使用习惯了。真的会始终用替代命令麽? 这个方式需要注意的是，无论如何不要真的把 rm 命令挪走(比如物理的 rename 名字)，如果这样，是很糟糕的策略。

4.修改权限

也有不少人直接把 rm 的权限修改，比如只允许 root 用户而不允许普通用户执行命令。这在调用一些脚本或者编译文件的时候，很容易引来很多麻烦。

任何一种策略，如果要扩大应用到一个团队的话，还需要考虑使用习惯对其他成员带来的影响。毕竟，"不爽"也会让很多人更容易犯错。

最后，友情提示，有的人经常通过层层跳板 Login 到主机上，可能会因为忘记了"身在何处" 而犯错误，最管用的方式是设置一下 PS1 环境变量。比如我在 Dreamhost 上用这样的：

PS1="\n\e[1;37m[\e[m\e[1;32m\u\e[m\e[1;33m@\e[m\e[1;35m\h\e[m \e[4m\`pwd\`\e[m\e[1;37m]\e[m\e[1;36m\n\e[m\\$ "

--EOF--

Redhat 应该是从 RHEL4 U2 开始正式增加的对 Device Multipath IO (MPIO) 的支持。SuSE Linux 则是在 SLES9.2 以后就提供支持了，谁先谁后我还真的不知道，不过SuSE 在这方面还真是一直比较激进，或许这也反映了追赶者的一些急躁心态。

关于如何设置 DM 可以参考 RedHat 站点上的一篇 FAQ：How do I setup device-mapper multipathing in Red Hat Enterprise Linux 4?。对于 RHEL 5 ，有一本 Using Device-Mapper Multipath 手册。另外，这里有篇中文的测试，步骤比较详细。

有些存储厂商在 Linux 上没有自己专有的多路径工具，如果需要类似的功能一般是推荐用 DM，但是我对负载均衡算法还有些持保留意见。 IO 路径选择器只有默认的 round-robin 。在负载均衡配置下，似乎这东西每个路径 在 1000 个 IO 之上就会重新选择路径(这个地方我不确定，谁来澄清一下?)。没有最小 IO 队列算法和最小服务时间等算法可供选择。

涉及到的 Oracle 支持情况: Oracle ASM 支持 DM 映射出来的设备.

--EOF--

有些 Linux 数据库服务器用的比较低端的存储，因为业务的变化，有时候需要新增一些 LUN。Linux 服务器添加 LUN 后必须要重启动 ? 有的时候存储厂商工程师也这么说，不过这似乎是一个一直被误解的信息。

从专攻存储的同事那里得知利用 QLogic FC HBA LUN Scan Utility 这个脚本即可无需重启动系统而识别新添加的 LUN。也无需对 QLogic FC driver 的重新 Load。

场景：Linux Server + QLogic 的 HBA 卡 。以 QLogic 的 Qla2340 HBA 卡为例。下载该脚本(顺便说一下，该页面的 QLogic FC HBA Information Utility 也比较有用)。然后看一下脚本说明文件。

用法最简单只需要运行：

# ./ql-dynamic-tgt-lun-disc.sh

脚本会提示在没有活动 IO 的情况下运行。其实问题不大的了。 之后确认 OS 识别到新设备:

 # fdisk -l 

如果系统中有 PowerPath ,还需要运行：

# powermt config 

OK。多少提高了一点系统可用性，你可以不用向老板申请停机维护了。

附：另外一篇参考文档.

--EOF--

上午是 CLARiiON 的简单介绍，在模拟操作的时候我发现了以前漏掉的一个盲点：Binding LUN 的时候，那个 Alignment Offset 的选项到底是干啥的? 讲师简单说了一下，感觉不太对路子。刚才闲下来，查找了一下这个信息，大致搞明白了这个 ”Alignment offset“。

用 ”Alignment offset EMC“ 作关键字搜索到的第一篇文档是 Dell 工程师写的。这里面用了一个词 "signature block" , 莫名的一个词，我相信是 Dell 工程师自己发明的(用 Metadata 不就得了)。另外两个关键词是 "Windows" 和 "31.5KB" ，为啥是 31.5KB ，不知道。接下来在 EMC 的 Powerlink 网站上找到了比较详细的说明。

首先确定一下，这个问题更多是影响 Windows 系统。

老的 BIOS 代码，使用 ”柱面、磁头、扇区数“这一套机制而不是 LBA （Logical block addressing ）的模式来寻址。Linux 的 fdisk 工具还是 Windows 磁盘管理器，在每个格式化的设备上都放置一份 MBR 。这个 MBR 占用 63 个隐含扇区 (63*512=31.5KB, Bingo!)。这个问题在 Windows 上存在，在 VMware 上也存在，offset 同样是 63。 在有些 Linux 上，因为 Boot Loader 的不同，也会有类似的问题。

无视 Alignment offset 会导致的问题:

如图所示，一个 IO 会分裂到两个 Disk(Device/LUN) 上去，后果很严重。和我以前描述过的 4k Offset 问题本质上是一样的。只是这个是针对文件系统的。

那么，如何校正这个 ”对齐偏移量" 呢?

存储厂商的推荐是如果用 Snap View / SAN Copy 等存储级别的操作的话，不要折腾，用系统默认的就成，否则，用主机端的解决方案。

主机端的解决方案分为 Windows 32位、Windows 64 位、Linux、VMware 几种。

1） 对于 32 位的 Windows ，使用 Windows 系统资源包的 diskpar.exe 来设定 offset ( 据说 Windows 2003 SP1 上的 diskpart.exe 已经具备了 diskpar.exe 的功能。refer)

2）对于 64 位的 Windows ，GPT(GUID Partition Table)类型的分区默认有 32M 保留区，MBR 类型的分区自动校准。不存在这个问题。这就是 64位 的 Windows 众多优点之一啊。

3) 对于 Linux ，fdisk /dev/{devicename} 然后进入 expert 模式, 然后输入 b ...

4) 对于 VMware，分为两种情况。虚拟机层（用虚拟机下操作系统的方案) 以及 ESX 服务器层 (fdisk).

上面几个步骤描述不详细，更详细的介绍你需要寻找一份白皮书： EMC CLARiion Best Practices for Fibre Channel Storage ，这个白皮书有针对 Flare 不同版本的，Flare 2.6 对这个问题有了比较好的改进。

是的，有的时候白皮书就在那里，只是没有人注意，没有看而已。

--EOF--

JFS2 的新特性

关掉 JFS2 的 Log: mount 的时候 log=NULL 可以关掉 JFS2 的日志。在一些特定的场合(如：恢复)会比较有用。另外一个特性是内部快照(internal snapshot)，即可以在同一文件系统上创建快照。

限制每进程的线程数

在以前的版本中这是做不到的，AIX 6 可以通过静态或者动态的方式修改每个进程的线程数量。属性由RLIMIT_THREADS 与 RLIMIT_NPROC 值控制. ulimit -a 可以查看值。

线程环境变量 pthread 1:1

pthread 也就是 POSIX Threads，AIX 6 对 "contention scope" 的 m:n 做了调整。 AIX 5 上 跑 Oracle RDBMS, Oracle 建议 export AIXTHREAD_SCOPE=S. 看来以后不用这么费事了。

补充一下这个 M:N ，一共有三种:

• M:1 (Library) 模型：M:1 (库模型）,每个进程都有一个核心线程。竞争范围：process(本地)
• 1:1 (Kernel) 模型：每个用户线程都有自己的核心线程。竞争范围：system (全局)
• M:N (Hybrid) 模型：M 个 用户线程对应 N 个 Kernel 线程。默认是 8:1(AIXTHREAD_MNRATIO) 。竞争范围：以上两种方式混合)

这个变化多少了反映了 IBM 在计算模式变化的方向上的倾斜。

动态虚拟内存 Page Size

AIX 6 支持四种值，4k、64K、16M、64GB. 一个新的需要知道的缩写：Dynamic variable page size support (VPSS)。VMM 可以动态修改 Page size ; 大的 page size 对应用是透明的(是不是会触发Bug，鬼才知道); 硬件支持(Power 6)的情况下 VPSS 是激活的。

”限制性可调“的核心参数

AIX 6 对一些比较关键的参数划了个类别：”限制性可调“(restriccted tunables) ，调整的时候会警告用户, 建议在厂商指导下进行:)

其他

安装程序更新了，现在是......图形化安装了

--EOF--

先看一个示意图:

从上图可以看出，Amazon 的架构是完全的分布式，去中心化。存储层也做到了分布式。

Dynamo 概述

Dynamo 的可扩展性和可用性采用的都比较成熟的技术，数据分区并用改进的一致性哈希(consistent hashing)方式进行复制，利用数据对象的版本化实现一致性。复制时因为更新产生的一致性问题的维护采取类似 quorum 的机制以及去中心化的复制同步协议。 Dynamo 是完全去中心化的系统，人工管理工作很小。

强调一下 Dynamo 的"额外"特点：
1) 总是可写
2) 可以根据应用类型优化

关键词

Key: Key 唯一代表一个数据对象，对该数据对象的读写操通过 Key 来完成.
节点(node)：通常是一台自带硬盘的主机。每个节点有三个 Java 写的组件：请求协调器(request coordination)、成员与失败检测、本地持久引擎(local persistence engine)
实例(instance)；每个实例由一组节点组成，从应用的角度看，实例提供 IO 能力。一个实例上的节点可能位于不同的数据中心内, 这样一个数据中心出问题也不会导致数据丢失。

上面提到的本地持久引擎支持不同的存储引擎。Dynamo 上最主要的引擎是 Berkeley Database Transactional Data Store(存储处理数百K的对象更为适合），其他还有 BDB Java Edition、MySQL 以及 一致性内存 Cache 等等。

三个关键参数 (N,R,W)

第一个关键参数是 N，这个 N 指的是数据对象将被复制到 N 台主机上，N 在 Dynamo 实例级别配置，协调器将负责把数据复制到 N-1 个节点上。N 的典型值设置为 3.

复制中的一致性，采用类似于 Quorum 系统的一致性协议实现。这个协议有两个关键值：R 与 W。R 代表一次成功的读取操作中最小参与节点数量，W 代表一次成功的写操作中最小参与节点数量。R + W>N ，则会产生类似 quorum 的效果。该模型中的读(写)延迟由最慢的 R(W)复制决定，为得到比较小的延迟，R 和 W 有的时候的和又设置比 N 小。

(N,R,W) 的值典型设置为 (3, 2 ,2),兼顾性能与可用性。R 和 W 直接影响性能、扩展性、一致性，如果 W 设置 为 1，则一个实例中只要有一个节点可用，也不会影响写操作，如果 R 设置为 1 ，只要有一个节点可用，也不会影响读请求，R 和 W 值过小则影响一致性，过大也不好，这两个值要平衡。对于这套系统的典型的 SLA 要求 99.9% 的读写操作在 300ms 内完成。

--待续--

更多阅读：Dynamo学习 -- http://donghao.org/2008/10/dynamoni.html