redis は分散データベース CAP の原理を導入しています
推奨 (無料):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 サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











Redisクラスターモードは、シャードを介してRedisインスタンスを複数のサーバーに展開し、スケーラビリティと可用性を向上させます。構造の手順は次のとおりです。異なるポートで奇妙なRedisインスタンスを作成します。 3つのセンチネルインスタンスを作成し、Redisインスタンスを監視し、フェールオーバーを監視します。 Sentinel構成ファイルを構成し、Redisインスタンス情報とフェールオーバー設定の監視を追加します。 Redisインスタンス構成ファイルを構成し、クラスターモードを有効にし、クラスター情報ファイルパスを指定します。各Redisインスタンスの情報を含むnodes.confファイルを作成します。クラスターを起動し、CREATEコマンドを実行してクラスターを作成し、レプリカの数を指定します。クラスターにログインしてクラスター情報コマンドを実行して、クラスターステータスを確認します。作る

Redisデータをクリアする方法:Flushallコマンドを使用して、すべての重要な値をクリアします。 FlushDBコマンドを使用して、現在選択されているデータベースのキー値をクリアします。 [選択]を使用してデータベースを切り替え、FlushDBを使用して複数のデータベースをクリアします。 DELコマンドを使用して、特定のキーを削除します。 Redis-CLIツールを使用してデータをクリアします。

Redisのキューを読むには、キュー名を取得し、LPOPコマンドを使用して要素を読み、空のキューを処理する必要があります。特定の手順は次のとおりです。キュー名を取得します:「キュー:キュー」などの「キュー:」のプレフィックスで名前を付けます。 LPOPコマンドを使用します。キューのヘッドから要素を排出し、LPOP Queue:My-Queueなどの値を返します。空のキューの処理:キューが空の場合、LPOPはnilを返し、要素を読む前にキューが存在するかどうかを確認できます。

Centosシステムでは、Redis構成ファイルを変更するか、Redisコマンドを使用して悪意のあるスクリプトがあまりにも多くのリソースを消費しないようにすることにより、LUAスクリプトの実行時間を制限できます。方法1:Redis構成ファイルを変更し、Redis構成ファイルを見つけます:Redis構成ファイルは通常/etc/redis/redis.confにあります。構成ファイルの編集:テキストエディター(VIやNANOなど)を使用して構成ファイルを開きます:sudovi/etc/redis/redis.conf luaスクリプト実行時間制限を設定します。

Redisコマンドラインツール(Redis-Cli)を使用して、次の手順を使用してRedisを管理および操作します。サーバーに接続し、アドレスとポートを指定します。コマンド名とパラメーターを使用して、コマンドをサーバーに送信します。ヘルプコマンドを使用して、特定のコマンドのヘルプ情報を表示します。 QUITコマンドを使用して、コマンドラインツールを終了します。

Redisカウンターは、Redisキー価値ペアストレージを使用して、カウンターキーの作成、カウントの増加、カウントの減少、カウントのリセット、およびカウントの取得など、カウント操作を実装するメカニズムです。 Redisカウンターの利点には、高速速度、高い並行性、耐久性、シンプルさと使いやすさが含まれます。ユーザーアクセスカウント、リアルタイムメトリック追跡、ゲームのスコアとランキング、注文処理などのシナリオで使用できます。

Debian Systemsでは、Directoryコンテンツを読み取るためにReadDirシステム呼び出しが使用されます。パフォーマンスが良くない場合は、次の最適化戦略を試してください。ディレクトリファイルの数を簡素化します。大きなディレクトリをできる限り複数の小さなディレクトリに分割し、Readdirコールごとに処理されたアイテムの数を減らします。ディレクトリコンテンツのキャッシュを有効にする:キャッシュメカニズムを構築し、定期的にキャッシュを更新するか、ディレクトリコンテンツが変更されたときに、頻繁な呼び出しをreaddirに削減します。メモリキャッシュ(memcachedやredisなど)またはローカルキャッシュ(ファイルやデータベースなど)を考慮することができます。効率的なデータ構造を採用する:ディレクトリトラバーサルを自分で実装する場合、より効率的なデータ構造(線形検索の代わりにハッシュテーブルなど)を選択してディレクトリ情報を保存およびアクセスする

Redisデータの有効期間戦略には2つのタイプがあります。周期削除:期限切れのキーを削除する定期的なスキャン。これは、期限切れの時間帯-remove-countおよび期限切れの時間帯-remove-delayパラメーターを介して設定できます。怠zyな削除:キーが読み取られたり書かれたりした場合にのみ、削除の有効期限が切れたキーを確認してください。それらは、レイジーフリーレイジーエビクション、レイジーフリーレイジーエクスピア、レイジーフリーラジーユーザーのパラメーターを介して設定できます。
