Redis 高可用性ソリューションの詳細な図による説明

Redis クラスターを最初から理解して構築する

一部の開発者は、データ結果のキャッシュなど、アプリケーションでのみ Redis を使用します。そして現在では、優れた Redis クライアント ツール (redisson) が数多くあり、基本的に redis コマンドに注意を払わずにかなりの数の機能を実行できます。したがって、次の問題には十分な注意が払われていない可能性があります:

災害から回復するにはどうすればよいですか?つまり、特定の Redis ノードに問題がある場合、サービスの高可用性を確保する方法

水平方向に拡張するにはどうすればよいでしょうか?データの量が特に大きい場合、単一 Redis のパフォーマンスの問題を解決する方法

クラスターには少なくとも何台のマシンが必要ですか?または、複数の Redis ノード

# のクラスターを構築するためにどのようなテクノロジーとツールが使用されていますか?

災害から回復するにはどうすればよいですか?

Redis はマスター/スレーブ ホット スタンバイ メカニズムを提供します。マスター サーバーのデータはスレーブ サーバーに同期されます。マスター サーバーのステータスはセンチネルを通じてリアルタイムで監視され、マスター サーバーの選択を担当します。 。メインサーバーに異常が発見された場合、一定のアルゴリズムに従ってメインサーバーを再選出し、問題のあるサーバーを利用可能リストから削除し、最終的にクライアントに通知します。マスターとスレーブは、以下に示すように 1 対多のツリー構造です。

Sentinel

Sentinel は中国のname of Sentinel. Redis によって生成される高可用性アーキテクチャ ツールは、それ自体が独立したプロセスであり、複数の Redis クラスターを同時に監視できます。

Sentinel クラスター

高可用性を考慮すると、Sentinel 自体もクラスタリングをサポートする必要があります。Sentinel が 1 つしかない場合、単一点の問題が発生します。

センチネルの決定

センチネルには数量構成があります。特定のマスター サービスが同時に利用できないとセンチネルの数が判断した場合、マスター/スレーブ スイッチはたとえば、合計 5 つのセンチネルがあり、3 人のセンチネルがサービスが利用できないと判断した場合、マスターとスレーブの切り替えを行うことを決定します。これにより、ネットワークの瞬間的な異常など、誤った切り替えを回避し、切り替えコストを削減できます。

水平方向に拡張するにはどうすればよいですか?

redis に限らず、他のデータベース製品であっても、単一ノードのデータ容量が一定の上限に達すると、外部にサービスを提供する能力がどんどん弱まってしまいます。 Redis は、クラスター機能を実装するための上位バージョンの redis-trib.rb を提供しています。また、サードパーティ ツール twemproxy を使用することもできます。

分散化、すべてのノードは平等です

Redis クラスターは集中化を念頭に置いて設計されていません。これにより、中央ノードの単一ポイントなどの問題を回避できます。各ノードはクラスター全体の状態を把握でき、単一ノードの Redis と同様に、それに接続されているノードはすべてのキーにアクセスできます。

クラスター模式図

自分の理解に基づいて描いたものですが、誤解がある場合はご指摘ください。

キーと Redis ノードの関係

中国語でハッシュ スロットとして理解される hasy soldt を紹介しました。合計 16384 個あり、操作するキーはモジュロ アルゴリズムを使用してキーがどのスロットに該当するかを確認します。

HASH_SLOT = CRC16(key) mod 16384

ハッシュ スロットとノードの間には特定の関係があるため、キーを特定の Redis ノードに割り当てることができます。

詳細な関係はさらに詳しく調べることができます。たとえば、ノード A は 0 ～ 5000 の番号が付けられたハッシュ スロットを担当し、ノード B は 5001 ～ 1000 を担当します。

段階的に構築します

システムは ubuntu で、redis が提供するクラスタツール redis-trib.rb を使用して、3 つのマスターと 3 つのスレーブでクラスターの構築を開始します。

最新の redis をインストールします

redis_cluster ディレクトリを作成し、7000 から 7005 までの 6 つのディレクトリを作成します

redis ディレクトリ内の redis.conf を中央より上に作成した 6 つのディレクトリにコピーします

分别修改redis.conf文件,对6个文件做类似的修改。

port  7000                                       //端口7000       
bind  127.0.0.1                                  //默认ip为127.0.0.1 需要改为其他节点机器可访问的ip
daemonize    yes                                 //后台运行
pidfile  /var/run/redis_7000.pid                 //pidfile文件对应7000
cluster-enabled  yes                             //开启集群
cluster-config-file  nodes_7000.conf             //集群的配置
cluster-node-timeout  15000                      //请求超时  默认15秒，可自行设置

bind需要注意的就是需要配置为其它机器可以访问的ip，否则无论是创建集群还是客户端连接都会有问题。

启动6个redis

redis-server redis_cluster/7000/redis.conf
redis-server redis_cluster/7001/redis.conf
redis-server redis_cluster/7002/redis.conf
redis-server redis_cluster/7003/redis.conf
redis-server redis_cluster/7004/redis.conf
redis-server redis_cluster/7005/redis.conf

创建集群
redis的src目录下有个redis-trib.rb，将它复制到/usr/local/bin中，然后执行如下脚本：

redis-trib.rb  create  --replicas  1  127.0.0.1:7000 127.0.0.1:7001  127.0.0.1:7002 127.0.0.1:7003  127.0.0.1:7004  127.0.0.1:7005

--replicas后面的1代表从服务器的个数，上面可以理解为前面3个为主服务器，后面三个分别做为从服务器，即三对主从。

执行过程中会遇到提示需要安装ruby，安装完成之后又会提示安装 gem redis。

安装gem redis，折腾了好久，最终发现是因为在国内访问不了某些网站导致通过apt-get install安装不成功，最后通过下载源码的方式安装成功。

再次执行创建集群的脚本,出现如下提示：

输入yes，继续

最少需要多少个主服务器？

可能是基于某些约定，集群约定只有当可用节点数大于半数以上时才具备对外提供服务的能力。首先数量一定是奇数，其实必须大于1，所以最少的主服务器数量为3。

测试集群
连接客户端，由于我的所有节点都是在本地，所以不需要输入ip，但需要加-c的参数。redis-cli -c -p 7000

连接成功后，增加一个key

set mykey 123

有一行提示语，指向到端口7002，这说明虽然我们连接的是7000的实例，但通过hash算法最终会将key分配到7002的实例上。

再连接7005端口查询下key，测试下是否任意一个实例都可以查询到key

get mykey

显示指向到端口7002

更多redis知识请关注redis数据库教程栏目。

以上がRedis 高可用性ソリューションの詳細な図による説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。