分散システム、遭遇した分散データベースの課題

　　分散システム、私は、リレーショナル・データベースの場合遅く訪問/ O占める高すぎると、メモリ不足にアクセスする場合、ポリシー・ストリーム人気のサブライブラリーのサブテーブルを考えることができ、非常に多くの新しい技術的課題の到着がします。

1.分散トランザクション

　　ときmysqlは業務上の問題（ACID）に対処する私たちを支援してきましたが、これは、唯一の次のシングル場合のものであるため、トランザクションの一貫性を考慮せずにアプリケーションまたはモノマー、モノマーデータベース、すべてのデータベース、複数のマスター・スレーブの場合バックアップ、個別の読み取りと書き込み、それは矛盾の事務ケースが発生します、そして、何が分散し、分散トランザクションを

　　トランザクションは、どのようにそれを解決するには？

　　1.に関する事項の概念

　　　　ローカル事務：ローカル・トランザクションの利点は、厳格なACID特性、効率的で、信頼性の高い、状態のみエクスプローラで維持され、単純なアプリケーション・プログラミング・モデルことができるによって支持されています。

　　　　グローバル・アフェアーズ：トランザクションはロールバックを提出するグローバルトランザクションマネージャグローバル・トランザクション、関連する業務とリソースのグローバル状態を管理する役割を担うトランザクションマネージャ、一貫性のある協調的リソースによってグローバルに管理されます。

　　　　2フェーズトランザクション：二相取引はで定義されたX / OPEN組織の使用をコミットDTPモデル抽象化を通じて、AP、 TM、 RM強い一貫性を保証事務の概念を。請求TMとRMの間で使用されるXA双方向通信のためのプロトコル。地元の伝統的な情勢と比較すると、

　　　　　　　　　　XAトランザクションが準備フェーズ、受動的に服従命令を受け入れるように加えて、データベースを高め、それはまた、逆のトランザクションがコミットできるかどうか、発信者に知らせることができます。だから、TM我々は強力なトランザクションの一貫性を確保するために、すべてのトランザクションの枝、そして最終的に提出する原子の結果を収集するために準備することができます。

　　　　BASE理論：BAはサポートパーティションが失敗した、基本的なサービスの利用可能性を意味し、Sは、柔軟性の状態を表し、短い時間が同期されていないことができ、Eは、最終的な一貫性を示し、最終的なデータは同じですが、実際の時間が矛盾しています。原子性と耐久性、可用性、パフォーマンス、サービス低下のための基本的な必要性から保証され、唯一の一貫性と分離の必要性を削減しなければなりません。

　　　 CAP定理：共有データシステムでは、CAPのみそれらのうちの2つを持つことができ、実際に業務システムを適応している任意の2つのシーンは、通常、CAPと酸との混合物です。分散システムは、最も重要なことではなく、高度に抽象的、絶対的なシステム特性の追求よりも、ビジネスニーズを満たすことです。Cは、つまり、その一貫性を示し、すべてのユーザーが、データが同じである参照してください。

　　　　　　　　　Aは、手段の利用可能性は、常に利用可能なデータのコピーを見つけることができますを示しています。Pは、ネットワークの停止やその他の障害に耐えることができ、パーティションのフォールトトレランスを表します。

　　2.ソリューション

　　　　1.二相（2PC）ソリューション

　　　　　　　　二相コミットは、ここで準備し、二つのインターフェースを提出するには、2つのリソースがあり、実際には比較的簡単です。

　　　　　　　　トランザクションの実行中に相互に排他的な要件の分離、に起因して、すべてのリソースがロックされている、これは短いトランザクションの実行時間にのみ適しているが決まります。しかし、トランザクションの一貫性を確保するために、主に使用されるシリアル化された分離レベルを分散トランザクションの整合性を確保するために、これは、システムのスループットを低下させます。

　　　　　　　　2PCプロトコルのコストが比較的高いので、しかし、世界的なロックの問題があり、パフォーマンスが比較的悪くなります。今、私たちは基本的に、この強力な均一なソリューションを使用しないでください。

　　　　2.TCCサービス補償スキーム

　　　　　　　　　　　　　　TCCは、try、確認、取り消しの3つの操作が含まれている名前の由来です。

　　　　　　　　　　　　　　TCCは、ビジネスサービス層、別途準備段階に位置している2フェーズ・コミットと比較すると、操作するビジネスリソースロックの粒度を選択する柔軟性をお試しください。TCCは、最終的なシステムパフォーマンスの一貫性を通じて、当社の設計上の選択に大きなインスピレーションをこの設計に問題を解決することです。システムは、ビジネスモデリング手法によって解決することができるいくつかの技術的な問題。

　　　　3.Saga総務

　　　　　　佐賀この概念は、データベース紙前に三十年から来サガ、佐賀のトランザクションは、トランザクション複数の短い長からなるトランザクションがあります。分散トランザクションのシナリオでは、我々は、分散トランザクションサーガトランザクションは複数からなるローカルトランザクションで見た、各ローカルトランザクションは、対応する取引補償を有します。

　　　　　　在Saga事务的执行过程中，如果某一步执行出现异常，Saga事务会被终止，同时会调用对应的补偿事务完成相关的恢复操作，这样保证Saga相关的本地事务要么都是执行成功，要么通过补偿恢复成为事务执行之前的状态。

　　　　　　Saga定义了一个事务中的每个子事务都有一个与之对应的反向补偿操作。由Saga事务管理器根据程序执行结果生成一张有向无环图，并在需要执行回滚操作时，根据该图依次按照相反的顺序调用反向补偿操作。Saga事务管理器只用于控制何时重试，何时补偿，

　　　　　　并不负责补偿的内容，补偿的具体操作需要由开发者自行提供。

　　　　　　SAGA可以看做一个异步的、利用队列实现的补偿事务。

　　　　　　其适用于无需马上返回业务发起方最终状态的场景，例如：你的请求已提交，请稍后查询或留意通知之类。

　　　　　　将上述补偿事务的场景用SAGA改写，其流程如下：

- - 　　　　订单服务创建最终状态未知的订单记录，并提交事务
  - 　　　　现金服务扣除所需的金额，并提交事务
  - 　　　　订单服务更新订单状态为成功，并提交事务

　　　　以上为成功的流程，若现金服务扣除金额失败，那么，最后一步订单服务将会更新订单状态为失败。

　　　　其业务编码工作量比补偿事务多一点，包括以下内容：

- - 　　　　订单服务创建初始订单的逻辑
  - 　　　　订单服务确认订单成功的逻辑
  - 　　　　订单服务确认订单失败的逻辑
  - 　　　　现金服务扣除现金的逻辑
  - 　　　　现金服务补偿返回现金的逻辑

　　　　但其相对于补偿事务形态有性能上的优势，所有的本地子事务执行过程中，都无需等待其调用的子事务执行，减少了加锁的时间，这在事务流程较多较长的业务中性能优势更为明显。同时，其利用队列进行进行通讯，具有削峰填谷的作用。

　　　　因此该形式适用于不需要同步返回发起方执行最终结果、可以进行补偿、对性能要求较高、不介意额外编码的业务场景。

　　　　但当然SAGA也可以进行稍微改造，变成与TCC类似、可以进行资源预留的形态。

　　　　4.基于消息事务　　　　

　　　　　　基于消息实现的事务适用于分布式事务的提交或回滚只取决于事务发起方的业务需求，其他数据源的数据变更跟随发起方进行的业务场景。

　　　　　　举个例子，假设存在业务规则：某笔订单成功后，为用户加一定的积分。

　　　　　　在这条规则里，管理订单数据源的服务为事务发起方，管理积分数据源的服务为事务跟随者。

　　　　　　从这个过程可以看到，基于消息队列实现的事务存在以下操作：

- - 　　　　订单服务创建订单，提交本地事务
  - 　　订单服务发布一条消息
  - 　　　　积分服务收到消息后加积分

　　　　我们可以看到它的整体流程是比较简单的，同时业务开发工作量也不大：

- - 　　　　编写订单服务里订单创建的逻辑
  - 　　　　编写积分服务里增加积分的逻辑

　　　　　　可以看到该事务形态过程简单，性能消耗小，发起方与跟随方之间的流量峰谷可以使用队列填平，同时业务开发工作量也基本与单机事务没有差别，都不需要编写反向的业务逻辑过程。因此基于消息队列实现的事务是我们除了单机事务外最优先考虑使用的形态。