Redis の利点と機能について話しましょう-Redis-php.cn

この記事では、Redis に関する関連知識を提供します。主に Redis の利点と特徴をいくつか紹介します。Redis は、ANSI C 言語で書かれたオープンソースであり、BSD プロトコルに準拠しています。ネットワークをサポートしており、ネットワークをサポートしています。メモリベースの分散ストレージデータベースですので、見てみましょう。皆さんのお役に立てれば幸いです。

推奨される学習: Redis ビデオチュートリアル

redis とは

Remote DIctionary Server (Redis) は、 Salvatore Sanfilippo によって作成されたキーと値のストレージシステムは、クロスプラットフォームの非リレーショナルデータベースです。

Redis は、ANSI C 言語で書かれたオープンソースのキー/値 (Key-Value) ストレージデータベースであり、BSD プロトコルに準拠し、ネットワーク、メモリベース、分散、およびオプションの永続性をサポートし、複数の言語を提供します。 API。

Redis は、値が文字列、ハッシュ、リスト、セット、ソートされたセットなどの型になる可能性があるため、データ構造サーバーと呼ばれることがよくあります。

Redisの特徴:

インメモリデータベースは高速でデータの永続化をサポートしており、メモリ上のデータをディスクに保存し、再起動時に再度読み込むことができます。
Redis は、単純なキーと値の型のデータをサポートするだけでなく、リスト、セット、zset、ハッシュなどのデータ構造のストレージも提供します。
Redis はデータバックアップ、つまりマスター/スレーブモードでのデータバックアップをサポートしています。
トランザクションのサポート

Redis の利点:

非常に高いパフォーマンス – Redis は 110,000 回/秒の速度で読み取り、高速で書き込みが可能81,000回/秒。
豊富なデータ型 – Redis は、バイナリの場合の文字列、リスト、ハッシュ、セット、および順序付きセットのデータ型操作をサポートします。
アトミック - Redis のすべての操作はアトミックであり、Redis は複数の操作をマージした後のアトミック実行もサポートしています。 (トランザクション)
豊富な機能 – Redis はパブリッシュ/サブスクライブ、通知、キーの有効期限などの機能もサポートしています。

Redis と他の Key-Value ストアの違いは何ですか?

Redis はより複雑なデータ構造を持ち、それらに対するアトミックな操作を提供します。これは他のデータベースとは異なる進化の過程です。 Redis のデータ型は基本的なデータ構造に基づいており、追加の抽象化を必要とせずにプログラマにとって透過的です。
Redis はメモリ内で実行されますが、ディスクに永続化できるため、データ量がハードウェアメモリを超えることはできないため、さまざまなデータセットの高速読み取りおよび書き込みを実行するときはメモリを考慮する必要があります。インメモリデータベースのもう 1 つの利点は、ディスク上の同じ複雑なデータ構造と比較して、メモリ内での操作が非常にシンプルであるため、Redis は内部の複雑性が高くても多くのことを実行できることです。また、ディスク形式に関しては、ランダムアクセスを必要としないため、コンパクトな追加生成となります。

Memcache と Redis の違いは何ですか

ストレージ方式 Memecache はすべてのデータをメモリに保存します。停電後はハングアップします。データは最大容量を超えることはできません。メモリー容量。 Redis の一部はハードディスクに保存され、redis はそのデータを永続化できます
データサポートタイプ memcached すべての値は単純な文字列です。その代わりとして、redis はより豊富なデータ型をサポートし、リストというストレージを提供しますset、zset、hash などのデータ構造
使用される基礎となるモデルが異なり、クライアントと通信するための基礎となる実装メソッドとアプリケーションプロトコルも異なります。一般的なシステムがシステム関数を呼び出すと、移動やリクエストに一定の時間が無駄になるため、Redis は独自の VM メカニズムを直接構築しました。
value 値のサイズは異なります: Redis は最大 512M に達しますが、memcache はわずか 1MB です。
Redis の速度は memcached よりもはるかに高速です
Redis はデータバックアップ、つまりマスター/スレーブモードでのデータバックアップをサポートしています。

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 はシングルスレッドなのでしょうか?

まず、上記の分析はすべて、Redis が高速であるという雰囲気を作り出すためであることを理解する必要があります。公式 FAQ には、Redis はメモリベースの操作であるため、CPU が Redis のボトルネックになるのではなく、Redis のボトルネックはマシンのメモリサイズまたはネットワーク帯域幅である可能性が高いと記載されています。シングルスレッドは実装が簡単で、CPU がボトルネックにならないため、シングルスレッドソリューションを採用するのが合理的です (結局のところ、マルチスレッドを使用すると多くの問題が発生します!)。

Redis データ型とコマンド

1.String(String)

redis 127.0.0.1:6379> SET rediskey redis
OK
redis 127.0.0.1:6379> GET rediskey
"redis"

ログイン後にコピー

2.Hash(Hash)

Redis ハッシュは文字列型のフィールドと値のマッピングテーブルであり、オブジェクトの保存に特に適しています。

Redis の各ハッシュには 232-1 のキーと値のペア (40 億以上) を保存できます

3. List(List)

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"

ログイン後にコピー

4. Set

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"

ログイン後にコピー

5. ソートされたセット

Redis 順序付きセットも、セットと同様に文字列型要素のコレクションであり、重複するメンバーは許可されません。

違いは、各要素が double 型のスコアに関連付けられていることです。 Redis はスコアを使用して、コレクションのメンバーを小さいものから大きいものまで並べ替えます。

順序付きセットのメンバーは一意ですが、スコアは繰り返すことができます。

セットはハッシュテーブルを通じて実装されるため、追加、削除、検索の複雑さは O(1) です。コレクション内のメンバーの最大数は 232 - 1 (4294967295、各コレクションには 40 億を超えるメンバーを保存できます) です。

6. HyperLogLog

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

ログイン後にコピー

7. パブリッシュおよびサブスクライブ

Redis パブリッシュおよびサブスクライブ (パブリッシュ/サブスクライブ)はメッセージ通信モードです。送信者 (pub) がメッセージを送信し、サブスクライバー (sub) がメッセージを受信します。

Redis クライアントは、任意の数のチャネルにサブスクライブできます。

次の図は、チャネル channel1 と、このチャネルにサブスクライブする 3 つのクライアント (client2、client5、client1) との関係を示しています。

Example

次の例は、パブリッシュとサブスクライブの仕組みを示しています。2 つの redis-cli クライアントを開く必要があります。

この例では、runoobChat:

という名前のサブスクリプションチャネルを作成しました。

第一个 redis-cli 客户端

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-cli 客户端

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 演示如下：

开启本地 Redis 服务，开启两个 redis-cli 客户端。
在第一个 redis-cli 客户端输入 SUBSCRIBE runoobChat，意思是订阅 runoobChat 频道。
在第二个 redis-cli 客户端输入 PUBLISH runoobChat “Redis PUBLISH test” 往 runoobChat 频道发送消息，这个时候在第一个 redis-cli 客户端就会看到由第二个 redis-cli 客户端发送的测试消息。

8. 事务

Redis 事务可以一次执行多个命令，并且带有以下三个重要的保证：

批量操作在发送 EXEC 命令前被放入队列缓存。
收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

一个事务从开始到执行会经历以下三个阶段：

开始事务。
命令入队。
执行事务。

实例

以下是一个事务的例子，它先以 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 还会继续执行。

9. 脚本

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"

ログイン後にコピー

10 GEO

Redis GEO 主要用于存储地理位置信息，并对存储的信息进行操作，该功能在 Redis 3.2 版本新增。

Redis GEO 操作方法有：

geoadd：添加地理位置的坐标。
geopos：获取地理位置的坐标。
geodist：计算两个位置之间的距离。
georadius：根据用户给定的经纬度坐标来获取指定范围内的地理位置集合。
georadiusbymember：根据储存在位置集合里面的某个地点获取指定范围内的地理位置集合。
geohash：返回一个或多个位置对象的 geohash 值。

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>

ログイン後にコピー

11 Redis Stream

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 指令追加消息时自动创建。

上图解析：

コンシューマグループ: XGROUP CREATE コマンドを使用して作成されたコンシューマグループ。コンシューマグループには複数のコンシューマ (コンシューマ) があります。
last_delivered_id: カーソル、各コンシューマグループにはカーソル last_delivered_id があり、メッセージを読んでいるコンシューマはカーソル last_delivered_id を前方に移動します。
pending_ids: コンシューマ (Consumer) の状態変数。コンシューマの未確認 ID を維持するために使用されます。 pending_ids は、クライアントによって読み取られたが、まだ ack (確認応答文字) を受信していないメッセージを記録します。