序文
コンピュータサイエンスの分野では、分散整合性が問題と、3つのサービスシナリオを初めて目を探求し、実証非常に重要かつ広範です。
1、鉄道駅の切符
あなたが私たちのエンドユーザーが頻繁に列車の旅行者であると言うならば、通常は彼がチケットを買うために駅の切符売り場に行くことで、その後、すべての----改札に切符を取り、その後、電車に乗り込み、素晴らしい旅を開始しましたそれはとても調和のとれたようです。
彼はおそらく同時に、唯一のチケットを最後の旅行にバインドされた杭州の送信先、および杭州列車を選択した場合を想像し、他の乗客の切符のウィンドウには、さまざまな購入と同じチケットです。あなたは何の一貫性発券システム保護を言っていない場合は、両方の成功を発券。改札で乗客の一つは、彼のチケットが無効になりますことを言ったとき......
もちろん、現代中国の鉄道チケットシステムはめったにこのような問題を見ていません。しかし、このケースでは、我々は非常に単純なシステムのエンドユーザーの需要ことがわかります。
「チケットが無効であるとき私にチケットを与えてください、私は無議決権を行使された場合、私にチケットを教えてください。」
かかわらず、すべての時間でその切符窓のでなければなりません（この場合は、杭州列車の旅の中指は、投票の残りのために結合していることがある中で）このシステムは、チケット厳格なコンプライアンス要件----システム上のデータを提示します正確な！
2、銀行振込
私たちのエンドユーザーが新卒大学生の場合、通常は最初の月に、彼らは家に送金することを選択します賃金を取得します。彼は銀行のカウンターに到着したとき、転送動作を完了し、銀行の出納係は彼を思い出させるために親切になります：「あなたの転送がNで、将来の仕事のために入金されます！」
この時点で、何らかの不満を持っている卒業生、係員に対抗しますその名前は言いました：「まあ、それはすぐにどのくらいの時間ではなく、少ないお金を重要ではありません！。」......
それはほとんどすべてのユーザーが最も基本的な近代的な銀行システムの必要性となっています
3、オンラインショッピング
あなたは彼が好きな製品の在庫を見たとき、私たちのエンドユーザーは、人々のオンラインショッピングであると言うなら。5に、すばやくそして注文を、購入を確認配信アドレスを書き留め、となります......
しかし、その瞬間次のシングル、システムは、ユーザに通知することができる：「不十分な在庫を！」このとき、消費者の大半は連れ去ら他者による商品は最愛作り、彼らはあまりにも遅いと文句を言うだろう。
しかし、実際には、製品の詳細ページに表示された在庫、通常ではない本当の商品の在庫、および時刻のみを購入する本当の受注は、システムが商品の真をチェックすることを、エンジニアが理解しなければならないシステム開発でのオンラインショッピングの経験がありました在庫。しかし、誰が気に？
解釈の問題
上記の3つの例については、私たちはそれを見なければならないと信じて、データの整合性のための様々なコンピュータ製品の使用中に、当社のエンドユーザーが同じ要求ではありません。
図1は、いくつかのシステムで、すぐにユーザーに対応する必要があるが、また、任意のクライアントへのシステムのデータを確保するために、鉄道駅のチケットシステムのような、本物です
図2に示すように、いくつかのシステムでは、ユーザは、銀行振込システムなど、データの整合性に遅れがあるが、信頼性の高いデータのセキュリティを保証する必要があるが、最終的に厳密な整合性を保証しなければなりません
システムの図3に示すように、いくつかの、いくつかは示すことができるが、ユーザーが「間違った」データであると言ったが、システム全体の過程で、不要なユーザの発生を回避するために、特定のプロセスにシステムデータの精度にチェックを行いますオンラインショッピングシステムなどの損失、
提案の分散一貫性
解決するために、分散システムにおける重要な問題は、データをコピーすることです。
Kシステムは、V1、V2によって更新されたクライアントC1の値を仮定しますが、クライアントは最新の値KにすぐC2を読み取ることができません：開発における私たちの日常の経験では、私は多くの開発者は、このような問題が発生していると信じています、あなたは後でに読む必要があります。
データベースの複製の間に遅延があるので、これは、正常です。
データ複製のための分散システムは、一般的に、2つの理由から来る必要があります。
図1に示すように、システムの可用性を高めるために、使用不能に起因する単一障害点を防止するため
2、異なる場所にあるデータのコピーがユーザーにサービスを提供することが可能である作るために、負荷分散技術により、システム全体のパフォーマンスを向上させます
大きな利益をもたらすために、分散システムの可用性とパフォーマンスのデータ・レプリケーションは自明ですが、データ複製一貫性は、チャレンジをもたらし、すべてのシステムの開発者が直面しなければなりません。
いわゆる一貫性の分布した後、それは、データの異なるノード間で発生する矛盾やデータの状況を解決するために、自分のコンピュータアプリケーションに頼ることができないことがあり、分散環境でのデータ複製機構を導入することを指します。単にデータの整合性が更新されたデータのコピーを参照する場合、他のコピーを更新することが可能であることを確認する、または別の矛盾の間でデータをコピーする必要があり、話します。
那么如何解决这个问题？一种思路是"既然是由于延时动作引起的问题，那我可以将写入的动作阻塞，直到数据复制完成后，才完成写入动作"。
没错，这似乎能解决问题，而且有一些系统的架构也确实直接使用了这个思路。但这个思路在解决一致性问题的同时，又带来了新的问题：写入的性能。
如果你的应用场景有非常多的写请求，那么使用这个思路之后，后续的写请求都将会阻塞在前一个请求的写操作上，导致系统整体性能急剧下降。
总得来说，我们无法找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，一致性级别由此诞生：
1、强一致性
这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大
2、弱一致性
这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不久承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态
3、最终一致性
最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型
欢迎大家关注我的公种浩【程序员追风】，文章都会在里面更新，整理的资料也会放在里面。
分布式环境的各种问题
分布式系统体系结构从其出现之初就伴随着诸多的难题和挑战：
1、通信异常
从集中式向分布式演变的过程中，必然引入网络因素，由于网络本身的不可靠性，因此也引入了额外的问题。
分布式系统需要在各个节点之间进行网络通信，因此每次网络通信都会伴随着网络不可用的风险，网络光纤、路由器或是DNS等硬件设备或是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。
另外，即使分布式系统各个节点之间的网络通信能够正常进行，其延时也会大于单机操作。
通常我们认为现代计算机体系结构中，单机内存访问的延时在纳秒数量级（通常是10ns），而正常的一次网络通信的延迟在0.1~1ms左右（相当于内存访问延时的105倍），如此巨大的延时差别，也会影响到消息的收发过程，因此消息丢失和消息延迟变得非常普遍。
2、网络分区
当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够正常通信，而另一些节点则不能----我们将这个现象称为网络分区。
当网络分区出现时，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能，包括对数据的事物处理，这就对分布式一致性提出了非常大的挑战。
3、三态
上面两点，我们已经了解到在分布式环境下，网络可能会出现各式各样的问题，因此分布式系统的每一次请求与响应，存在特有的三态概念，即成功、失败、超时。
在传统的单机系统中，应用程序在调用一个函数之后，能够得到一个非常明确的响应：成功或失败。而在分布式系统中，由于网络是不可靠的，虽然在绝大部分情况下，网络通信也能够接受到成功或失败的响应，当时当网络出现异常的情况下，就可能会出现超时现象，通常有以下两种情况：
（1）由于网络原因，该请求并没有被成功地发送到接收方，而是在发送过程中就发生了消息丢失现象
（2）该请求成功地被接收方接收后，进行了处理，但是在将响应反馈给发送方的过程中，发生了消息丢失现象
当出现这样的超时现象时，网络通信的发起方是无法确定当前请求是否被成功处理的
4、节点故障
节点故障则是分布式环境下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象，通常根据经验来说，每个节点都有可能出现故障，并且每天都在发生
分布式事务
随着分布式计算的发展，事物在分布式计算领域也得到了广泛的应用。
在单机数据库中，我们很容易能够实现一套满足ACID特性的事物处理系统，但在分布式数据库中，数据分散在各台不同的机器上，如何对这些数据进行分布式的事物处理具有非常大的挑战。
分布式事物是指事物的参与者、支持事物的服务器、资源服务器以及事物管理器分别位于分布式系统的不同节点上，通常一个分布式事物中会涉及对多个数据源或业务系统的操作。
可以设想一个最典型的分布式事物场景：一个跨银行的转账操作涉及调用两个异地的银行服务，其中一个是本地银行提供的取款服务，另一个则是目标银行提供的存款服务，这两个服务本身是无状态并且相互独立的，共同构成了一个完整的分布式事物。
如果从本地银行取款成功，但是因为某种原因存款服务失败了，那么就必须回滚到取款之前的状态，否则用户可能会发现自己的钱不翼而飞了。
从这个例子可以看到，一个分布式事务可以看做是多个分布式的操作序列组成的，例如上面例子的取款服务和存款服务，通常可以把这一系列分布式的操作序列称为子事物。
因此，分布式事务也可以被定义为一种嵌套型的事物，同时也就具有了ACID事物特性。但由于在分布式事务中，各个子事物的执行是分布式的，因此要实现一种能够保证ACID特性的分布式事物处理系统就显得格外复杂。
CAP理论
一个经典的分布式系统理论。CAP理论告诉我们：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。
1、一致性
在分布式环境下，一致性是指数据在多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一直的状态。
对于一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是老数据（或称为脏数据），这就是典型的分布式数据不一致的情况。
在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性
2、可用性
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是"有限时间内"和"返回结果"。
"有限时间内"是指，对于用户的一个操作请求，系统必须能够在指定的时间内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。
另外，"有限的时间内"是指系统设计之初就设计好的运行指标，通常不同系统之间有很大的不同，无论如何，对于用户请求，系统必须存在一个合理的响应时间，否则用户便会对系统感到失望。
"返回结果"是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出队请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。
3、分区容错性
分区容错性约束了一个分布式系统具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络）中，由于一些特殊的原因导致这些子网络出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。
需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。
既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样：
用一张表格说明一下：
需要明确的一点是，对于一个分布式系统而言，分区容错性是一个最基本的要求。因为既然是一个分布式系统，那么分布式系统中的组件必然需要被部署到不同的节点，否则也就无所谓分布式系统了，因此必然出现子网络。
而对于分布式系统而言，网络问题又是一个必定会出现的异常情况，因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。因此系统架构师往往需要把精力花在如何根据业务特点在C（一致性）和A（可用性）之间寻求平衡。
BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。
BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。接下来看一下BASE中的三要素：
1、基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：
（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
2、软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
3、最终一致性
最終的な一貫性は、データのすべてのコピーは、同期後に時間をかけて、最終的には可能な一貫性のある状態を達成することを強調しました。そのため、最終的な一貫性の性質は、リアルタイムシステムは、データの強い一貫性を保証するために必要がなく、最終的なシステムは、データの一貫性を達成することを確保する必要があることです。
全体的に、BASE理論指向の大規模な高可用性のスケーラブルな、分散システム、および物事の伝統的なACID特性が反対している、それはモデルACID強い整合性とは全く異なっているが、犠牲強い一貫して得られました可用性とデータが矛盾しているが、最終的に一貫性のある状態に達する時間を許可します。
しかし、実際の分散シナリオでは、異なるビジネスユニットおよびコンポーネントは、データの整合性のための異なる要件があるので、特定の分散システムアーキテクチャ設計工程において、ACID BASE理論的な特性とは、しばしば一緒。
遂に
サポートのおかげで、ヨーヨーの記事を覚えて賞賛のポイントのように、みんなと共有へようこそ！