一篇讲关于Dynomite的博客文章，看了觉得不错，就自己根据原文做了部分翻译，很多地方可能翻译的不是很恰当，语句通顺上面也还是需要修饰。(点击原文)
Dynomite-让非分布的数据存储变成分布式的
服务架构
目的
在开源的世界里有很多单服务器的数据存储解决方案，例如: Memcached, Redis, BerkeleyDb, LevelDb, Mysql (datastore)。这些解决方案通常采用master-slave配置。当请求非常的多，需要处理大量的流量的时候，我们就会引入集群机制。大多数人都同意，这将非常的不简单。另外，对开发者来说，这在管理数据上面也是一个挺大的挑战。
Dynomite拓扑结构
一个Dynomite集群包括了多个数据中心(dc)。每个数据中心都有多个机架(racks)，每个机架包含了多个节点。每个机架又包含了完整的数据集，这些数据集被分配在机架的多个数据节点上。所以，多个机架就能够提供数据服务的高可用性。在机架上，每一个节点都拥有一个特殊的令牌(token)号，这个令牌标记用来识别出每一个节点所拥有的数据集。
每个Dynomite节点(例如:a1,b1,c1)都有一个Dynomite进程(Process)来协调提供数据服务，他扮演了一个类似于代理(proxy)，路由(traffic router)或协调者(coordinator)的角色。在 Dynamo paper中,Dynomite是位于Dynamo层，并且提供了额外的可插拔数据存储代理的支持来尽可能的维持本地数据存储协议。
数据存储方式可以像Memcached 或 Redis这样的内存数据库，也可以像Mysql, BerkeleyDb 或 LevelDb这样的数据库，当前Dynomite支持Redis和Memcached。
数据复制
客户端能够连接到机架上的任何一个节点来发送写数据请求，如何这个节点恰好就是写请求数据的拥有着，那么该数据就会首先会被写到本地的数据服务中，并且会异步的复制到所有数据中心集群中的机架中。如果这个节点不是数据的拥有着，则它会做出协调将数据发送给同一个机架中的拥有者节点，然后同样的在所有的数据中心做一个异步的复制操作。
在当前的实现中，当一个节点在本地机架中成功的执行了数据请求操作并且异步复制到其它远程数据中心的时候，协调者会返回给客户端一个OK标记。
下面的一张图展示了一个客户端将一个写数据请求发送给了一个不是数据拥有者的例子。该数据属于a2,b2,c2和d2节点，请求被发送到了a1，然后a1将会充当一个协调者将请求转发到合适的节点。
高可用读请求
多数据中心及多机架模型提供了高可用服务。客户端能够连接到任意一个节点来读数据。跟写操作一样，当这个节点是读数据请求的数据拥有着的时候，那么它就直接提供读服务。否则，它就会将这个读请求发送到同一个机架的请求数据拥有着节点。当在远程数据中心或者机架进行数据复制操作失败的时候，Dynomite客户端将会请求失败。
可插拔的数据存储
Dynomite当前支持Redis和Memcached，这里感谢TwitterOSS Twemproxy这个项目。根据我们的经验，这两个数据库的最常用的API接口我们的已经支持。其它额外的API接口我们会在不久的将来支持。
标准的Memcached/Redis协议支持
任何可以跟Memcached或Redis进行数据交互的客户端也都可以跟Dynomite进行交互，你不需要改变什么。然而，有部分方式是不支持的，例如:故障转移策略，请求限制，连接池等。(更多的细节在客户端架构一节中)
IO事件通知服务的可扩展性
所有的输入输出流都在单线程的IO事件循环中被执行，其它额外的线程是执行后台或者管理的任务。所有的线程是通过无锁环队列来发送消息进行沟通的，消息是异步执行发送。这个实现机制能够让每一个Dynomite节点都能在处理大量客户端连接的同时仍然能够执行许多非客户端的并行任务。
Peer to peer 和线性可扩展性
每个Dynomite集群中的节点都有相同的职责，所以不存在单点故障。有了这个优点，我们就可以添加更多的节点到Dynomite集群中来。
冷热缓存
现在，这个功能在对Redis做数据库的时候是有用的，Dynomite能够帮助填满peers中的空节点从而减少性能损耗。
非对称多数据中心复制
上面提到，一个写数据操作中，数据将会被复制到多个数据中心，在不同的数据中心，Dynomite可以被配置成拥有不同的机架和节点。当在不同数据中心请求流不平衡的时候将会有极大的帮助。
节点间的沟通和gossip
Dynomite内置了gossip来帮助维护集群成员以及故障检测和恢复。这简化了Dynomite集群的维护。