<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Bookcold&#039;s Blog &#187; CAP</title>
	<atom:link href="http://bookcold.com/tag/cap/feed" rel="self" type="application/rss+xml" />
	<link>http://bookcold.com</link>
	<description>Just for pleasure</description>
	<lastBuildDate>Sun, 29 Aug 2010 06:39:14 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>最终一致性</title>
		<link>http://bookcold.com/2010/03/333</link>
		<comments>http://bookcold.com/2010/03/333#comments</comments>
		<pubDate>Wed, 10 Mar 2010 16:20:56 +0000</pubDate>
		<dc:creator>bookcold</dc:creator>
				<category><![CDATA[系统架构]]></category>
		<category><![CDATA[CAP]]></category>
		<category><![CDATA[Eventually Consistent]]></category>

		<guid isPermaLink="false">http://bookcold.com/2010/03/11/333/</guid>
		<description><![CDATA[<p>Eventually Consistent &#8211; Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.</p> <p>可以从两个角度看待一致性。一个是从开发者、客户端的角度：它们如何观察数据更新。第二种是从服务器端看待：更新如何流通整个系统且系统对更新有什么保证。</p> 客户端一致性： <p>客户端需考虑一下部分：</p> 存储系统 它在本质上是大规模且高度分布的系统，其创建目的是为了保证耐用性和可用性。 进程A 对存储系统进行读写。 进程B和C 这两个进程完全独立于进程A，也读写存储系统。无论B、C是真正的进程还是进程内的现场，它们是相对独立的。B、C需要通信以分享信息。客户端一致性必须处理一个观察者（在此即进程A、B或C）如何以及何时看到存储系统中的一个数据对象被更新。 强一致性 在更新完成后，（A、B或C进行的）任何后续访问都将返回更新过的值。 弱一致性 系统不保证后续访问将返回更新过的值，在那之前要先满足若干条件。从更新到保证任一观察者看到更新值的时刻之间的这段时间被称为不一致窗口。 最终一致性。这是弱一致性的一种特殊形式；存储系统保证如果对象没有新的更新，最终所有访问都将返回最后更新的值。如果没有发生故障，不一致窗口的最大值可以根据下列因素确定：比如通信延迟、系统负载、复制方案涉及的副本数量。DNS是实现最终一致性的最流行的系统。 <p>客户端一致性模型的变体有：</p> 因果一致性。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。 “读己之所写”一致性。这是一个重要的模型。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。 会话一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某种错误，会话被中止，一个新的会话需要创建，且系统的保证不会使两个会话重叠。 单调读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。 服务器端一致性 <p>几个定义：</p> <p>N = the number of nodes that store replicas of the data</p> <p>W = the [...]]]></description>
			<content:encoded><![CDATA[<blockquote><p>Eventually Consistent &#8211; Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.</p>
</blockquote>
<p>可以从两个角度看待一致性。一个是从开发者、客户端的角度：它们如何观察数据更新。第二种是从服务器端看待：更新如何流通整个系统且系统对更新有什么保证。</p>
<h4>客户端一致性：</h4>
<p>客户端需考虑一下部分：</p>
<ul>
<li>存储系统 它在本质上是大规模且高度分布的系统，其创建目的是为了保证耐用性和可用性。</li>
<li>进程A 对存储系统进行读写。</li>
<li>进程B和C 这两个进程完全独立于进程A，也读写存储系统。无论B、C是真正的进程还是进程内的现场，它们是相对独立的。B、C需要通信以分享信息。客户端一致性必须处理一个观察者（在此即进程A、B或C）如何以及何时看到存储系统中的一个数据对象被更新。</li>
<li>强一致性 在更新完成后，（A、B或C进行的）任何后续访问都将返回更新过的值。</li>
<li>弱一致性 系统不保证后续访问将返回更新过的值，在那之前要先满足若干条件。从更新到保证任一观察者看到更新值的时刻之间的这段时间被称为不一致窗口。</li>
<li>最终一致性。这是弱一致性的一种特殊形式；存储系统保证如果对象没有新的更新，最终所有访问都将返回最后更新的值。如果没有发生故障，不一致窗口的最大值可以根据下列因素确定：比如通信延迟、系统负载、复制方案涉及的副本数量。DNS是实现最终一致性的最流行的系统。</li>
</ul>
<p>客户端一致性模型的变体有：</p>
<ul>
<li>因果一致性。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。</li>
<li>“读己之所写”一致性。这是一个重要的模型。当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。</li>
<li>会话一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某种错误，会话被中止，一个新的会话需要创建，且系统的保证不会使两个会话重叠。</li>
<li>单调读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。</li>
<li>单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就非常难以编程了。</li>
</ul>
<h4>服务器端一致性</h4>
<p>几个定义：</p>
<p>N = the number of nodes that store replicas of the data</p>
<p>W = the number of replicas that need to acknowledge the receipt of the update before the update completes</p>
<p>R = the number of replicas that are contacted when a data object is accessed through a read operation</p>
<p>N=节点内存储重复数据的数量</p>
<p>W=在更新完成之前需要确认收到更新的数据副本数</p>
<p>R=一个读操作需要访问的数据副本数</p>
<p>如果W+R&gt;N， 那么读写数据集总是重叠的，这就保证了强一致性。在一个主备RDBMS场景中当实现了同步复制，N=2，W=2，R=1。在异步复制且从允许从备份数据库读数据的情况下，N=2，W=1，R=1。这种情况R+W=N，则一致性无法保证。</p>
<p>如何配置N，W，R，这依赖于系统一般的应用场景和哪一种性能（CAP）需要优化。当R=1，N=W是，我们优化读的情况，当W=1，R=N时，我们优化得到快速的写的能力。</p>
<p>弱/最终一致性的产生是当W+R&lt;=N，这意味着存在读写重叠的可能。</p>
<p>“读己之所写”一致性、会话一致性和单调一致性是否可以达成，取决于客户端对为其执行分布式协议的服务器的“粘度”。如果每次都是同一台服务器，那么就比较容易保证“读己之所写”一致性和单调一致性。这样做会使管理负载平衡以及容错变得稍困难一些，但这是一种简单的方案。</p>
<p>客户端有时会实现“读己之所写”一致性和单调读一致性。通过给写入添加版本，对那些版本早于最后版本的值来说，客户端会丢弃这些值的读出。</p>
<p>在有些应用中，不可用的任何分区都是不能接受的，保证客户端能访问分割分区并操作是很重要的。这种情况下，服务器客户端分配新的存储节点接收数据，并在分区恢复后执行合并操作。例如，Amazon的购物车就是一个总是可写的系统。当出现分区时，客户可以继续往购物车添加东西，即使原有的购物车可能在其他分区。购物车应用在分区恢复后帮助存储系统合并购物车。</p>
<p>来自：</p>
<p><a href="http://www.allthingsdistributed.com/2008/12/eventually_consistent.html">http://www.allthingsdistributed.com/2008/12/eventually_consistent.html</a></p>
<p><a href="http://www.infoq.com/cn/news/2009/01/EventuallyConsistent,">http://www.infoq.com/cn/news/2009/01/EventuallyConsistent,</a></p>
]]></content:encoded>
			<wfw:commentRss>http://bookcold.com/2010/03/333/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CAP理论</title>
		<link>http://bookcold.com/2010/03/325</link>
		<comments>http://bookcold.com/2010/03/325#comments</comments>
		<pubDate>Tue, 09 Mar 2010 13:37:40 +0000</pubDate>
		<dc:creator>bookcold</dc:creator>
				<category><![CDATA[系统架构]]></category>
		<category><![CDATA[CAP]]></category>

		<guid isPermaLink="false">http://bookcold.com/2010/03/09/325/</guid>
		<description><![CDATA[<p>Most of the data, Most of the time.</p> 一. 什么是CAP 1. Atomic Data Objects (Consistent) <p>为了保证一致性，所有的操作必需保证有序，且每一个操作看起来在一瞬间完成。这等价于要求分布式的共享内存好像就在一个节点上，一次相应一个操作。对于原子的读写共享内存操作有一个重要的性质，即当完成一个写操作后，读操作必需返回正确的值。这是一致性最简单的模型。</p> 2. Available Data Objects(Availble) <p>关于可用性一个比较弱的定义：对于一个算法完成的时间没有限制，即允许无限制的计算。一个比较强的定义是：即使当严重网络故障发生时，每个请求都必须要能终止（返回给客户端）。</p> 3. Partition Tolerance <p>分区即当不允许消息任意的在节点间传输。当一个网络被分割，从一个分区内的任意节点往另一个分区的节点发送的消息都会丢失。</p> <p>例如：如果有一个数据库允许在80个节点上分布于两个机架，当连接两个机架的的网络故障时，现在这个数据库是被分区的。如果数据库是分区容错的，那么数据库现在在各自的分区仍然可以进行读写操作。如果不是分区容错，那么这个集群就完全不能访问。</p> 定理：任何分布式系统只可同时满足以上二点，没法三者兼顾。 <p> 忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。</p> 二. 概念、定理 <p>两个基本概念：</p> <p>异步网络模型&#160;&#160;&#160; 没有时钟，节点所做的决定只依据收到的消息和本地计算</p> <p>In the asynchronous model,there is no clock,and nodes must make decisions based only on the messages received and local computation.</p> [...]]]></description>
			<content:encoded><![CDATA[<blockquote><p><font size="2">Most of the data, Most of the time.</font></p>
</blockquote>
<h3>一. 什么是CAP</h3>
<h4>1. Atomic Data Objects (Consistent)</h4>
<p><font size="2">为了保证一致性，所有的操作必需保证有序，且每一个操作看起来在一瞬间完成。这等价于要求分布式的共享内存好像就在一个节点上，一次相应一个操作。对于原子的读写共享内存操作有一个重要的性质，即当完成一个写操作后，读操作必需返回正确的值。这是一致性最简单的模型。</font></p>
<h4>2. Available Data Objects(Availble)</h4>
<p><font size="2">关于可用性一个比较弱的定义：对于一个算法完成的时间没有限制，即允许无限制的计算。一个比较强的定义是：即使当严重网络故障发生时，每个请求都必须要能终止（返回给客户端）。</font></p>
<h4>3. Partition Tolerance</h4>
<p><font size="2">分区即当不允许消息任意的在节点间传输。当一个网络被分割，从一个分区内的任意节点往另一个分区的节点发送的消息都会丢失。</font></p>
<p><font size="2">例如：如果有一个数据库允许在80个节点上分布于两个机架，当连接两个机架的的网络故障时，现在这个数据库是被分区的。如果数据库是分区容错的，那么数据库现在在各自的分区仍然可以进行读写操作。如果不是分区容错，那么这个集群就完全不能访问。</font></p>
<h4><strong>定理：任何分布式系统只可同时满足以上二点，没法三者兼顾。</strong></h4>
<p><strong>     <br />忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。</strong></p>
<h3>二. 概念、定理</h3>
<p><strong>两个基本概念：</strong></p>
<p><strong>异步网络模型</strong>&#160;&#160;&#160; 没有时钟，节点所做的决定只依据收到的消息和本地计算</p>
<p>In the asynchronous model,there is no clock,and nodes must make decisions based only on the messages received and local computation.</p>
<p><strong>部分同步网络模型</strong>&#160;&#160;&#160;&#160;&#160; network to have a clock,且每个节点的时钟频率是一样的，但是节点自身是不同步的。因此同一时刻不同节点有可能有不同的值。</p>
<p>&#160;</p>
<p><strong>定理一</strong>：在异步网络模型中，对数据对象的读写操作无法保证以下属性：对所有的正常操作（包括消息丢失）都具有有效性和一致性。</p>
<p><strong>Theorem1</strong>&#160; It is impossible in the asynchronous network model to implement a read/write data object that guarantees the following properties:     <br />• Availability     <br />• Atomicconsistency     <br />in all fair executions(including those in which messages are lost).</p>
<p><strong>推论一</strong>：在异步网络模型中，对数据对象的读写操作无法保证以下属性：对所有正常的执行都保证有效性，且在没有数据丢失的执行中保证一致性</p>
<p><strong>Corollary1.1</strong>&#160; It is impossible in the asynchronous network model to implement a read/write data object that guarantees the following properties:     <br />• Availability, in all fair executions,     <br />• Atomic consistency, infair executions in which no messages are lost.</p>
<p><strong>CAP理论的证明：</strong></p>
<p>1. 在网络中有两个节点，N1和N2。它们共享数据V，值为V0。对A和B分别是是节点N1和N2上安全、可靠的操作。</p>
<p><a href="http://www.julianbrowne.com/article/viewer/brewers-cap-theorem" target="_blank"><img style="border-bottom: 0px; border-left: 0px; display: block; float: none; margin-left: auto; border-top: 0px; margin-right: auto; border-right: 0px" title="image" border="0" alt="image" src="http://bookcold.com/wp-content/uploads/2010/03/image1.png" width="208" height="244" /></a></p>
<p>2. A写一个新的值给V，B读取V的新值。</p>
<p>1）A给V赋了一个新值V1&#160;&#160;&#160; </p>
<p>2）从N1往N2发送一个消息M，更新N2中V的值</p>
<p>3）从B中读取V的值，返回值V1</p>
<p><a href="http://www.julianbrowne.com/article/viewer/brewers-cap-theorem" target="_blank"><img style="display: block; float: none; margin-left: auto; margin-right: auto" src="http://www.julianbrowne.com/attachments/71/images/scenario-1.png" /></a></p>
<p>3.&#160; 假如A和B被分区（分割），N1和N2的值是非一致的，N2返回V0</p>
<p><a href="http://www.julianbrowne.com/article/viewer/brewers-cap-theorem" target="_blank"><img style="display: block; float: none; margin-left: auto; margin-right: auto" src="http://www.julianbrowne.com/attachments/71/images/scenario-2.png" /></a></p>
<p>&#160;</p>
<h3>三. 任意两个组合均成立</h3>
<p><a href="http://www.dbanotes.net/arch/cap.html" target="_blank"><img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="image" border="0" alt="image" src="http://bookcold.com/wp-content/uploads/2010/03/image.png" width="244" height="241" /></a> </p>
<p><strong>1. 原子性和分区容错性</strong></p>
<p>用一个指定节点维护数据的值。当一个节点收到客户发来的请求时，将该请求转发给指定节点，当从指定节点收到确认消息后，节点再发送一个反馈信息给客户端。</p>
<p><strong>2. 原子性和有效性</strong></p>
<p>如果没有分区，上面的算法同样满足这个条件</p>
<p><strong>3. 有效性和分区容错性</strong></p>
<p>如果没有并发请求，服务对任意的请求都可以返回初始值</p>
]]></content:encoded>
			<wfw:commentRss>http://bookcold.com/2010/03/325/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
<!-- WP Super Cache is installed but broken. The path to wp-cache-phase1.php in wp-content/advanced-cache.php must be fixed! -->