<?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>kafka0102的边城客栈 &#187; 对等系统</title>
	<atom:link href="http://www.kafka0102.com/tag/%e5%af%b9%e7%ad%89%e7%b3%bb%e7%bb%9f/feed" rel="self" type="application/rss+xml" />
	<link>http://www.kafka0102.com</link>
	<description>要有最朴素的生活与最遥远的梦想，即使明日天寒地冻、路远马亡。</description>
	<lastBuildDate>Sat, 18 Jun 2011 04:20:42 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>CAP理论及BASE思想等</title>
		<link>http://www.kafka0102.com/2010/04/86.html</link>
		<comments>http://www.kafka0102.com/2010/04/86.html#comments</comments>
		<pubDate>Sun, 18 Apr 2010 09:03:24 +0000</pubDate>
		<dc:creator>kafka0102</dc:creator>
				<category><![CDATA[nosql]]></category>
		<category><![CDATA[BASE]]></category>
		<category><![CDATA[cap]]></category>
		<category><![CDATA[一致性问题]]></category>
		<category><![CDATA[同步异步]]></category>
		<category><![CDATA[对等系统]]></category>
		<category><![CDATA[最终一致性]]></category>

		<guid isPermaLink="false">http://www.kafka0102.com/?p=86</guid>
		<description><![CDATA[CAP理论是由 Brewer远在2000年的PODC会议上提出来的。CAP指的是：Consistency、Availability和 Partition Tolerance，下面简述此三者：

1、Consistency（一致性）：一致性是说数据的原子性，这种原子性在经典的数据库中是通过事务来保证的，当事务完成时，无论其是成功还是回滚，数据都会处于一致的状态。在分布式环境中，一致性是说多点的数据是否一致。

2、 Availability（可用性）：可用性是说服务能一直保证是可用的状态，当用户发出一个请求，服务能在有限时间内返回结果。而这种可用性是不关乎结果的正确与否，所以，如果服务一致返回错误的结果，其实也可以称为其是可用的。

3、Partition Tolerance（分区容忍性）：Partition这个词不是常说的操作系统或数据库中的用语，而是指网络的分区。网络中的两个服务结点出现分区的原因很多，比如网络断了、对方结点因为程序bug或死机等原因不能访问。]]></description>
			<content:encoded><![CDATA[<p>很久没有更新，今天说些和分布式系统中的一些概念、理论相关的东西，切入点是CAP。</p>
<h2>CAP</h2>
<p>CAP理论是由Brewer远在2000年的PODC会议上提出来的。CAP指的是：Consistency、Availability和Partition Tolerance，下面简述此三者：</p>
<p>1、Consistency（一致性）：一致性是说数据的原子性，这种原子性在经典的数据库中是通过事务来保证的，当事务完成时，无论其是成功还是回滚，数据都会处于一致的状态。在分布式环境中，一致性是说多点的数据是否一致。</p>
<p>2、Availability（可用性）：可用性是说服务能一直保证是可用的状态，当用户发出一个请求，服务能在有限时间内返回结果。而这种可用性是不关乎结果的正确与否，所以，如果服务一致返回错误的结果，其实也可以称为其是可用的。</p>
<p>3、Partition Tolerance（分区容忍性）：Partition这个词不是常说的操作系统或数据库中的用语，而是指网络的分区。网络中的两个服务结点出现分区的原因很多，比如网络断了、对方结点因为程序bug或死机等原因不能访问。</p>
<p>对于CAP三者，Brewer给出的结论是三者在分布式环境中不能鼎力，一个分布式系统只能有限的实现两者要求，并且这个结论又被另一高人证明了一番。</p>
<h2>一致性问题</h2>
<p>一致性可分为强一致性和弱一致性，弱一致性又称为最终一致性。</p>
<p>在单机环境中，强一致性可以由数据库的事务保证。但在多机环境中，强一致性就很难做到。尽管可以使用2PC来实现分布式事务，但它的低性能（很多情况下满足不了可用性需求）使得不适合于互联网应用。这种强一致性效果的取得，其实是让提交处理过程同步化。</p>
<p>在多机环境中，通过使提交处理半同步半异步、或者全异步，取得最终一致性效果。例如数据库中的主从复制，在提交时就是主库同步从库异步，这对从库复制进度落后不多的场景很简单有效，但在从库落后主库很多时，如果应用还从从库读数据，就会读出脏数据，可以通过监控从库复制进度来选择读哪个从库以避免这个问题。在NOSQL模式下，以Dynamo为例，可以通过确定NRW的不同取值，可以做到同步、半同步半异步、或者全异步的效果。</p>
<p>最终一致性使得数据的提交效果具有延时性，而在一定的延时性范围内（比如<span style="font-family: Times New Roman;">1</span><span style="font-family: 宋体;">秒以内），应用的可用性就是</span><span style="font-family: Times New Roman;">OK</span><span style="font-family: 宋体;">的，比如提交后在客户端通过</span><span style="font-family: Times New Roman;">JS</span><span style="font-family: 宋体;">等停一段时间刷新页面就是要取得这种效果。</span></p>
<h2>主从OR对等系统</h2>
<p>像数据库这样的主从系统有着广泛的应用，它很适合于提交压力不会使得从库复制明显落后的场景。它的缺点是，当主从提交压力增大、或者存在耗时长的提交命令时，从库复制进度会明显落后于主库。在Cache+DB的应用场景下，Cache的填充时机和策略也会受到主从模式影响。如果在一个Session中提交DB后作废Cache，而由后续的（或并发的）另一个Session来再次设置Cache、并且数据是从从库获取，就很有可能缓存住脏数据，如果Cache时间很长，那问题可能就很严重了。可以变通的策略是，在一个Session中提交DB后不是作废Cache，而是更新Cache，并且数据是从主库获取或者直接从应用环境获取。主从的另一个问题是，它有提交单点，但是，如果主从能满足应用需要，在具有完备的主备切换的保证下，这个单点问题并不见得有多大。</p>
<p>因为Dynamo的时兴，对等系统成为另一种选择。对等系统解决了单点问题，有着高分区容忍性，但它的效果仍得商榷。NRW的不同取值会影响读写数据效果，多点提交带来的冲突解决也是个问题，尽管通常采用高版本替换低版本的粗暴策略。现在的NOSQL对等系统存储的是简单的kv，并且可以采用加机器来扩容，所以性能方面应该是可接受的（尽管常见的单机kv存储性能要比数据库高很多，但在对等系统中，因为其复杂性，换算下来单机的性能并不见得有多高）。</p>
<p>SQL和NOSQL各有其优缺点。如果存储一些实体数据并且查询提交只是根据唯一标识来，使用NOSQL也许就很合适。但像复杂的关系数据，使用SQL就更合适些。而就提交模式来说，如果并发提交的数据隔离性不好（比如需要同时对同一个数值做更新），那么对等系统的提交冲突就会增多，数据的正确性就会受到影响。</p>
<h2>BASE</h2>
<p>上面提到，在分布式环境中，CAP只能取两者。但是，因为网络分区的情况不可避免，并且它对可用性有着重要影响，所以互联网中的分布式系统多在一致性方面做些折中。虽然不能达到强一致性，但可以根据应用特点采用适用的手段来达到够用的一致性效果。比如，对于微博系统，当用户新增一条消息，能够达到用户能看到刚才发的消息、而他的follower们能在尽快时间看到他新发的消息的效果就可以了。而在实现时，就可以结合同步和异步多种策略、SQL+NOSQL多种存储方案来满足应用需要。</p>
<p>BASE（Basically Available、Soft state、Eventually consistent）是对CAP中的AP的延伸。</p>
<p>在单机环境中，ACID是数据的属性；而在分布式环境中，BASE就是数据的属性。ACID有“尖刻”之含义，所以单机环境的数据有着很高的要求。而因为分布式环境的网络分区性及复杂性，对数据也只能有“基本”的要求了。</p>
<p>从ACID到CAP和BASE，从单机到分布式，从SQL到NOSQL，互联网应用的大规模发展促使不断出现可替代旧方案的新技术。在技术选型方面，重要的是根据自己的应用特点选择自己能驾驭的技术。而现实的应用场景，也大多是多种技术方案的结合。</p>
]]></content:encoded>
			<wfw:commentRss>http://www.kafka0102.com/2010/04/86.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

