前：https://blog.csdn.net/LawssssCat/article/details/105108098
次へ：https://lawsssscat.blog.csdn.net/article/details/105141410
パブリッシュおよびサブスクライブ
Redisのは、（パブ/サブ）パブリッシュおよびサブスクライブ・メッセージング通信モードである：送信者（パブ）は、加入者（SUB）がメッセージを受信し、メッセージを送信します。
Redisのクライアントは、任意の数のチャンネルを購読することができます。
以下に示しCLIENT2関係、CLIENT1、client5顧客三つのチャネル（チャネル1）、および加入者チャンネルが終了
新しいメッセージがチャネルチャネル1に送信された場合、このメッセージは、PUBLISHコマンドを介して加入者に送信されます3台のクライアント
＃設定サブスクリプションおよび出版
共通コマンド
订阅频道：
SUBSCRIBE channel channel ...
订阅给定的一个或者多个频道的信息
PSUBSCRIBE pattern1 pattern2 ...
订阅一个或者多个符合给定模式的频道。
发布频道：
PUBLISH channel message
将信息发送到指定的频道
退订频道：
UNSUCSCRIBE channel1 channel2 ...
退订指定的频道
PUNSUBSCRIBE pattern pattern
退订所有给定模式的频道
シナリオ
- リアルタイムメッセージングシステムなど、：普通のインスタントメッセージング、グループチャット機能
- ブログサイトでは、100人のファンは、速やかにファンにプッシュ、新しい記事を送信する、あなたに加入があります
- マイクロチャンネル公衆数
- CMSは、リリースニュースのキャッシュクリアする
ポータルキャッシュシステムを、キャッシュをクリアするキャッシュモジュール推奨を更新し、チャネルを介してニュースを受信しました - 中央構成
設定情報の変更、ノードの構成情報が通知メッセージを受信するために購読することができ
マルチデータベース
Redisの下で、データベースは整数インデックスで表される場合、データベース名によって識別されません。
デフォルトでは、クライアントのデータベースは0に接続されています。
Redisの設定ファイルデータベースの合計数を制御するために、以下のパラメータ：
# redis.conf 文件 为配置文件
database 16
選択したデータベースを切り替えます
# 数据库下标 从0开始，1,2，3,4 ...15
select 数据库下标
現在のライブラリを移動するためのもう一つの重要
move key名称 数据库
空のデータベース
flushdb
清除当前数据库的所有 key
flushall
清除整个redis的数据库所有key
＃なぜ複数のデータベース？
複数のデータベースが独立している、私たちは、さまざまなビジネスのためのデータベース・サービスを提供することができます
（同時に、異なるデータベースも開発として使用することができ、デバッグ、オン・ライン）
Redisの総務
Redisのトランザクションを複数回実行することができる、リン、（順次シリアライズ実行コマンドは、他の、許可されたストッパに挿入されていません）
シンプルな
二つの重要な保証とRedisの情勢：
- すべてのコマンドは、トランザクションのシリアル化すること、その後、順番に実行されますRedisの
- Redisの実行は、ガッサーの動作を表示されるように許可されていない、他のコマンドに挿入されることはありません
送信時のバッチ操作は、
EXEC 命令キューバッファの前に置かれています。
受信EXEC 命令トランザクションの実行を入力した後、任意のコマンドの総務が失敗し、コマンドの残りの部分はまだ実行されています
トランザクションの間に、他のクライアントから提出されたコマンド要求は、トランザクションの実行コマンド・シーケンスに挿入されることはありません。
DISCARD
取消事务，放弃执行事务块内的所有命令
EXEC
执行所有事务块的命令
MULTI
标记一个事务块的开始
UNWATCH
取消WATCH命令对所有KEY的监视
WATCH key1 key2 ...
监视一个（或者多个）KEY
如果在事务执行之前，这个（或这些）KEY被其他命令改动，那么事务将被打断。
三つのフェーズ＃総務（Redisの）
- トランザクションを開始
- コラムへのコマンド
- 執行部
例＃1 MULTI EXEC
伝達関数、B 50元に転送
トランザクションのチームに複数のコマンドのうちトランザクションMULTI、最終トリガーEXECコマンドを使用してトランザクションを開始するための最初の
例＃2 DISCARDは、キューを実行しているあきらめます
エラー＃事務の3例として「論理」処理
エラー情勢「論理的」プロセス：
コマンドがエラーのうちに報告されている場合は、他のコマンドが実行される一方で、コマンドの唯一のエラーは、実行されませんが、背中を丸めていません
間違い＃4例情勢「順序」のプロセス
いわゆるコマンドエラー、コマンドはエラーに入力されたとき、
すべてのキューが解除され実行されます
実施例5の時計＃情勢
要件：トランザクションがコミットされる前に、1つのアカウントがトランザクション内で動作するために、別のプロセスがアカウントを操作します
ノートに二つのこと：
- これは、トランザクション内で開くことができない、オープンな（マルチ）トランザクションの前にオンにする必要があります
- 1つのトランザクション以下の場合にのみ有効
＃シナリオ
一連のコマンドは、実行するために実行したりしてはなりません
私たちは、コマンドのセットは、実装の過程で追加コマンドを挿入されていないことを確実にしたいです
例えば：
- スパイク
Redisのデータ消去戦略
メモリが不足している時に、公式の警告へのRedisは、Redisのは成功した書き込みを確保するために、ポリシー設定をキャッシュいくつかのキーのうち基づいて行われます。
無段階的政策、またはキー検索の無い、適切なうちは、Redisのは、メモリエラーから直接戻らないとき。
＃最大キャッシュ構成
Redisのでは、ユーザが使用する最大メモリサイズを設定することを可能にします。
maxmemory 512G
Redisのは、政策のうち、6つのデータを提供しています：
以下のためではなく、未使用のメモリブロック（メモリブロック）LRU（最も最近使用、最低使用頻度アルゴリズム）と呼ばれる
メモリ管理のページによって置換アルゴリズム、オペレーティングシステムがメモリ不足とLRUに属するデータを判定する追加のデータをロードするために構築された空いたシステム
-
揮発性-LRU：データのタイムアウト設定は、最も使用頻度の低いデータを削除します
-
allkeys-LRU：最も広く使用されている戦略はある最低使用データの削除、中のクエリのすべてのキー
-
揮発性ランダム：タイムアウトがランダムに削除データを設定されています
-
allkeysランダム：クエリは、すべてのキーは、ランダムに削除します
-
揮発性-TTL：ソート、与えられたクエリタイムアウトのためにすべてのデータを設定した後、すぐに期限切れのデータ削除されます。
-
noeviction：あなたがプロパティに設定されている場合、それは削除操作はしません、メモリオーバーフローエラーが返された場合。（デフォルト）
-
揮発性LFU：すべての設定キーの有効期限からキー使用の少なくともフラットレートの追放
LFU（最もよく使われるが、LRU）はまた、共通のキャッシングアルゴリズムであります -
allkeys-LFU：キーの最小周波数を持つすべてのキーから追放
LFUは4.0の後に新たな戦略であります
Redisの持続性
＃RDB
（写真は話すマスタースレーブレプリケーションの背中に関連し、我々は今、左に見ることができます）
RDB（Redisのデータベースが）Redisのデフォルトの永続性メカニズムです。
RDBは、スナップショット、保存の状態に対応します。（数KBスナップショットGデータの数十=」）
スナップショットは、デフォルトの永続モードである
。この方法は、バイナリファイル、デフォルトのファイル名に書き込まれたスナップショット・メモリのデータの方法ですdump.rdb
利点
- 高速データのスナップショットは、高速なデータを復元、保存しました
- 災害復旧のための適切な
短所
- 小型メモリ・マシンは、使用には適していません
- 対照的に、効率が高くありません
要件を満たすためにRDBのメカニズムは、スナップショットを取ることになります
＃AOF
一定の時間間隔でスナップショットは、スナップショットを実行するために開かれたのでRedisのがダウンしている場合ので、それが最後のスナップショットの後のすべての変更を失うことになります。
アプリケーションは、すべての変更を失うことはありません必要な場合は、永続的な方法AOF採用することができます
追加のみのファイル：
- 永続的な方法AOF使用する場合は、Redisのは、書き込み機能が受信した各ライトコマンド（デフォルトはappendonly.aofある）ファイルに追加されます。
- Redisのは、再起動すると、保存したファイルの書き込みコマンドを再実行することにより、メモリ内にデータベース全体を再構築するために来ます。
3つの方法があります（デフォルトは次のとおりです。fsymc 1秒に1回）
- appendonly EYSは
永続AOF開始します - appendfsyncいつも
すぐに、ディスクに書き込まれた最も遅いが、完全な持続性を確保するために受け取りました - appendfsynv everysec（デフォルト）
秒、パフォーマンスと持続性が良好な妥協を行っているに一度ディスクに書き込まは - appendfsyncなし
OSに完全に依存し、最高の性能が持続的な保証されません
問題点
AOF方法はまた、別の問題をもたらします。永続ファイルはどんどん大きくなります。
例えば、我々はINCR testコマンドを100回呼び出し、ファイルには、すべての100個のコマンドを保存する必要があり、実際には、99冗長があります。
キャッシュとデータベースの整合性をRedisの
ソリューション
＃リアルタイム同期
強い整合性の要件が比較的高く、これは、リアルタイムの同期方式で使用されるべきです。
- クエリ - キャッシュは、DBから別のクエリを見つけることができませんが、キャッシュに保存します
- 更新/削除 - 期限切れのキャッシュをデータベースを更新し、その後、設定（キャッシュの内容を更新することはお勧めしません）
注意：
@Cacheable：長い文字列型に変換されるように、注意ニーズをクエリを使用して、または例外をスローすると
@CachePutを：使用更新、このアノテーションを使用し、DBからデータを照会します
#CacheEvict：使用を削除するときに
キャッシュを：組み合わせの使用を
問題と解決策についての同期
キャッシュの浸透
キャッシュの浸透は存在しない特定のクエリデータを参照します
データが照会されるので、何もキャッシュは、データベースが見つけることができなくなりますが、データベースがない場合、これは浸透キャッシュで、その結果、データベースにこのデータを検索する各クエリにつながります
解決策：以下のヌルの結果より持続性のクエリキャッシュ。
注：DBを見つけることができない値もあり、挿入、または場合でも、とき問合せキーをクリアする必要があります
（もちろん、空のキャッシュの有効期限を設けては）
キャッシュ雪崩
キャッシュは時間をかけて集中している場合は、期限が切れていたキャッシュの浸透の多くが発生し、すべてのクエリは、キャッシュ雪崩で、その結果、データベース上に落ちます。
完璧な解決策はありません
- ユーザーの行動の分析、そう均等故障時間の可能な点として配布
- 同時要求の多数を回避するように、書き込まれたキャッシュキューまたはシングルスレッドを確保する手段（工程）をロックすると、基礎となるストレージシステムの障害に陥ります
ホットキー
キーの訪問は非常に多くの場合、キーの失敗は、スレッドの多くは負荷が増加し、システムのRAN崩壊を引き起こし、キャッシュを構築することがある場合。
ソリューション
- ロック：一緒に配布、などをロックし、同期シングル
分布式锁（後で言います） - 処理時間をキャッシュする設定が、対応するキー内の値ではありません。
検出されたイベントには有効期限が切れ、非同期更新よりも多くのキャッシュを主催している場合。 - セット値の小さい満了時間T1 T0満了時間値t1よりアップデートキャッシュの動作T1を拡張し、作る、有効期限が切れたとき。
- [設定]タブキャッシュは、キャッシュは、タグ、非同期更新実際のキャッシュ有効期限が切れた後、
＃非同期キュー
同時実行性の高いため
- これは、非同期キューの同期に使用することができます
- カフカは、メッセージングミドルウェアとして生産と消費のプロセスメッセージに使用することができます。
＃アリ同期同棲運河
運河の実装では、同期機構シミュレーションMySQLのスレーブとマスタ、監視DB bitlogログキャッシュ更新トリガの更新であります
このアプローチは、両手♂♂♂プログラマーのを解放しますか？ワークロード♂削減
億で使用されるときには、いくつかの制限を！
- （これらのレコードは、バイナリログイベントのバイナリログイベントと呼ばれている）でのマスター・レコードバイナリログ（バイナリログ）への変更は、ショーbinlogのイベントで見ることができます
- そのリレーログにバイナリログイベントのマスタスレーブコピー（リレーログ）
- スレーブリレーのREDOログ・イベントは、独自のデータを反映するために変更されます。
運河の作品
- 運河インタラクティブシミュレーションMySQLのスレーブプロトコルは、MySQLのマスター契約にダンプを送信するために、MySQLのスレーブに変装します
- MySQLのマスタdunpはスレーブにバイナリログを押す開始要求を受信した（すなわち、管）
- （元のバイトストリームのための）分析管バイナリログオブジェクト
＃UDFは道カスタム関数を使用しています
ユーザー定義関数であるUDF（ユーザー定義関数）ハイブ
フェイスAPIは、トリガーを使用してプログラムすることがMySQLの同期をキャッシュしますが、高コストの学習を主にUDF C / C ++言語、。
データベース：トリガ
insert into user()
Create trigger {
触发的代码
}
＃Luaのスクリプトパーサ
組み込みLuaの環境でサポートされている2.6バージョンは、Redisの。
スクリプトには通常のコマンドを実行します。EVALを
