redis は分散データベース CAP の原理を説明します
- coldplay.xixi転載
- 2021-02-09 17:49:342802ブラウズ
推奨 (無料): redis
従来の ACID とは
A (原子性) 原子性
C (一貫性) 一貫性
I (分離) 独立性
D (耐久性) 耐久性
リレーショナルデータベースは次のとおりですACID ルール。英語のトランザクションは、現実世界のトランザクションと非常によく似ています。次の 4 つの特徴があります。
1. A (原子性) Atomicity
原子性これは理解しやすいです。つまり、トランザクション内のすべての操作が完了するか、何も行われません。トランザクションの成功の条件は、トランザクション内のすべての操作が成功することです。If 1 つの操作がある限り、失敗すると、トランザクション全体が失敗し、ロールバックする必要があります。たとえば、口座Aから口座Bに100元を送金する銀行振込は、1）口座Aから100元を引き出す、2）口座Bに100元を入金するという2つのステップに分かれます。これら 2 つのステップは同時に完了するか、同時に完了しないかのどちらかで、最初のステップのみが完了し、2 番目のステップが失敗した場合、理由もなく金額が 100 元減額されます。
2. C (一貫性) Consistency
一貫性も理解しやすいため、データベースは常に一貫した状態でなければなりません。 , トランザクションを実行しても、データベースの元の一貫性制約は変更されません。
3. I (分離) 独立性いわゆる独立性とは、同時トランザクションが互いに影響を与えないことを意味します
,データがトランザクションによってアクセスされるデータは、別のトランザクションによって変更されます。他のトランザクションがコミットされていない限り、そのトランザクションがアクセスするデータは、コミットされていないトランザクションの影響を受けません。たとえば、口座 A から口座 B に 100 元を送金する取引があります。取引がまだ完了していない場合、この時点で B が自分の口座を確認しても、新しく追加された 100 元は表示されません。4. D (耐久性) 耐久性
永続性とは、トランザクションがコミットされると、その変更がデータベースに永続的に保存されることを意味します
。ダウンタイムがあっても失われます。CAP
C:一貫性
A:可用性 P:パーティション許容値)または分散許容値
CAP理論的には、分散ストレージ システムでは、最大でも上記の 2 つの点しか達成できないことを意味します。
強い一貫性: たとえば、データに含まれるものはそのままです。 分散システム内のすべてのデータ バックアップは同時に同じ値を持ちます
。 (データの同じ最新コピーにアクセスするすべてのノードと同等)
可用性: たとえば、淘宝ダブルイレブンを使用しないことは不可能です。 クラスター内の一部のノードに障害が発生した後でも、クラスター全体は引き続きクライアントの読み取りおよび書き込みリクエストに応答できますか?。 (データ更新の高可用性)
パーティションのフォールト トレランス: 実際には、パーティション化は通信の時間制限要件と同等です。 システムが制限時間内にデータの一貫性を達成できない場合は、パーティションが発生したことを意味し、現在の操作では C と A のどちらかを選択する必要があります。
例: Taobao バッグ 強い一貫性を確保するために、このバッグの「いいね！」の数は 141 である必要がありますが、これは間違ってはいけません。正確なガイダンスが必要ですが、同時実行性が高い場合にデータの均一性を確保するのは困難です。 高可用性の場合:「いいね！」や表示数のエラーが許容されるなど、一貫性が弱い場合がありますが、Web サイトの麻痺を引き起こすことはありません。 。
そのため、ほとんどの Web サイト アーキテクチャでは AP が使用されます。弱い整合性と高可用性
Nosql の場合、
パーティション トレランスを達成する必要があります
現在のネットワーク ハードウェアでは遅延パケット損失などの問題が確実に発生するため、 パーティション トレランスを達成する必要があります。したがって、一貫性と可用性の間でトレードオフを行うことしかできず、これら 3 つの点を同時に保証できる NoSQL システムはありません。
CA 従来の Oracle データベース ほとんどの Web サイト アーキテクチャの AP の選択 CP Redis、Mongodb
一貫性と可用性のバランスをとってください。ほとんどの Web アプリケーションは実際には強い一貫性を必要としません。したがって、P のために C を犠牲にすることが、分散データベース製品の現在の方向性です。
一貫性と可用性の選択
Web2.0 Web サイトの場合、リレーショナル データベースの主な機能の多くは役に立たないことがよくあります
データベース トランザクションの一貫性要件
多くの Web リアルタイム システムでは、厳密なデータベース トランザクションは必要なく、読み取りの一貫性に対する要件は非常に低く、場合によっては、書き込みの一貫性に対する要件はそれほど高くありません。最終的な整合性を実現します。
データベースのリアルタイム書き込みおよび読み取りの要件
リレーショナル データベースの場合、データの一部を挿入してすぐにクエリを実行すると、確実にデータを読み取ることができますが、多くの Web データベースでは、たとえば、それほど高いリアルタイム性は必要ありません。たとえば、Weibo にメッセージを投稿した後、数秒後、場合によっては 10 秒以上後に購読者がこのニュースを目にすることはまったく問題ありません。
複雑な SQL クエリ、特に複数テーブル関連のクエリの要件
大量のデータを含む Web システムでは、複数の大きなテーブルに対する関連クエリや複雑なデータ分析は非常にタブーです。レポート クエリの種類、特に SNS タイプの Web サイトは、需要と製品設計の観点からこの状況を回避します。多くの場合、単一テーブルの主キー クエリと単一テーブルの単純な条件付きページング クエリのみが存在し、SQL の機能は大幅に低下します。
古典的な CAP 図
CAP 理論の核心は、分散システムは一貫性、可用性、およびパーティションのフォールト トレランスを同時に満たすことはできないということです。 3 つのニーズのうち、同時に満足できるのは最大 2 つまでです。
したがって、CAP 原則に従って、NoSQL データベースは 3 つのカテゴリに分類されます: CA 原則を満たす、CP 原則を満たす、AP 原則を満たす:
CA - シングルポイント クラスター、一貫性と可用性を満たすシステムは、一般にスケーラビリティが低くなります。
CP - 一貫性を満たし、パーティショニングを許容する必要があるシステム。通常、パフォーマンスはそれほど高くありません。
AP - 可用性、パーティション許容度を満たし、一般に整合性要件が低いシステム。 
BASE
BASE は、リレーショナル データベースの強整合性と可用性の低下によって引き起こされる問題を解決するために提案されたソリューションです。
BASE は、実際には次の 3 つの用語の略語です。
基本的に利用可能
ソフトな状態
最終的に整合性のある
It この目的は、全体的なスケーラビリティとパフォーマンスを向上させることです。システムは、特定の時点でデータの一貫性に対する要件を緩和できるようにすることで、システムを保護します。なぜこのようなことが言えるのでしょうか? その理由は、地理的な分散と非常に高いパフォーマンス要件のため、大規模システムでは分散トランザクションを使用してこれらのインジケーターを完了できないことが多いためです。これらのインジケーターを取得するには、別の方法を使用して完了する必要があります。これが BASE です。この問題の解決策
分散クラスタの概要
分散システム
は、コンピュータ ネットワーク接続 (ローカル ネットワークまたは広域ネットワーク) を介した複数のコンピュータと通信ソフトウェア コンポーネントで構成されます。エリアネットワーク）。分散システムは、ネットワーク上に構築されたソフトウェア システムです。ソフトウェアの特性だからこそ、分散システムは高度な凝集性と透明性を持っています。したがって、ネットワークと分散システムの違いは、ハードウェアよりも高レベルのソフトウェア (特にオペレーティング システム) にあります。分散システムは、PC、ワークステーション、LAN、WAN などのさまざまなプラットフォームに適用できます。
簡単に言うと:
分散: 異なるサービス モジュール (プロジェクト) が複数のサーバーにデプロイされ、RPC/RMI を介して通信および呼び出しを行い、外部サービスとグループ内サービスを提供します。
クラスター: 同じサービス モジュールが複数の異なるサーバーに展開され、分散スケジューリング ソフトウェアを通じて統合スケジューリングが実行され、外部サービスとアクセスが提供されます。
以上がredis は分散データベース CAP の原理を説明しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。