转自：http://www.aspiringcraftsman.com/2008/01/art-of-separation-of-concerns/
Introduction
In software engineering, Separation of Concerns refers to the delineation and correlation of software elements to achieve order within a system. Through proper separation of concerns, complexity becomes manageable.
The goal of this article is to promote the understanding of the principle of Separation of Concerns and to provide a set of foundational concepts to aid software engineers in the development of maintainable systems.
阅读全文 The Art of Separation of Concerns
服务器失效时正常的。 存储和处理的数据是海量的。 文件不会被频繁写入和修改。 机柜内的数据传输速度大于机柜间的数据传输速度。 海量数据的情况下移动计算比移动数据高效。
Eventually Consistent – Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.
可以从两个角度看待一致性。一个是从开发者、客户端的角度：它们如何观察数据更新。第二种是从服务器端看待：更新如何流通整个系统且系统对更新有什么保证。
客户端一致性：
客户端需考虑一下部分：
存储系统 它在本质上是大规模且高度分布的系统，其创建目的是为了保证耐用性和可用性。 进程A 对存储系统进行读写。 进程B和C 这两个进程完全独立于进程A，也读写存储系统。无论B、C是真正的进程还是进程内的现场，它们是相对独立的。B、C需要通信以分享信息。客户端一致性必须处理一个观察者（在此即进程A、B或C）如何以及何时看到存储系统中的一个数据对象被更新。 强一致性 在更新完成后，（A、B或C进行的）任何后续访问都将返回更新过的值。 弱一致性 系统不保证后续访问将返回更新过的值，在那之前要先满足若干条件。从更新到保证任一观察者看到更新值的时刻之间的这段时间被称为不一致窗口。 最终一致性。这是弱一致性的一种特殊形式；存储系统保证如果对象没有新的更新，最终所有访问都将返回最后更新的值。如果没有发生故障，不一致窗口的最大值可以根据下列因素确定：比如通信延迟、系统负载、复制方案涉及的副本数量。DNS是实现最终一致性的最流行的系统。
客户端一致性模型的变体有：
因果一致性。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。 “读己之所写”一致性。这是一个重要的模型。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。 会话一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某种错误，会话被中止，一个新的会话需要创建，且系统的保证不会使两个会话重叠。 单调读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。 服务器端一致性
几个定义：
N = the number of nodes that store replicas of the data
W = the [...]
Most of the data, Most of the time.
一. 什么是CAP 1. Atomic Data Objects (Consistent)
为了保证一致性，所有的操作必需保证有序，且每一个操作看起来在一瞬间完成。这等价于要求分布式的共享内存好像就在一个节点上，一次相应一个操作。对于原子的读写共享内存操作有一个重要的性质，即当完成一个写操作后，读操作必需返回正确的值。这是一致性最简单的模型。
2. Available Data Objects(Availble)
关于可用性一个比较弱的定义：对于一个算法完成的时间没有限制，即允许无限制的计算。一个比较强的定义是：即使当严重网络故障发生时，每个请求都必须要能终止（返回给客户端）。
3. Partition Tolerance
分区即当不允许消息任意的在节点间传输。当一个网络被分割，从一个分区内的任意节点往另一个分区的节点发送的消息都会丢失。
例如：如果有一个数据库允许在80个节点上分布于两个机架，当连接两个机架的的网络故障时，现在这个数据库是被分区的。如果数据库是分区容错的，那么数据库现在在各自的分区仍然可以进行读写操作。如果不是分区容错，那么这个集群就完全不能访问。
定理：任何分布式系统只可同时满足以上二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。
二. 概念、定理
两个基本概念：
异步网络模型 没有时钟，节点所做的决定只依据收到的消息和本地计算
In the asynchronous model,there is no clock,and nodes must make decisions based only on the messages received and local computation.
[...]
Amazon Dynamo 论文。几乎所有懂 NoSQL 的人都阅读过它。
Google 的 Bigtable 论文。 也许您已经耳熟能详。
Werner Vogels 的 Eventually Consistent （发布于 ACM Queue）。如果您对最终一致性不是非常清晰，请阅读这篇文章。
Brewer 的 CAP 理论（可伸缩性的基础）在这里可以找到非常好的诠释。也可以看看 2000 7 月 PODC 上 Brewer的原始幻灯片。
在 2009 年 6 月在 SFO 的 NoSQL 见面会的幻灯片。这些资料可以用经典的、关键的、将影响巨大的、值得纪念的来形容。
SQL Databases Don’t Scale 是一篇简短、基础、直切问题的文章。除非您是一位在伸缩性问题上身经百战的数据库管理员，否则，这篇文章讲述的内容对于您可能是非常关键的。
Jonathan Ellis 的文章 NoSQL Ecosystem 以表格的方式对当今主流的分布式数据库做了比较。类似的比较还有 Quick Reference to Alternative data storages。Ellis [...]
