Redis の概要
Redis は完全にオープンソースで無料で、BSD プロトコルに準拠しており、高性能のキーと値のデータベースです
Redis と
Redis はデータの永続化をサポートしており、メモリ上のデータをディスクに保存し、再起動時に再ロードして使用することができます。
Redis の利点
Redis データ型
Redis は 5 つのデータ型をサポートしています: string (string)、hash (hash)、list (list)、set ( set)、zset (ソートセット:順序付きセット)#string
string は、redis の最も基本的なデータ型です。キーは値に対応します。 文字列はバイナリ セーフです。つまり、redis の文字列には任意のデータを含めることができます。たとえば、jpg 画像やシリアル化されたオブジェクトなどです。 Redis の基本データ型の 1 つは文字列型であり、文字列型の値のサイズは最大 512 MB です。理解: 文字列はJavaのマップのようなもので、キーは値に対応します
127.0.0.1:6379> set hello world OK 127.0.0.1:6379> get hello "world"
hash
ハッシュ コレクションは、キーと値のペアで構成される Redis データ型です。 Redis ハッシュは文字列型のキーと値のマッピング テーブルであり、オブジェクトの格納に特に適しています。理解: ハッシュはキーと値のセットと考えることができます。複数の文字列に対応するハッシュとして考えることもできます。
文字列との違い : 文字列はキーと値のペアですが、ハッシュは複数のキーと値のペアです。
// hash-key 可以看成是一个键值对集合的名字,在这里分别为其添加了 sub-key1 : value1、 sub-key2 : value2、sub-key3 : value3 这三个键值对 127.0.0.1:6379> hset hash-key sub-key1 value1 (integer) 1 127.0.0.1:6379> hset hash-key sub-key2 value2 (integer) 1 127.0.0.1:6379> hset hash-key sub-key3 value3 (integer) 1 // 获取 hash-key 这个 hash 里面的所有键值对 127.0.0.1:6379> hgetall hash-key 1) "sub-key1" 2) "value1" 3) "sub-key2" 4) "value2" 5) "sub-key3" 6) "value3" // 删除 hash-key 这个 hash 里面的 sub-key2 键值对 127.0.0.1:6379> hdel hash-key sub-key2 (integer) 1 127.0.0.1:6379> hget hash-key sub-key2 (nil) 127.0.0.1:6379> hget hash-key sub-key1 "value1" 127.0.0.1:6379> hgetall hash-key 1) "sub-key1" 2) "value1" 3) "sub-key3" 4) "value3"
list
Redis リストは、挿入順に並べ替えられた文字列の単純なリストです。リストの左側または右側に要素を追加できます。
127.0.0.1:6379> rpush list-key v1 (integer) 1 127.0.0.1:6379> rpush list-key v2 (integer) 2 127.0.0.1:6379> rpush list-key v1 (integer) 3 127.0.0.1:6379> lrange list-key 0 -1 1) "v1" 2) "v2" 3) "v1" 127.0.0.1:6379> lindex list-key 1 "v2" 127.0.0.1:6379> lpop list (nil) 127.0.0.1:6379> lpop list-key "v1" 127.0.0.1:6379> lrange list-key 0 -1 1) "v2" 2) "v1"
set
redis のセットは、文字列型の順序付けされていないコレクションです。セットはハッシュ テーブルのデータ構造を使用して実装されるため、挿入、削除、検索操作の時間計算量は O(1)##
127.0.0.1:6379> sadd k1 v1 (integer) 1 127.0.0.1:6379> sadd k1 v2 (integer) 1 127.0.0.1:6379> sadd k1 v3 (integer) 1 127.0.0.1:6379> sadd k1 v1 (integer) 0 127.0.0.1:6379> smembers k1 1) "v3" 2) "v2" 3) "v1" 127.0.0.1:6379> 127.0.0.1:6379> sismember k1 k4 (integer) 0 127.0.0.1:6379> sismember k1 v1 (integer) 1 127.0.0.1:6379> srem k1 v2 (integer) 1 127.0.0.1:6379> srem k1 v2 (integer) 0 127.0.0.1:6379> smembers k1 1) "v3" 2) "v1"
redis のセットと Java です。セットインはまだ少し異なります。 redis のセットは、複数の文字列型の値に対応するキーであり、文字列型のコレクションでもあります。ただし、redis のリストとは異なり、セット内の文字列コレクション要素を繰り返すことはできませんが、リストはできます。
Zsetredis zset は、set と同様、文字列型要素のコレクションであり、コレクション内の要素を繰り返すことはできません。
違いは、zset の各要素が double 型スコアに関連付けられていることです。 Redis はスコアを使用して、セット内のメンバーを小さいものから大きいものへと並べ替えます。
zset の要素は独特ですが、スコアは繰り返すことができます。
127.0.0.1:6379> zadd zset-key 728 member1 (integer) 1 127.0.0.1:6379> zadd zset-key 982 member0 (integer) 1 127.0.0.1:6379> zadd zset-key 982 member0 (integer) 0 127.0.0.1:6379> zrange zset-key 0 -1 withscores 1) "member1" 2) "728" 3) "member0" 4) "982" 127.0.0.1:6379> zrangebyscore zset-key 0 800 withscores 1) "member1" 2) "728" 127.0.0.1:6379> zrem zset-key member1 (integer) 1 127.0.0.1:6379> zrem zset-key member1 (integer) 0 127.0.0.1:6379> zrange zset-key 0 -1 withscores 1) "member0" 2) "982"
zset はスコアのサイズに従って並べ替えられます。 パブリッシュとサブスクライブ通常、Redis はメッセージのパブリッシュとサブスクライブには使用されません。
はじめにRedis パブリッシュおよびサブスクライブ (pub/sub) はメッセージ通信モデルです。送信者 (パブ) がメッセージを送信し、サブスクライバー (サブスクリプション) がメッセージを受信します。 。
Redis クライアントは、任意の数のチャネルにサブスクライブできます。
次の図は、チャネル channel1 と、このチャネルにサブスクライブする 3 つのクライアント (client2、client5、client1) 間の関係を示しています。
学Redis这篇就够了
当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：
学Redis这篇就够了
实例
以下实例演示了发布订阅是如何工作的。在我们实例中我们创建了订阅频道名为 redisChat:
127.0.0.1:6379> SUBsCRIBE redisChat Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "redisChat"
现在，我们先重新开启个 redis 客户端，然后在同一个频道 redisChat 发布两次消息，订阅者就能接收到消息。
127.0.0.1:6379> PUBLISH redisChat "send message" (integer) 1 127.0.0.1:6379> PUBLISH redisChat "hello world" (integer) 1 # 订阅者的客户端显示如下 1) "message" 2) "redisChat" 3) "send message" 1) "message" 2) "redisChat" 3) "hello world"
事务
redis 事务一次可以执行多条命令，服务器在执行命令期间，不会去执行其他客户端的命令请求。
事务中的多条命令被一次性发送给服务器，而不是一条一条地发送，这种方式被称为流水线，它可以减少客户端与服务器之间的网络通信次数从而提升性能。
Redis 最简单的事务实现方式是使用 MULTI 和 EXEC 命令将事务操作包围起来。
批量操作在发送 EXEC 命令前被放入队列缓存。
在接收到 EXEC 命令后，进入事务执行。如果在事务中有命令执行失败，其他命令仍然会继续执行。也就是说 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 事务命令
下表列出了 redis 事务的相关命令：
序号命令及描述：
1. DISCARD 取消事务，放弃执行事务块内的所有命令。
2. EXEC 执行所有事务块内的命令。
3. MULTI 标记一个事务块的开始。
4. UNWATCH 取消 WATCH 命令对所有 key 的监视。
5. WATCH key [key …]监视一个 (或多个) key ，如果在事务执行之前这个 (或这些) key 被其他命令所改动，那么事务将被打断。
持久化
Redis 是内存型数据库，为了保证数据在断电后不会丢失，需要将内存中的数据持久化到硬盘上。
RDB 持久化
将某个时间点的所有数据都存放到硬盘上。
可以将快照复制到其他服务器从而创建具有相同数据的服务器副本。
如果系统发生故障，将会丢失最后一次创建快照之后的数据。
如果数据量大，保存快照的时间会很长。
AOF 持久化
将写命令添加到 AOF 文件（append only file）末尾。
使用 AOF 持久化需要设置同步选项，从而确保写命令同步到磁盘文件上的时机。
这是因为对文件进行写入并不会马上将内容同步到磁盘上，而是先存储到缓冲区，然后由操作系统决定什么时候同步到磁盘。
选项同步频率always每个写命令都同步eyerysec每秒同步一次no让操作系统来决定何时同步
always 选项会严重减低服务器的性能
everysec 选项比较合适，可以保证系统崩溃时只会丢失一秒左右的数据，并且 Redis 每秒执行一次同步对服务器几乎没有任何影响。
no 选项并不能给服务器性能带来多大的提升，而且会增加系统崩溃时数据丢失的数量。
随着服务器写请求的增多，AOF 文件会越来越大。Redis提供了一项称作AOF重写的功能，能够消除AOF文件中的重复写入命令。
复制
slaveof host port コマンドを使用して、あるサーバーを別のサーバーのスレーブ サーバーにします。
スレーブ サーバーはマスター サーバーを 1 つだけ持つことができ、マスター間のレプリケーションはサポートされていません。
接続プロセス
マスターサーバーはスナップショットファイル、つまりRDBファイルを作成し、スレーブサーバーに送信し、書き込みコマンドの送信中に実行するバッファー レコード。
スナップショット ファイルの送信後、サーバーからバッファに格納されている書き込みコマンドの送信を開始します。
スレーブ サーバーは古いデータをすべて破棄し、マスター サーバーから送信されたスナップショット ファイルをロードします。その後、スレーブ サーバーはマスター サーバーからの書き込みコマンドの受け入れを開始します。
マスター サーバーは書き込みコマンドを実行するたびに、同じ書き込みコマンドをスレーブ サーバーに送信します。
マスター/スレーブ チェーン
負荷が増加し続ける場合、マスター サーバーがすべてのスレーブ サーバーをすぐに更新できない場合、または再接続して同期できない場合スレーブサーバーはシステムの過負荷を引き起こす可能性があります。
この問題を解決するには、中間層を確立して、メイン サーバーのレプリケーション ワークロードを軽減します。中間層サーバーは、同時に最上層サーバーのスレーブ サーバーとして、また最下層サーバーのマスター サーバーとして機能します。
Sentinel
Sentinel はクラスター内のサーバーを監視し、スレーブ サーバーから新しいマスター サーバーを自動的に選択できます。
フラグメンテーション
フラグメンテーションは、データを複数の部分に分割する方法です。データは複数のマシンに保存できます。この方法は、特定の問題を解決するのに役立ちます。線形レベル問題を解決するときにパフォーマンスの向上を達成できます。
4 つの Redis インスタンス R0、R1、R2、R3 があり、ユーザー user:1、user:2、… を表すキーが多数あるとします。保存する指定のキーを選択するにはさまざまな方法があります。どのような場合に。
最も単純なのは範囲シャーディングです。たとえば、0 ～ 1000 のユーザー ID はインスタンス R0 に保存され、1001 ～ 2000 のユーザー ID はインスタンス R1 に保存されます。ただし、これにはマッピング範囲テーブルを維持する必要があり、維持にコストがかかります。
もう 1 つのオプションはハッシュ シャーディングです。保存する必要があるインスタンスは、キーに対して CRC32 ハッシュ関数を実行し、それを数値に変換し、インスタンス数を剰余することによって決定されます。
シャーディングが実行される場所に応じて、シャーディングは 3 つのシャーディング方法に分類できます。
クライアント シャーディング: クライアントは整合性アルゴリズムを使用します。ハッシュなどにより、どのノードに配布するかを決定します。
プロキシ シャーディング: クライアントのリクエストをプロキシに送信すると、プロキシはそれを正しいノードに転送します。
サーバー シャーディング: Redis クラスター。
以上がRedis の包括的な知識ポイントは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
