この記事では、Redis に関する関連知識を提供します。主に Redis の利点と特徴をいくつか紹介します。Redis は、ANSI C 言語で書かれたオープン ソースであり、BSD プロトコルに準拠しています。ネットワークをサポートしており、ネットワークをサポートしています。メモリベースの分散ストレージデータベースですので、見てみましょう。皆さんのお役に立てれば幸いです。
推奨される学習: Redis ビデオ チュートリアル
Remote DIctionary Server (Redis) は、 Salvatore Sanfilippo によって作成されたキーと値のストレージ システムは、クロスプラットフォームの非リレーショナル データベースです。
Redis は、ANSI C 言語で書かれたオープン ソースのキー/値 (Key-Value) ストレージ データベースであり、BSD プロトコルに準拠し、ネットワーク、メモリベース、分散、およびオプションの永続性をサポートし、複数の言語を提供します。 API。
Redis は、値が文字列、ハッシュ、リスト、セット、ソートされたセットなどの型になる可能性があるため、データ構造サーバーと呼ばれることがよくあります。
1. Redis は完全にメモリに基づいており、ほとんどのリクエストは純粋なメモリ操作であり、非常に高速です。データは HashMap と同様にメモリに保存されます。HashMap の利点は、検索と操作の時間計算量が O(1);
2 であることです。データ構造が単純で、データ操作も簡単です。シンプルです。Redis のデータ構造は特別に設計されています;
3. 不必要なコンテキストの切り替えや競合状態を回避するために単一のスレッドを使用します。 CPU に依存し、さまざまなロックを考慮する必要がありません。ロックのロックと解放の問題がなく、デッドロックによるパフォーマンスの消費がありません。
4. マルチチャネル I/O 多重化モデルを使用します。 、ノンブロッキング IO;
5. 使用される基礎となるモデルが異なり、基礎となる実装メソッドとクライアントとの通信用のアプリケーション プロトコルが異なります。Redis は、VM メカニズムを自身で直接構築します。システムがシステム関数を呼び出すと、一定の時間が無駄になります。移動とリクエスト;
6.複数の I/O 再利用モデル
マルチチャネル I/O 多重化モデルは、select、poll、および epoll を使用して、複数のストリームの I/O イベントを同時に監視します。アイドル状態のとき、現在のスレッドはブロックされます。1 つ以上のとき、ストリームには I/O イベントがあり、ブロッキング状態からウェイクアップするため、プログラムはすべてのストリームをポーリングし (epoll は実際にイベントを発行したストリームのみをポーリングします)、準備ができたストリームのみを順番に処理します。オペレーション。
**ここで、「マルチチャネル」は複数のネットワーク接続を指し、「再利用」は同じスレッドを再利用することを指します。 **マルチチャネル I/O 多重化テクノロジの使用により、単一のスレッドで複数の接続リクエストを効率的に処理でき (ネットワーク IO の時間消費を最小限に抑えます)、Redis はメモリ内のデータを非常に高速に操作します。つまり、インメモリ操作はRedis のパフォーマンスに影響を与えるボトルネックにならないこと 上記の点が主に Redis の高スループットに貢献します。
まず、上記の分析はすべて、Redis が高速であるという雰囲気を作り出すためであることを理解する必要があります。公式 FAQ には、Redis はメモリベースの操作であるため、CPU が Redis のボトルネックになるのではなく、Redis のボトルネックはマシンのメモリ サイズまたはネットワーク帯域幅である可能性が高いと記載されています。シングルスレッドは実装が簡単で、CPU がボトルネックにならないため、シングルスレッド ソリューションを採用するのが合理的です (結局のところ、マルチスレッドを使用すると多くの問題が発生します!)。
redis 127.0.0.1:6379> SET rediskey redis OK redis 127.0.0.1:6379> GET rediskey "redis"
Redis ハッシュは文字列型のフィールドと値のマッピング テーブルであり、オブジェクトの保存に特に適しています。
Redis の各ハッシュには 232-1 のキーと値のペア (40 億以上) を保存できます
Redis list は、挿入順にソートされた文字列の単純なリストです。リストの先頭 (左) または末尾 (右) に要素を追加できます。
リストには、最大 232 - 1 個の要素を含めることができます (4294967295、リストあたり 40 億以上の要素)。
redis 127.0.0.1:6379> LPUSH rediskey redis (integer) 1 redis 127.0.0.1:6379> LPUSH rediskey mongodb (integer) 2 redis 127.0.0.1:6379> LPUSH rediskey mysql (integer) 3 redis 127.0.0.1:6379> LRANGE rediskey 0 10 1) "mysql" 2) "mongodb" 3) "redis"
Redis の Set は、文字列型の順序付けされていないコレクションです。セットのメンバーは一意であるため、セット内に重複したデータが存在することはできません。
コレクション オブジェクトのエンコーディングは、intset または hashtable にすることができます。
Redis のコレクションはハッシュ テーブルを通じて実装されるため、追加、削除、検索の複雑さは O(1) です。
コレクション内のメンバーの最大数は 232 - 1 (4294967295、各コレクションには 40 億を超えるメンバーを保存できます) です。
redis 127.0.0.1:6379> SADD rediskey redis (integer) 1 redis 127.0.0.1:6379> SADD rediskey mongodb (integer) 1 redis 127.0.0.1:6379> SADD rediskey mysql (integer) 1 redis 127.0.0.1:6379> SADD rediskey mysql (integer) 0 redis 127.0.0.1:6379> SMEMBERS rediskey 1) "mysql" 2) "mongodb" 3) "redis"
Redis 順序付きセットも、セットと同様に文字列型要素のコレクションであり、重複するメンバーは許可されません。
違いは、各要素が double 型のスコアに関連付けられていることです。 Redis はスコアを使用して、コレクションのメンバーを小さいものから大きいものまで並べ替えます。
順序付きセットのメンバーは一意ですが、スコアは繰り返すことができます。
セットはハッシュ テーブルを通じて実装されるため、追加、削除、検索の複雑さは O(1) です。コレクション内のメンバーの最大数は 232 - 1 (4294967295、各コレクションには 40 億を超えるメンバーを保存できます) です。
Redis はバージョン 2.8.9 で HyperLogLog 構造を追加しました。
Redis HyperLogLog はカーディナリティ統計に使用されるアルゴリズムです。HyperLogLog の利点は、入力要素の数または量が非常に大きい場合でも、カーディナリティの計算に必要なスペースが常に固定され、非常に小さいことです。 。
Redis では、ほぼ 2^64 の異なる要素のカーディナリティを計算するために、各 HyperLogLog キーに必要なメモリは 12 KB のみです。これは、カーディナリティの計算時により多くのメモリを消費するコレクションとは対照的で、要素が多いほど、より多くのメモリが消費されます。
ただし、HyperLogLog は入力要素に基づいてカーディナリティを計算するだけで、入力要素自体は保存しないため、HyperLogLog はコレクションのように入力の各要素を返すことができません。
たとえば、データ セットが {1, 3, 5, 7, 5, 7, 8} の場合、このカーディナリティ セットはデータセットは {1, 3 , 5 ,7, 8}、カーディナリティ (非反復要素) は 5 です。カーディナリティの推定とは、許容誤差範囲内でカーディナリティを迅速に計算することです。
次の例は、HyperLogLog の作業プロセスを示しています:
//添加指定元素到 HyperLogLog 中。 redis 127.0.0.1:6379> PFADD rediskey "redis" 1) (integer) 1 redis 127.0.0.1:6379> PFADD rediskey "mongodb" 1) (integer) 1 redis 127.0.0.1:6379> PFADD rediskey "mysql" 1) (integer) 1 //添加指定元素到 HyperLogLog 中。 redis 127.0.0.1:6379> PFCOUNT rediskey (integer) 3
Redis パブリッシュおよびサブスクライブ (パブリッシュ/サブスクライブ)はメッセージ通信モードです。送信者 (pub) がメッセージを送信し、サブスクライバー (sub) がメッセージを受信します。
Redis クライアントは、任意の数のチャネルにサブスクライブできます。
次の図は、チャネル channel1 と、このチャネルにサブスクライブする 3 つのクライアント (client2、client5、client1) との関係を示しています。
次の例は、パブリッシュとサブスクライブの仕組みを示しています。2 つの redis-cli クライアントを開く必要があります。
この例では、runoobChat:
という名前のサブスクリプション チャネルを作成しました。redis 127.0.0.1:6379> SUBSCRIBE runoobChat Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "runoobChat" 3) (integer) 1
现在，我们先重新开启个 redis 客户端，然后在同一个频道 runoobChat 发布两次消息，订阅者就能接收到消息。
redis 127.0.0.1:6379> PUBLISH runoobChat "Redis PUBLISH test" (integer) 1 redis 127.0.0.1:6379> PUBLISH runoobChat "Learn redis by runoob.com" (integer) 1 # 订阅者的客户端会显示如下消息 1) "message" 2) "runoobChat" 3) "Redis PUBLISH test" 1) "message" 2) "runoobChat" 3) "Learn redis by runoob.com"
gif 演示如下：
runoobChat 频道。Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：
一个事务从开始到执行会经历以下三个阶段：
以下是一个事务的例子， 它先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令：
redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days" QUEUED redis 127.0.0.1:6379> GET book-name QUEUED redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series" QUEUED redis 127.0.0.1:6379> SMEMBERS tag QUEUED redis 127.0.0.1:6379> EXEC 1) OK 2) "Mastering C++ in 21 days" 3) (integer) 3 4) 1) "Mastering Series" 2) "C++" 3) "Programming"
单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。
事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。
这是官网上的说明 From redis docs on transactions:
It’s important to note that even when a command fails, all the other commands in the queue are processed – Redis will not stop the processing of commands.
比如：
redis 127.0.0.1:7000> multi OK redis 127.0.0.1:7000> set a aaa QUEUED redis 127.0.0.1:7000> set b bbb QUEUED redis 127.0.0.1:7000> set c ccc QUEUED redis 127.0.0.1:7000> exec 1) OK 2) OK 3) OK
如果在 set b bbb 处失败，set a 已成功不会回滚，set c 还会继续执行。
Redis 脚本使用 Lua 解释器来执行脚本。 Redis 2.6 版本通过内嵌支持 Lua 环境。执行脚本的常用命令为 EVAL。
redis 127.0.0.1:6379> EVAL "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"Redis GEO 主要用于存储地理位置信息，并对存储的信息进行操作，该功能在 Redis 3.2 版本新增。
Redis GEO 操作方法有：
redis> GEOADD Sicily 13.361389 38.115556 "Palermo" 15.087269 37.502669 "Catania" (integer) 2 redis> GEODIST Sicily Palermo Catania "166274.1516" redis> GEORADIUS Sicily 15 37 100 km 1) "Catania" redis> GEORADIUS Sicily 15 37 200 km 1) "Palermo" 2) "Catania" redis>
Redis Stream 是 Redis 5.0 版本新增加的数据结构。
Redis Stream 主要用于消息队列（MQ，Message Queue），Redis 本身是有一个 Redis 发布订阅 (pub/sub) 来实现消息队列的功能，但它有个缺点就是消息无法持久化，如果出现网络断开、Redis 宕机等，消息就会被丢弃。
简单来说发布订阅 (pub/sub) 可以分发消息，但无法记录历史消息。
而 Redis Stream 提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。
Redis Stream 的结构如下所示，它有一个消息链表，将所有加入的消息都串起来，每个消息都有一个唯一的 ID 和对应的内容：
每个 Stream 都有唯一的名称，它就是 Redis 的 key，在我们首次使用 xadd 指令追加消息时自动创建。
上图解析：
Redis は、クライアント/サーバー モデルと要求/応答プロトコルに基づく TCP サービスです。これは、通常、リクエストは次の手順に従うことを意味します。
Redis パイプライン テクノロジを使用すると、サーバーが応答しない場合でもクライアントはサーバーにリクエストを送信し続け、最終的にはすべてのサービスを一度に読み取り、応答を終了します。 。
推奨される学習: Redis ビデオ チュートリアル
以上がRedis の利点と機能について話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
