上周五我们继续内部技术讨论，对某Java Web应用进行了latency分析。Latency主要是分析一个URL高并发请求下消耗时间的分布，比如ab(ApacheBench)输出结果最后一段

Percentage of the requests served within a certain time (ms)
  50%      5
  66%      6
  75%      6
  80%      6
  90%      7
  95%      8
  98%     10
  99%     18
 100%     92 (longest request)

表示99%的调用是在18ms返回的，从结果来看latency比较低，反映相应URL的性能是比较理想。

这次技术讨论首先是情况介绍，测试工程师介绍了主要URL从本地IDC到全国的latency的分布图。另外DBA也从数据库的角度介绍了DB层面常见的latency来源。这样会后我们可以对最明显的问题进行优化和改进。

除去通用的问题之后当然是讨论方法，程序员关注的重心大部分还是从应用层面怎么降低latency。

压力测试

很多Web开发的朋友也经常讨论Web应用如何有效的进行压力测试，目前也没有万能的方法。可以使用的工具有loadrunner, 或者Erlang语言开发的tsung等，很多公司也有自己的内部工具。HTTP/Memcache/MySQL等协议压力测试其实相对简单，通常用自己脚本或者高级语言开发的工具比起通用工具来说效果会更佳。

profiling

对接口进行Profiling是发现瓶颈最直观的方法，Google据说就有很完善的内部profiler工具(当然Google内部什么工具都有)。我们讨论了目前不同开发人员使用的profiling方法的优缺点。

1. 直接使用专业工具，比如JProfiler, 还有Java自带的JVisualVM等。
2. AOP(Aspect-oriented programming)的方式，优点是对程序没有污染，在外部配置需要profiling的方法。
3. 工具类的方法，需要在service方法前后加入小量关键点，优点是纯Java的实现，可以运行时动态打开或关闭profiler。比如通过给进程发signals的方法(见Signals and Java)动态让程序输出当前运行情况，起到了能够动态profiling服务器但在正常情况下又不影响服务器性能的作用。

从讨论情况来看大部分开发人员还是倾向于方法3，我们也希望团队能逐步建立类似Google内部profiler之类自己的工具。

• 谈团队每周技术交流
• Twitter“鲸鱼”故障技术剖析
• 用Python实现CRUD功能REST服务
• 使用脚本引擎增加程序运行时动态执行能力(Java篇)
• Memcache mutex设计模式

场景

Mutex主要用于有大量并发访问并存在cache过期的场合，如

• 首页top 10, 由数据库加载到memcache缓存n分钟
• 微博中名人的content cache, 一旦不存在会大量请求不能命中并加载数据库
• 需要执行多个IO操作生成的数据存在cache中, 比如查询db多次

问题

在大并发的场合，当cache失效时，大量并发同时取不到cache，会同一瞬间去访问db并回设cache，可能会给系统带来潜在的超负荷风险。我们曾经在线上系统出现过类似故障。

解决方法

方法一
在load db之前先add一个mutex key, mutex key add成功之后再去做加载db, 如果add失败则sleep之后重试读取原cache数据。为了防止死锁，mutex key也需要设置过期时间。伪代码如下
(注：下文伪代码仅供了解思路，可能存在bug，欢迎随时指出。)

if (memcache.get(key) == null) {
    // 3 min timeout to avoid mutex holder crash
    if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
        value = db.get(key);
        memcache.set(key, value);
        memcache.delete(key_mutex);
    } else {
        sleep(50);
        retry();
    }
}

方法二
在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。伪代码如下

v = memcache.get(key);
if (v == null) {
    if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
        value = db.get(key);
        memcache.set(key, value);
        memcache.delete(key_mutex);
    } else {
        sleep(50);
        retry();
    }
} else {
    if (v.timeout <= now()) {
        if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
            // extend the timeout for other threads
            v.timeout += 3 * 60 * 1000;
            memcache.set(key, v, KEY_TIMEOUT * 2);

            // load the latest value from db
            v = db.get(key);
            v.timeout = KEY_TIMEOUT;
            memcache.set(key, value, KEY_TIMEOUT * 2);
            memcache.delete(key_mutex);
        } else {
            sleep(50);
            retry();
        }
    }
}

相对于方案一
优点：避免cache失效时刻大量请求获取不到mutex并进行sleep
缺点：代码复杂性增大，因此一般场合用方案一也已经足够。

方案二在Memcached FAQ中也有详细介绍 How to prevent clobbering updates, stampeding requests，并且Brad还介绍了用他另外一个得意的工具 Gearman 来实现单实例设置cache的方法，见 Cache miss stampedes，不过用Gearman来解决就感觉就有点奇技淫巧了。

附：本次Web2.0技术沙龙演讲主题：微博Cache设计谈，需下载请点击演讲稿下menu/download (需登录slideshare)。

• Memcached数据被踢(evictions>0)现象分析
• Web 2.0技术沙龙设想
• Twitter架构图(cache篇)
• MemcacheDB, Tokyo Tyrant, Redis performance test
• FarmVille(美版开心农场)谈架构:所有模块都是一个可降级的服务

内容选取

大部分都是接近工作的，比如应用层如何访问cache及db、当前项目的重构或某个复杂的算法等。比如一个重构的话题让大家找出项目中目前不合理的若干问题，并分析这些问题存在的历史原因。然后大家分别发表自己认为合适的解决方案并进行讨论。

可以取得的成效

• 团队成员取长补短，获得更全面的技术
• 分享经验，避免成员步入已知的雷区
• 提高分析技术问题的能力
• 认识不足，找到自己需要提高的方向
• 达成团队更多共识，比如什么是好的做法什么是不推荐的做法

后续主题

以后可以进一步考虑的讨论主题，最大的原则是考虑跟近期项目有相关性，比如

• 互联网应用合适的压力测试方式
• profiler 系统性能分析，热点调用的主要消耗点并提出解决方案。
• 工具介绍，可以提高效率或者对工作有帮助
• 某个算法，如粉丝排序

与code review的区别

code review关注代码细节, 团队讨论更关注宏观抽象层面的问题，但部分时候团队讨论也进行一些有代表意义的code改进。

与主题演讲区别

倾向于圆桌式的讨论，需要大家参与的开放式问题。以前也尝试过主题式的，但是由于团队内的主题演讲空间有限，演讲者可能要先精通某个领域才适合讲，如果每周一轮不太可行，比如Facebook Engineering tech talks也是精英演讲的方式，结果也不是非常活跃。因此每周一次更合适讨论一些跟工作相关未达成共识的话题，这样更敏捷，也更容易给参与者带来成效。

-EOF-

广告：我们团队招收各层次技术人才，包括Java后端工程师，数据架构师(MySQL)，PHP工程师, 数据挖掘工程师(如精通Hadoop)等，工作地点是北京，有兴趣可以直接给我邮件。

上次提到的Web 2.0技术沙龙已经与CSDN顺利举行了第一期，由于之前报名的已经非常多，就未在博客上宣传了，第一期活动今天已经结束。

• 广州技术沙龙安排
• 降低应用latency方法谈
• 做卓有成效的程序员
• 广州技术沙龙设想
• 为什么优秀开发者进入Google后就不参与开源了

For now, we’re not working on using Cassandra as a store for Tweets. This is a change in strategy. Instead we’re going to continue to maintain our existing Mysql-based storage. We believe that this isn’t the time to make large scale migration to a new technology. We will focus our Cassandra work on new projects that we wouldn’t be able to ship without a large-scale data store.

Twitter为什么要停用Cassandra

我们来分析一下Twitter停止使用Cassandra的原因
1. Cassandra仍然缺少大并发海量数据访问的案例及经验，Cassandra来源自Facebook，但是在Facebook内部Cassandra目前只用在inbox search产品上，容量大约有100-200T。且Inbox Search在Facebook的基础架构中也并非核心应用。并且还传出不少rumors说facebook已经放弃Cassandra。

2. 新产品需要一定稳定期，Cassandra代码或许还存在不少问题，但是Twitter如果投入大量的精力来改进Cassandra和比较优化MySQL的投入来看有点得不偿失。在QCon Beijing上@nk也提到Cassandra在Twitter的内部测试中曾经暴露出不少严重的问题。

Twitter为什么之前选用Cassandra

此问题曾经在QCon Beijing 2010做过介绍，在去年的第一期广州技术沙龙也有过交流，类似Twitter这样的网站使用Cassandra的主要原因有
1. 数据增长规模需要不断增加新服务器，传统的切分方案在面临增删硬件时候需要手工维护，当数据规模速度增快，业务又不运行停机维护，手工维护的成本增加造成系统运维不堪重负。
2. 不能简单增加服务器解决请求量增长的问题，需要数据架构师精细的规划。
3. 每一个新的特性都需要重复评估数据拆分及访问优化的问题，架构师需要投入大量精力review几乎相同的业务场景。

Twitter的调整对于MySQL业界来说或许是一大利好，MySQL虽然受近期Oracle收购阴影的影响，但是对于目前大多数拥有海量数据访问的网站依然是他们第一选择。MySQL简单，可靠，安全，配套工具完善，运维成熟。业界碰到的大部分可扩展性方面的问题在MySQL中其实都有清晰明确的解决方法。虽然重复sharding的问题很烦，增删机器相关的运维工作也很繁琐，但是这些工作量还是在可以接受的范围内。

究竟Twitter这次策略改变是NoSQL运动的一次挫折还是前进中的一段小插曲？我们拭目以待。目前另外一大Web 2.0巨头Digg仍然在使用Cassandra。

• 2010年的技术架构建议
• Web 2.0技术沙龙设想
• Facebook平台设计(二)
• Twitter架构图(cache篇)
• FarmVille(美版开心农场)谈架构:所有模块都是一个可降级的服务

Social platform话题

• Feed架构, 讨论feed在微博及sns如何高效的投递
• Cache, RAM is the new disk, cache使用近几年已经发生了不少变化，可以进一步探讨cache架构如何设计
• 分布式key value面临的挑战，如尝试cassandra心得
• Realtime search
• Social数据分析(如hadoop)

Social app话题

Social app方面我也不太擅长，不过公司有不少开发无线以及产品设计的geek在闲聊中比较有兴趣，先列进来，效果不好随时cancel。

• HTML5 app
• LBS (Location-based Services) 技术
• OAuth 前几天在微博上戏称OAuth是一种典型的过度设计，用于解决非HTTPS环境第三方受信问题。

主要考虑在北京搞，Twitter上立即有不少回应表示意向，有兴趣的可以进一步交流。联系方式可看博客首页或者关于页。

• 广州技术沙龙设想
• 谈团队每周技术交流
• Twitter架构图(cache篇)
• 构建可扩展的微博架构(qcon beijing 2010演讲)
• 第一期广州技术沙龙活动总结

if (state == TEXAS) {
        rate = TX_RATE;
        amt = base * TX_RATE;
        calc = 2 * basis(amt) + extra(amt) * 1.05;
} else if ((state == OHIO || (state == MAINE)) {
        rate = ((state == OHIO) ? OH_RATE : ME_RATE);
        amt = base * rate;
        calc = 2 * basis(amt) + extra(amt) * 1.05;
        if (state == OHIO)
                points = 2;
} else {
        rate = 1;
        amt = base;
        calc = 2 * basis(amt) + extra(amt) * 1.05;
}

可能很多人读此代码都有似曾相识之感，不错，我们身边不少程序员就是如此编程的。这段代码就是由于太多Repeat造成罗嗦难懂，结构复杂，维护困难。大家可能都会迅速想到两点重构方法
1. amt, calc 可以移出来
2. 第2个if可以拆分

但是这样就完美了吗？4个if/else是否让人闻到一股不对劲的气味？这段程序是否还是传统结构化编程思维？if条件中state再增多程序会怎样？因此虽然是一段很短的代码，但是重构优化实际是无止境的。

再谈巧合编程(Don’t Programmer by Coincidence)，在很多项目中其实也很常见，巧合编程就是有问题的代码在开发过程中恰好能运行通过，但是运行在别的环境很容易就出问题，比如下面的C++代码

        a = 2;
        b = 3;
        if (a + b != 5) exit(1);

什么情况会exit(1)?

传统智慧认为，项目一旦进入编码阶段，工作主要就是机械的把设计转换成可执行语句。这种态度是许多程序低效、不可维护的最大原因。
⋯
我们大多数人都能够几乎自动地驾驶汽车，我们不用明确的命令我们的脚踩刹车，或是命令手动方向盘，我们只是想“减速并右转”。但是，可靠的司机会不断查看周围的情况，检查潜在的问题，并且让自己在万一发生意外时处在有利的位置上。编码也是这样。

因此开发过程质量问题非常重要, 有经验的程序员懂得如何避开前进过程中的各种雷区。Code review就是在你的驾驶过程中，由另外一名有经验的驾驶员坐在副驾的座位上，帮你纠正各种危险的驾驶习惯，避免在当时或以后踏入各种已知的雷区。

本文读后感已先前在新浪微博发出，收到过几十条转发及评论。微博的内容或许更有灵感并及时，欢迎关注http://t.sina.com.cn/timyang

• 多服务器通讯层应该如何设计—一次code review小记
• 做卓有成效的程序员
• Friendfeed的MySQL key/value存储
• 5%的神话(关于开发效率与职业方向)
• 用Python实现CRUD功能REST服务

大部分章节是介绍具体的方法来如何提高程序员工作效率。记住具体的技巧未必有太大价值，很多人都认同一种观点就是，读一本书最终的目标是忘记其中所有的观点，但是它会潜移默化影响了你以后的思维和或观点，包括你的行为。因此我认为此书直接的影响就是帮助思考开发过程的方法和问题，思考以前的惯例是否存在问题。比如最近在设计某个产品删除功能的时候，一位同事突然提到是否产品将来有需要查看行为历史，如果需要记录历史，删除的流程就会变复杂，不但影响删除功能的实现，还会影响后端数据的规模，从而进一步会影响架构的设计。因而我的直觉是这是一个过早优化，也就是书中第9章讲的YAGNT(You Ain’t Gonna Need It 你不需要这个特性)。由于第一时间的质疑，这个可能需要耗费大量开发时间的特性被暂停，对于项目本身或许是一件好事。

此外书中一些敏捷的思路也会带来一些间接影响,我还意识到过去一些非敏捷方法可能会给项目带来风险，一个过去的项目，开发完成之后逐渐变得臃肿，和大部分后端服务相似，需要依赖一些特定的数据库及其他依赖环境。由于不希望开发环境与真实环境差距太大，开发环境也全部按真实环境最小单元的配置来进行，这就导致开发依赖的环境很多

内部依赖
MySQL master/slave
分表
Memcached(多个)

外部依赖
Message Queue(消息队列)
用户及鉴权服务
internal HTTP service

导致的问题
需要特定的环境才能开发，比如公司配好的环境中
无法在家中或咖啡馆干活，因为系统跑不起来，无法看到效果
一旦部分依赖环境有问题，则无法开工，只能等着服务恢复
一旦几天没跟进代码，可能就由于环境设置的变化而无法独自启动工程。

这些问题就导致代码改进的工作令人生畏，要像Google那样做到任何对代码感兴趣的人可以patch代码的意愿都会变成”mission impossible”。因此对于这个项目来说，最急需的一个改进是分析依赖，让项目能够随时随地可以方便的跑起来，大家可以很简单的改进代码，对改进的代码进行测试验证，测试之后新的代码基本可以无风险的运行到线上环境去。否则臃肿的项目只会降低大家的贡献的热情，最后变成一个死气沉沉的工作任务。

你的项目中的惯例是否存在问题呢？比如Java中POJO中无用的get/set方法，比如一些使用c/c++来“优化”项目中的瓶颈而走向时间泥潭的经历，比如贵公司是否又在雄心勃勃要做一个自己的框架，事实上这个框架对于项目本身毫无价值。诸如此类的情况会非常多，这本书主要介绍的是程序员要如何提高自身的效率，但我觉得程序员更多的也应思考团队的效率改进并发出声音。

• 为什么优秀开发者进入Google后就不参与开源了
• 程序员修炼之道-DRY与巧合编程
• 谈团队每周技术交流
• FarmVille(美版开心农场)谈架构:所有模块都是一个可降级的服务
• 谈Linux内核定时器

• Twitter架构是单IDC设计，从它递增的tweet id就可以看出，后来当面向@nk提问也得到了证实。
• 中美网络环境差异，单IDC和多IDC有很多设计上的不同
• 大部分参会人员未必能对英文演讲有深入理解及感悟，中文的演讲可以讲一些细节解释更透彻。
• Twitter对故障的容忍度大，国内公司对服务故障通常更敏感。因此国内架构师会考虑设计方案尽量简单可靠，服务需要更稳定。国外开发团队更倾向追求在工作中应用技术创新，因此会导致架构设计理念的不少差异。

演讲的slide如下，登录slideshare之后可以下载。

这里再补充在qcon演讲未来得及考虑成熟的一个方面，用户规模影响设计，具体是指用户数每上一个数量级，许多设计需要重新考虑。

10万用户级别

• 单服务器，前端、后端、cache、db在一起。

百万级

• db和cache单独部署服务器，db或按业务进行拆分(sharding)
• cache或使用一致性hash扩展。
• 前端后端还是在一起，但是根据业务拆分，每个业务可分配不同数量的服务器

千万级

• 开始重视架构设计，有专门技术架构师
• 需跨机房部署，前端在远程增加反向代理加速，数据库在异地机房使用slave数据库副本
• 后端拆分出来，系统内部需要远程调用，内部需远程调用协议。

亿级

• 架构更细分，或增加数据架构师，cache架构师，分布式架构师
• 数据库sharding碰到烦恼，开始考虑分布式数据服务
• 数据访问需要根据业务特点细分。
• 开发、运维、测量、调优具备有自己的专有工具。
• 所有服务需要地理多机房分布，具备IDC容灾设计。
• 服务可降级

上面的数字仅供理解“用户规模影响设计”，数字本身并无具体指导价值。

另外在slide中也提到了，目前新浪微博团队急需人才，对上面相关技术领域感兴趣的架构师及各层次开发人员(熟悉PHP，Java, C或数据架构任意一种)可随时跟我联系，工作地点为北京，联系方式见博客首页。

• Twitter架构图(cache篇)
• QCon Beijing qconbeijing全部演讲资料下载
• Twitter停用Cassandra原因分析
• Web 2.0技术沙龙设想
• 陈杰谈网游服务器的后端技术

• 许多优秀开发者都很喜欢编程，他们喜欢研究有趣有挑战的问题，并不特别在意这些项目是否开源。
• 大家都太忙，Google似乎用尽了每个人的空余时间。并不是说Google强迫大家一天到晚都在干活，而是由于Google里面太多有趣的东西做了，Brad经常挂在口头一句话就是“现在手头有7个属于20%空余时间的项目”。
• Google的开发环境太好了，源代码控制，build系统，code review工具，debugger调试工具，profiler调优工具，submit queues, continuous builds, test bots, 文档以及所有相关的自动化工具及流程非常完善。因此很容易hack任何项目，在任何地方，或者给任何人提交patch，并且值得一提的是，很容易找到对应的人或者list去提交patch。通常说来，提交patch是参与特性讨论，表达诚意的最好方式，即使你的patch是有问题的。

从上面尤其是第3点来看，Google确实是技术人员的理想环境。

• 做卓有成效的程序员
• 谈团队每周技术交流
• 从技术角度看Google Wave
• 降低应用latency方法谈
• Twitter系统运维经验

背景资料 Latency差异

Jeff Dean提到不同数据访问方式latency差异

Numbers Everyone Should Know
L1 cache reference                           0.5 ns
Branch mispredict                            5 ns
L2 cache reference                           7 ns
Mutex lock/unlock                           25 ns
Main memory reference                      100 ns
Compress 1K bytes with Zippy             3,000 ns
Send 2K bytes over 1 Gbps network       20,000 ns
Read 1 MB sequentially from memory     250,000 ns
Round trip within same datacenter      500,000 ns
Disk seek                           10,000,000 ns
Read 1 MB sequentially from disk    20,000,000 ns
Send packet CA->Netherlands->CA    150,000,000 ns

这个数据对于我们设计多IDC数据访问策略具有关键的指导作用，我们可以用这个数据来衡量数据架构来如何设计才能满足高并发低延迟的目标。
这份数据实际上对所有网络应用及分布式应用开发者都具有很大借鉴作用，数据需要根据访问频率尽量放在latency小的地方。

1. 2PC/3PC/Paxos模式

在上文中提到，2PC/3PC相比Paxos有明显的缺点，因此最好不用于生产环境，这里就不再详述。
Paxos选择了CAP理论中的”Consistency, Partition”, 需要牺牲availability。它可以在多个IDC之间实现强一致性复制。

Paxos缺点

• IDC之间需要高速稳定网络
• 一个2f+1个节点的网络中，需要f+1个节点完成事务才能成功。
• Throughput低，不适合高请求量的场合。所以大部分分布式存储产品并不直接使用Paxos算法来同步数据。

2. Dynamo模式

Dynamo论文中并未专门描述Dynamo算法是否适合多IDC场景，只有少量文字提到

In essence, the preference list of a key is constructed such that the storage nodes are spread across multiple data centers. These datacenters are connected through high speed network links. This scheme of replicating across multiple datacenters allows us to handle entire data center failures without a data outage.

从上文看到，前提条件是“high speed network links” 可能对国内的情况不太适用。假如IDC之间网络不稳定，那会发生哪些情况呢？

Quorum 算法中，如果要考虑高可用性，则数据需要分布在多个机房。双机房如NRW=322由于单机房故障后可能会发生3个点中2个点都在故障机房，导致出现数据不 可用的情况，所以合适的部署是NRW=533，需要3个机房。大部分请求需要2个机房节点返回才能成功，考虑到多IDC的带宽及latency，性能自然会很差。

Quorum算法在读写的时候都要从quorum中选取一个coordinator，算法如下

A node handling a read or write operation is known as the
coordinator. Typically, this is the first among the top N nodes in
the preference list. If the requests are received through a load
balancer, requests to access a key may be routed to any random
node in the ring. In this scenario, the node that receives the
request will not coordinate it if the node is not in the top N of the
requested key’s preference list. Instead, that node will forward the
request to the first among the top N nodes in the preference list.

如果严格按照Dynamo协议，coodinator一定要在N中第一个节点，那在3个机房中将有2/3的请求需要forward到异地机房的 coordinator执行，导致latency增大。如果对coodinator选择做优化，让client选取preference list中前N个节点中在本地机房的一个节点作为coordinator，这样会一定程度降低latency，但是会存在相同的key选择不同节点作为 coordinator的概率增大，导致数据conflict的概率增大。

同时在多机房模式下，Failure detection容易产生混乱。Dynamo并没有使用一致性的failure view来判断节点失效。而是由每个节点独自判断。

Failure detection in Dynamo is used to avoid attempts to
communicate with unreachable peers during get() and put()
operations and when transferring partitions and hinted replicas.
For the purpose of avoiding failed attempts at communication, a
purely local notion of failure detection is entirely sufficient: node
A may consider node B failed if node B does not respond to node
A’s messages (even if B is responsive to node C’s messages).

而最近非常流行的Cassandra基本上可以看作是开源的Dynamo clone, 它在Facebook Inbox Search项目中部署在150台节点上，并且分布在美国东西海岸的数据中心。

The system(Facebook Inbox Search) currently stores about 50+TB of data on a 150 node cluster, which is spread out between east and west coast data centers.

虽然在它的JIRA中有一个提案 CASSANDRA-492 是讲”Data Center Quorum”，但是整体看来Cassandra并没有特别的针对对IDC的优化，它的paper[5]中提到

Data center failures happen due to power outages, cooling
failures, network failures, and natural disasters. Cassandra
is configured such that each row is replicated across multiple
data centers. In essence, the preference list of a key is con-
structed such that the storage nodes are spread across mul-
tiple datacenters. These datacenters are connected through
high speed network links. This scheme of replicating across
multiple datacenters allows us to handle entire data center
failures without any outage.

跟Dynamo中的描述几乎是相同的。

3. PNUTS模式

PNUTS模式是目前最看好的多IDC数据同步方式。它的算法大部分是为多IDC设计。

PNUTS主要为Web应用设计，而不是离线数据分析（相比于Hadoop/HBase）。

• Yahoo!的数据基本都是用户相关数据，典型的以用户的username为key的key value数据。
• 统计数据访问的特征发现85%的用户修改数据经常来源自相同的IDC。

根据以上的数据特征，Yahoo!的PNUTS实现算法是

• 记录级别的master, 每一条记录选择一个IDC作为master，所有修改都需要通过master进行。即使同一个表(tablet)中不同的记录master不同。
• master上的数据通过Yahoo! Message Broker(YMB)异步消息将数据复制到其他IDC。
• master选择具有灵活的策略，可以根据最新修改的来源动态变更master IDC， 比如一个IDC收到用户修改请求，但是master不在本地需要转发到远程master修改，当远程修改超过3次则将本地的IDC设成master。
• 每条记录每次修改都有一个版本号(per-record timeline consisitency)，master及YMB可以保证复制时候的顺序。

Yahoo!的PNUTS实际可理解为master-master模式。
一致性：由于记录都需通过master修改，master再复制到其他IDC, 因此可达到所有IDC数据具有最终一致性。
可用性：

• 由于所有IDC都有每条记录的本地数据，应用可以根据策略返回本地cache或最新版本。
• 本地修改只要commit到YMB即可认为修改成功。
• 任一IDC发生故障不影响访问。

论文中提到的其他优点

hosted, notifications, flexible schemas, ordered records, secondary indexes, lowish latency, strong consistency on a single record, scalability, high write rates, reliability, and range queries over a small set of records.

总之，PNUTS可以很好的适合geographic replication模式。

• 记录publish到本地YMB则认为成功，免除Dynamo方式需要等待多个Data Center返回的latency。
• 如果发生master在异地则需要将请求forward到异地，但是由于存在master转移的策略，需要forward的情况比较少。

极端情况，当record的master不可用时候，实现上似乎有些可疑之处，读者可自行思考。

Under normal operation, if the master copy of a record fails, our system has protocols to fail over to another replica. However, if there are major outages, e.g. the entire region that had the master copy for a record becomes unreachable, updates cannot continue at another replica without potentially violating record-timeline consistency. We will allow applications to indicate, per-table, whether they want updates to continue in the presence of major outages, potentially branching the record timeline. If so, we will provide automatic conflict resolution and notifications thereof. The application will also be able to choose from several conflict resolution policies: e.g., discarding one branch, or merging updates from branches, etc.

初步结论

低带宽网络
PNUTS record-level mastering模式最佳。
高带宽低延迟网络
(1Gbps, Latency < 50ms)
1. 用Dynamo Quorum, vector clock算法实现最终一致性
2. 用Paxos实现强一致性

后记

本文从开始准备到发布时间较长，由于在多IDC数据访问方面目前业界并无统一的成熟方案，相关资料和文献也相对较少，而且对这方面有兴趣且有相应环境的人不多，短时间要提出自己成熟独立的见解也具有一定难度，本文仅包含一些不成熟的想法的整理，由于自己对文中的观点深度也不是满意，所以一直没有最终完稿发布。但考虑到最近工作较忙，暂时没有精力继续深入研究，所以希望公开文章抛砖引玉，同时也欢迎对这方面课题有兴趣者进一步交流探讨。

Resource

1. Ryan Barrett, Transactions Across Datacenters
2. Jeff Dean, Designs, Lessons and Advice from Building Large Distributed Systems (PDF)
3. PNUTS: Yahoo!’s Hosted Data Serving Platform (PDF)
4. Thoughts on Yahoo’s PNUTS distributed database
5. Cassandra – A Decentralized Structured Storage System (PDF)
6. Yahoo!的分布式数据平台PNUTS简介及感悟

• 分布式key/value store演讲草稿(一)
• 多IDC的数据分布设计(一)
• Yahoo!的分布式数据平台PNUTS简介及感悟
• Paxos在大型系统中常见的应用场景
• Dynamo一个缺陷的架构设计(译)