【IT168 案例】Dynamo是面向Amazon自有的电子商务应用的，使用广域分布的大规模集群提供高可靠的对象存储服务，主要存储1M左右甚至更小的内容，如购物车、推荐列表等。由于Dynamo的应用场合，设计上有这么一些“独特”的要求：

　　高可靠性与高可伸缩性

　　始终可写，写优先于读(保证用户体验——用户添加购物车内容时应尽量避免失败)

　　一致性与写入速度的折衷，不要求同步写入所有副本

　　对称、务中心架构，支持异构节点

　　Dynamo的数据分布方式采用了比较典型的DHT方式，但有一些有意思的策略，比如“虚拟节点”——每个物理节点被当做多个虚拟节点：

　　分散节点的加入/删除带来的冲击：节点加入/删除会影响相邻的节点，通过多个虚拟节点，物理节点的加入/删除的影响被平均散播到多个节点上了。

　　表征异构节点的能力差异

　　此外，Dynamo支持对对象的不同版本进行记录和处理，并且可以将不同版本提供给应用，供应用自己更灵活地进行合并。对象的副本数遵循(N,R,W)的规则，N个副本，如果R个读取的一致则确定读取成功，如果W个写入成功则认为写入成功，不要求全部N个都成功完成，只要 R+W>N，数据的最终一致性就可以得到保障。这里，读取比一次写多次读的系统(如HDFS)麻烦，但写入变简单了，这反映了应用的需求。

　　看了这个设计，我大致有这么几个感触

　　应用决定设计

　　应用规模和应用类型会左右架构设计的原则和方向的采用和“写大于读”的设计都来源于此

　　精巧与实用(大巧不工)并重

　　如果说 DHT 是精巧的话，多个虚拟节点的设计相对于复杂的负载均衡等机制来说绝对算是“实用”的典范了

　　底层与应用的互动

　　版本合并的事情，放在底层叫做高效，放在应用叫做灵活，只有合适的选择，没有错误的技术