Redis Scaling and Failover for DirectumRX Services

Redis هو نظام إدارة قاعدة بيانات فئة NoSQL (قواعد بيانات إدارة قواعد البيانات غير العلائقية) وهو بالكامل في ذاكرة الوصول العشوائي. للوصول إلى البيانات ، يتم استخدام نموذج "المفتاح" - "القيمة". غالبًا ما يستخدم نظام إدارة قواعد البيانات لتخزين ذاكرات التخزين المؤقت في خدمات قابلة للتطوير ، لتخزين الصور والبيانات الصغيرة.

يستخدم Redis DBMS على نطاق واسع بسبب:

• سرعة عالية ، لأن يتم تخزين جميع البيانات في ذاكرة الوصول العشوائي.
• عبر منصة.
• التوزيع بموجب ترخيص BSD (ينطبق على البرامج مفتوحة المصدر).

يمكن تقدير مدى توزيع تطبيق Redis وقابليته للتطبيق من خلال الكم الهائل من الوثائق مع جميع أنواع الحالات على الموقع الرسمي للمشروع .

إذا كنت تستخدم القياس الأفقي لخدمات DirectumRX ، فيجب عليك استخدام التثبيت الآمن من Redis للعمل بشكل صحيح مع خدمة تخزين DirectumRX وخدمة الوصول إلى الويب DirectumRX.



سيقوم Redis بتخزين البيانات التشغيلية وذاكرة التخزين المؤقت وغيرها من المعلومات الضرورية لتشغيل الخدمات في وضع القياس بحيث لا تعتمد عملية تفاعل المستخدم مع النظام على التثبيت الذي يعمل معه حاليًا.

لن تخزن Redis بيانات حساسة ولن تكون تحت عبء ثقيل. ولكن في حالة فشل Redis ، سيواجه المستخدمون العديد من الأخطاء عند التبديل بين عمليات التثبيت.

على موقع Redis الرسمي ، هناك طريقتان لضمان القياس الأفقي والتسامح مع الخطأ:

1. باستخدام Redis Sentiel .
2. باستخدام Redis الكتلة .

النظر في تخصيص هذه الخيارات.

تكوين Redis Sentiel

تم تطبيق الخيار باستخدام Redis Sentiel (Redis Tracking Node) في Redis 2.4 ويتضمن استخدام خدمة Redis Sentiel الإضافية لمراقبة مدى توفر المعالج. يقوم أيضًا بتكوين العقد المتماثلة في حالة فشل المعالج. تحديد أي من العقد SLAVE ستصبح MASTER وإجراء إعادة التكوين أثناء التنقل.

تنفذ المخطط الكلاسيكي:



يمكن أن يكون هناك العديد من العقد SLAVE (حتى 1000 وفقًا للموقع الرسمي) ، من أجل العمل المنتج ، يوصى باستخدام عقدتي SLAVE على الأقل.

عادةً ما يتم تكوين النظام بطريقة يتم تكوين خدمة Redis Sentiel على العقد MASTER و SLAVE ، وإذا فشلت عقدة MASTER ، تقرر عقد المراقبة المتبقية إدخال MASTER جديد.

الإصدار الحالي من Redis متاح للتنزيل من الموقع الرسمي لمطور المنتج . ومع ذلك ، فإن موقع التوزيع متاح فقط لنظام التشغيل Linux. في وقت واحد ، كان مشروع Microsoft لنقل أجهزة Redis إلى Windows قيد التطوير ، ولكن في الوقت الحالي توقف المشروع عن التطوير على الإصدار 3.2.100 ، لذلك في هذه المقالة سننظر في خيار النشر الأكثر صلة - على نظام Linux.

كعقد اختبار ، سوف نستخدم مضيفين افتراضيين هما redis1 و redis2 مع توزيع Linux المثبت على دبيان 10.

أولاً ، قم بتحديث قوائم الحزمة من المستودع الافتراضي وتثبيت Redis:

apt-get update && apt-get upgrade apt install redis-server 

التحقق من الإصدار:

 root@redis1:/home/user# redis-server -v Redis server v=5.0.3 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=afa0decbb6de285f 

دع redis1 يعمل كعقدة MASTER و redis2 يكون بمثابة عقدة SLAVE.

للقيام بذلك ، نكتب في ملفات تكوين Redis المعلمات الضرورية التي ستتيح لك إنشاء نسخة متماثلة (لم تتسامح بعد مع الخطأ).

بالنسبة لـ redis1 في ملف التكوين /etc/redis/redis.conf ، حدد:

 # ,   MASTER     . requirepass TestPass 

بالنسبة لـ redis2 في ملف التكوين /etc/redis/redis.conf ، حدد:

 #   MASTER  . slaveof redis1 6379 #      . masterauth TestPass #   ,         . requirepass TestPass 

أعد تشغيل خدمات خادم redis على كلا العقدتين:

 root@redis1:/etc/redis# /etc/init.d/redis-server stop [ ok ] Stopping redis-server (via systemctl): redis-server.service. root@redis1:/etc/redis# /etc/init.d/redis-server start [ ok ] Starting redis-server (via systemctl): redis-server.service. root@redis2:/etc/redis# /etc/init.d/redis-server stop [ ok ] Stopping redis-server (via systemctl): redis-server.service. root@redis2:/etc/redis# /etc/init.d/redis-server start [ ok ] Starting redis-server (via systemctl): redis-server.service. 

نتحقق من الجانب MASTER من أن العقد أصبحت نسخًا متماثلة وتلقى الأدوار اللازمة:

 root@redis1:/etc/redis# redis-cli -a TestPass info replication Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Replication role:master connected_slaves:1 slave0:ip=192.168.9.96,port=6379,state=online,offset=28,lag=0 master_replid:56b0a702d5823d107b0ca1ca2c80f8ef650a4b28 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:28 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:28 

على جانب الرقيق ، نرى نفس الموقف:

 root@redis2:/etc/redis# redis-cli -a TestPass info replication Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Replication role:slave master_host:redis1 master_port:6379 master_link_status:up master_last_io_seconds_ago:4 master_sync_in_progress:0 slave_repl_offset:14 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:56b0a702d5823d107b0ca1ca2c80f8ef650a4b28 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:14 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:14 

تحتاج الآن إلى تكوين النسخة المتماثلة بحيث تتم استعادتها تلقائيًا في حالة فشل إحدى العقد. للقيام بذلك ، نحتاج إلى خدمة تتبع Redis Sentinel.

بناءً على الوثائق ، يمكن لخدمة مراقبة Redis Sentinel تنفيذ العمليات التالية:

1. يتحقق من توفر العقد MASTER و SLAVE ويمكنه إرسال تنبيهات حول عدم إمكانية الوصول إلى العقد.
2. في حالة فشل عقدة MASTER ، يمكن أن تضع عقدة الشاهد عقدة SLAVE في وضع MASTER ، بالإضافة إلى إعادة تكوين العقد SLAVE المتبقية ، وتبدأ في العمل مع MASTER الجديد.
3. لإجراء تغييرات على ملفات التكوين الخاصة بالعقد MASTER و SLAVE.

من أجل نقاء التجربة ، سنضع خدمة شاهد على جهاز redis3 VM منفصل.

نقوم بتوصيل مستودع Redis بنفس الطريقة وتثبيت حزمة redis-sentinel:

 apt install redis-sentinel 

بعد التثبيت ، تحتاج إلى إجراء الإعدادات في ملف التكوين لعقدة المراقبة /etc/redis/sentinel.conf:

 #    redis1   6379. #   1 -      , #        MASTER-. #       , #     MASTER-. sentinel monitor master01 redis1 6379 1 #  3 ,       . sentinel down-after-milliseconds master01 3000 #    MASTER- sentinel failover-timeout master01 6000 # ,  SLAVE-   . #    ,    , #      . sentinel parallel-syncs master01 1 #    . bind 192.168.9.97 127.0.0.1 ::1 #    MASTER-. sentinel auth-pass master01 TestPass 

أعد تشغيل الخدمة بعد إجراء الإعدادات:

 root@redis3:/etc/redis# /etc/init.d/redis-sentinel restart [ ok ] Restarting redis-sentinel (via systemctl): redis-sentinel.service. 

تحقق من أن خدمة التتبع شهدت MASTER و SLAVE:

 root@redis3:/etc/redis# redis-cli -p 26379 info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=master01,status=ok,address=192.168.9.95:6379,slaves=1,sentinels=1 

نبدأ التجارب.

نقوم بمحاكاة الفشل وإيقاف خدمة خادم redis على عقدة redis1 والحصول على المعلومات الحالية لعقدة الشاهد:

 root@redis3:/etc/redis# redis-cli -p 26379 info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=master01,status=ok,address=192.168.9.96:6379,slaves=1,sentinels=1 

نرى لقد تغير MASTER.

سنقوم باستعادة تشغيل عقدة redis1 والتحقق من حالتها:

 root@redis3:/var/log/redis# redis-cli -h redis1 -p 6379 -a TestPass info replication Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Replication role:slave master_host:192.168.9.96 master_port:6379 master_link_status:up master_last_io_seconds_ago:1 master_sync_in_progress:0 slave_repl_offset:15977 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:6c0c7d0eedccede56f211f2db74a98c4d0ff6d56 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:15977 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:15977 

نرى أن العقدة تلقت دور SLAVE ، وأن العقدة redis2 هي عقدة MASTER.

محاكاة فشل عقدة redis2 والتحقق من حالة عقدة الشاهد:

 root@redis3:/var/log/redis# redis-cli -p 26379 info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=master01,status=ok,address=192.168.9.95:6379,slaves=1,sentinels=1 

وحالة العقدة redis1:

 root@redis3:/var/log/redis# redis-cli -h redis1 -p 6379 -a TestPass info replication Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. # Replication role:master connected_slaves:0 master_replid:6e9d67d6460815b925319c2bafb58bf2c435cffb master_replid2:6c0c7d0eedccede56f211f2db74a98c4d0ff6d56 master_repl_offset:33610 second_repl_offset:26483 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:33610 

عظيم ، الآلية تعمل. لكن السؤال الذي يطرح نفسه الآن هو كيف سنربط خدمات DirectumRX الخاصة بنا ، لأنها تحتاج إلى عنوان عقدة واحد. سنقوم بحل الموقف باستخدام خدمة HAProxy.

Redis العقدة وكيل

يمكن أن تعمل أي خدمة TCP tcp كوكيل عكسي لعقد Redis. في هذه المقالة ، سننظر في استخدام HAProxy ، نظرًا لأنه أداة متخصصة مصممة لتوفير إتاحة عالية وموازنة تحميل ، ويتم استخدامها بواسطة خدمات معروفة عالمياً. اقرأ المزيد عن HAProxy على صفحة المطور .

تثبيت HAProxy على عقدة redis3:

 root@redis3:/var/log/redis# apt install haproxy 

في ملف تكوين HAProxy /etc/haproxy/haproxy.cfg ، أضف الإعدادات لطلبات الوكلاء إلى عقد Redis:

 … frontend ft_redis bind *:6379 name redis mode tcp default_backend bk_redis backend bk_redis mode tcp option tcp-check tcp-check connect #  ,         . tcp-check send AUTH\ TestPass\r\n tcp-check expect string +OK tcp-check send PING\r\n tcp-check expect string +PONG tcp-check send info\ replication\r\n #    MASTER, .. SLAVE      . tcp-check expect string role:master tcp-check send QUIT\r\n tcp-check expect string +OK server Redis1 redis1:6379 check inter 3s server Redis2 redis2:6379 check inter 3s 

في هذا التكوين ، تتم الإشارة إلى أننا سنرسل أي طلبات تأتي إلى جميع واجهات الجهاز الظاهري الحالي على العنوان الموجود على المنفذ 6379. سنقوم بنقل الطلبات إلى العقدة التي ستستجيب لوجود دور MASTER.

أعد تشغيل خدمة haproxy:

 root@redis3:/etc/haproxy# /etc/init.d/haproxy restart 

دعنا نحاول الاتصال باستخدام عميل redis-cli وإنشاء مفتاح اختبار:

 root@redis3:/etc/haproxy# redis-cli -p 6379 -a TestPass Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 127.0.0.1:6379> SET TestKey "Some test string" OK 127.0.0.1:6379> GET TestKey "Some test string" 127.0.0.1:6379> info keyspace # Keyspace db0:keys=1,expires=0,avg_ttl=0 

إيقاف العقدة redis1 والاستعلام مرة أخرى قائمة المفاتيح:

 127.0.0.1:6379> info keyspace Error: Server closed the connection (3.01s) 127.0.0.1:6379> info keyspace # Keyspace db0:keys=1,expires=0,avg_ttl=0 (2.01s) 127.0.0.1:6379> GET TestKey "Some test string" 

نرى أنه تم قطع الاتصال لبعض الوقت ، ولكن بعد ذلك تمت استعادة الاتصال مرة أخرى وبقيت جميع البيانات في مكانها.

يكفي الآن تسجيل عنوان الوكيل العكسي في ملفات التكوين الخاصة بخدمات DirectumRX للاتصال بـ Redis.

تكوين Redis الكتلة

يعد خيار تجميع نظام المجموعة Redis ، الذي يتم تطبيقه على الإصدار redis 3.0 والإصدارات الأحدث ، حلاً لإنشاء وإدارة نظام مع تجزئة البيانات وتكرارها. يؤدي مهام إدارة العقدة والنسخ المتماثل ومزامنة البيانات على العقد وضمان الوصول إلى تطبيق العميل إلى عقدة MASTER في حالة فشل أحد العقد MASTER المتعددة.



تعمل Redis Cluster في الوضع المتعدد ، حيث يمكن أن تحتوي كل عقدة MASTER على عقد SLAVE واحد أو أكثر (حتى 1000).

القياس هو الوظيفة الرئيسية للكتلة. بالإضافة إلى ذلك ، يمكن أن تضمن المجموعة تسامح الأعطال في خدمة Redis:

• إذا لم تنجح بعض العقد ، فإن الكتلة تعيد توزيع الحمل منها على عقد أخرى ؛
• في حالة عدم عمل العقد الرئيسية ، تنتهي المجموعة بالكامل.

قد تنشأ حالة عندما يكتب العميل 2 إلى العقدة M2. يجيب M2 "موافق" ويحاول الكتابة إلى S2. في الوقت نفسه ، لا تنتظر M2 الإكمال الصحيح لتبادل البيانات مع S2 ، ولكنها تستجيب للعميل على الفور. في هذه الحالة ، قد لا تحتوي النسخة المتماثلة S2 على كافة البيانات. لذلك ، يوصى باستخدام عدة نسخ طبق الأصل من SLAVE.

قد ينشأ أيضًا موقف عندما يتوقف M1 و M3 عن "رؤية" M2 ، ولا يزال العميل يواصل كتابة البيانات إلى M2. إذا استمر عدم التوافر لبعض الوقت (معلمة انقضاء عقدة نظام المجموعة) ، فسيتم وضع S2 في هذه الحالة في وضع MASTER ، وسوف يتوقف M2 عن العمل بمفرده.

توصي الوثائق الرسمية باستخدام 6 عقد - مثيل Redis واحد لكل عقدة ، مما يسمح بمزيد من الموثوقية ، ولكن لا أحد يمنع استخدام ثلاث عقد مع طبولوجيا الاتصال التالية:



في حالة فشل أحد العقد الفعلية ، ستذهب النسخ المتماثلة SLAV المقابلة إلى وضع MASTER ، ولن يتم تعطيل العملية.

ننفذ 3 أجهزة افتراضية (redis1 و redis2 و redis3) على منصة الاختبار ، ستعمل كل واحدة منها على مثلي Redis.

سيتصل تطبيق العميل بمنفذ محدد في ملف تكوين العميل ، وبالتالي ، يجب أن تعمل أزواج MASTER - SLAVE على نفس المنافذ.

بالنسبة للزوج M1 - S1 ، سوف نستخدم المنفذ 6381
بالنسبة للزوج M2 - S2 ، سوف نستخدم المنفذ 6382
بالنسبة للزوج M3 - S3 ، سوف نستخدم المنفذ 6383

تحضير ملفات التكوين

على redis1:

 cp /etc/redis/redis.conf /etc/redis/m1_redis.conf cp /etc/redis/redis.conf /etc/redis/s2_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak 

على redis2:

 cp /etc/redis/redis.conf /etc/redis/m2_redis.conf cp /etc/redis/redis.conf /etc/redis/s3_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak 

على redis3:

 cp /etc/redis/redis.conf /etc/redis/m3_redis.conf cp /etc/redis/redis.conf /etc/redis/s1_redis.conf mv /etc/redis/redis.conf /etc/redis/redis.bak 

املأ ملفات التكوين وفقًا للقالب:

 bind <IP- > protected-mode no #      ,    . port <> pidfile /var/run/redis_<>.pid # <yes/no> -   Redis Cluster cluster-enabled yes # ,      : #  ,  ,    . #         . cluster-config-file nodes-<>.conf #  ,  master-   , #          slaves #    . cluster-node-timeout 15000 

لنطلق عقد Redis:

العقدة redis1:

 root@redis1:/etc/redis# redis-server /etc/redis/m1_redis.conf root@redis1:/etc/redis# redis-server /etc/redis/s2_redis.conf 

عقدة Redis2:

 root@redis2:/etc/redis# redis-server /etc/redis/m2_redis.conf root@redis2:/etc/redis# redis-server /etc/redis/s3_redis.conf 

عقدة Redis3:

 root@redis3:/etc/redis# redis-server /etc/redis/m3_redis.conf root@redis3:/etc/redis# redis-server /etc/redis/s1_redis.conf 

لتكوين الكتلة ، تحتاج إلى استخدام الأداة المساعدة للعميل redis-cli ، لتمريرها قائمة من أزواج منافذ ip: من الخوادم التي ستلعب أدوار MASTER و SLAVE:

 redis-cli --cluster create redis1-ip:6381 redis2-ip:6382 redis3-ip:6383 redis1-ip:6382 redis2-ip:6383 redis3-ip:6381 --cluster-replicas 1 

، حيث يخبرك الخيار --cluster-replicas 1 بعدد SLAVE الذي سيحصل عليه كل سيد ، ويتم تحديده تلقائيًا من قائمة النسخ المتماثلة المنقولة.

 root@redis1:~/redis/src# redis-cli --cluster create 192.168.9.51:6381 192.168.9.52:6382 192.168.9.53:6383 192.168.9.51:6382 192.168.9.52:6383 192.168.9.53:6381 --cluster-replicas 1 >>> Performing hash slots allocation on 6 nodes... Master[0] -> Slots 0 - 5460 Master[1] -> Slots 5461 - 10922 Master[2] -> Slots 10923 - 16383 Adding replica 192.168.9.52:6383 to 192.168.9.51:6381 Adding replica 192.168.9.51:6382 to 192.168.9.52:6382 Adding replica 192.168.9.53:6381 to 192.168.9.53:6383 >>> Trying to optimize slaves allocation for anti-affinity [OK] Perfect anti-affinity obtained! M: e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381 slots:[0-5460] (5461 slots) master M: d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382 slots:[5461-10922] (5462 slots) master M: 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383 slots:[10923-16383] (5461 slots) master S: 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382 replicates d499af3672b3063c7239572ec311ad3160f280ae S: 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383 replicates 3a41475e1613519c3ecdec695736a898262a24a5 S: 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381 replicates e92cb96fd6c20db7509662a248902e3751ebe95f Can I set the above configuration? (type 'yes' to accept): yes >>> Nodes configuration updated >>> Assign a different config epoch to each node >>> Sending CLUSTER MEET messages to join the cluster Waiting for the cluster to join ..... >>> Performing Cluster Check (using node 192.168.9.51:6381) M: e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381 slots:[0-5460] (5461 slots) master 1 additional replica(s) M: d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382 slots:[5461-10922] (5462 slots) master 1 additional replica(s) S: 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381 slots: (0 slots) slave replicates e92cb96fd6c20db7509662a248902e3751ebe95f S: 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382 slots: (0 slots) slave replicates d499af3672b3063c7239572ec311ad3160f280ae S: 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383 slots: (0 slots) slave replicates 3a41475e1613519c3ecdec695736a898262a24a5 M: 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383 slots:[10923-16383] (5461 slots) master 1 additional replica(s) [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered. 

تم بناء الكتلة بشكل صحيح. سنقوم بعرض معلومات حول الكتلة:

 root@redis1:~/redis/src# redis-cli -c -h 192.168.9.51 -p 6381 192.168.9.51:6381> CLUSTER INFO cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:6 cluster_my_epoch:1 cluster_stats_messages_ping_sent:1254 cluster_stats_messages_pong_sent:1243 cluster_stats_messages_sent:2497 cluster_stats_messages_ping_received:1238 cluster_stats_messages_pong_received:1254 cluster_stats_messages_meet_received:5 cluster_stats_messages_received:2497 192.168.9.51:6381> 

لاختبار نسخة متماثلة محددة ، كما هو الحال مع Redis Sentiel ، يمكنك استخدام أمر النسخ المتماثل INFO:

 root@redis1:~/redis/src# redis-cli -c -h 192.168.9.51 -p 6381 192.168.9.51:6381> INFO replication # Replication role:master connected_slaves:1 slave0:ip=192.168.9.53,port=6381,state=online,offset=1946,lag=0 master_replid:59cd95d394dad9d0e49042637fdfd5290db4abfe master_replid2:0000000000000000000000000000000000000000 master_repl_offset:1946 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:1946 192.168.9.51:6381> 

دعنا نحاول إنشاء عدة مفاتيح والتحقق من ظهور هذه المفاتيح على النسخ المتماثلة:

 192.168.9.51:6381> SET key1 test1 -> Redirected to slot [9189] located at 192.168.9.52:6382 OK 192.168.9.52:6382> SET key2 test2 -> Redirected to slot [4998] located at 192.168.9.51:6381 OK 192.168.9.51:6381> SET key3 test3 OK 192.168.9.51:6381> 

تحقق من M2:

 root@redis2:/home/user# redis-cli -c -h 192.168.9.52 -p 6382 192.168.9.52:6382> GET key1 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.51:6381 "test2" 192.168.9.51:6381> GET key3 "test3" 192.168.9.51:6381> 

وعلى M3:

 root@redis3:/home/user# redis-cli -c -h 192.168.9.53 -p 6383 192.168.9.53:6383> GET key1 -> Redirected to slot [9189] located at 192.168.9.52:6382 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.51:6381 "test2" 192.168.9.51:6381> GET key3 "test3" 192.168.9.51:6381> 

سنقوم بتعطيل عقدة redis1 وتحقق من كيفية عمل S1:

 192.168.9.52:6382> CLUSTER NODES <b>182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave,fail d499af3672b3063c7239572ec311ad3160f280ae 1569509904727 1569509900000 4 connected</b> 485ffb786e9763955e6f10ffc59247690ad9bc11 <i>192.168.9.53:6381@16381 master</i> - 0 1569510017272 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569510018274 5 connected <b>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 master,fail - 1569509906731 1569509901721 1 connected</b> 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569510019275 3 connected 10923-16383 d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 myself,master - 0 1569510017000 2 connected 5461-10922 

نرى معلومات حول فشل M1 و S2 وأن S3 قد تحول إلى وضع MASTER.

تحقق من مكان تخزين المفاتيح:

 192.168.9.52:6382> GET key1 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6381> GET key3 "test3" 192.168.9.53:6381> 

المفاتيح التي تم تخزينها مسبقًا على redis1 متاحة الآن على redis3.

قم باستعادة تشغيل عقدة redis1 وتحقق من حالة العقدتين M1 و S2:

 192.168.9.53:6381> CLUSTER NODES <i>e92cb96fd6c20db7509662a248902e3751ebe95f 192.168.9.51:6381@16381 slave 485ffb786e9763955e6f10ffc59247690ad9bc11 0 1569511658217 7 connected 182e5cffc9c31c231de69ddbaf507ec1fe17bb09 192.168.9.51:6382@16382 slave d499af3672b3063c7239572ec311ad3160f280ae 0 1569511657000 4 connected</i> d499af3672b3063c7239572ec311ad3160f280ae 192.168.9.52:6382@16382 master - 0 1569511656000 2 connected 5461-10922 3a41475e1613519c3ecdec695736a898262a24a5 192.168.9.53:6383@16383 master - 0 1569511656000 3 connected 10923-16383 485ffb786e9763955e6f10ffc59247690ad9bc11 192.168.9.53:6381@16381 myself,master - 0 1569511656000 7 connected 0-5460 44f656062259005adea58bc5ad024071a050e192 192.168.9.52:6383@16383 slave 3a41475e1613519c3ecdec695736a898262a24a5 0 1569511657216 5 connected 

استعادت صحة M1 و S2 ، لكن الآن M1 في وضع SLAVE.

والمفاتيح موجودة أيضًا على عقدة redis3:

 192.168.9.53:6383> GET key1 -> Redirected to slot [9189] located at 192.168.9.52:6382 "test1" 192.168.9.52:6382> GET key2 -> Redirected to slot [4998] located at 192.168.9.53:6381 "test2" 192.168.9.53:6383> GET key3 -> Redirected to slot [935] located at 192.168.9.53:6381 "test3" 

تم تكوين الكتلة واختبار استرداد Redis.

للوصول إلى خدمات DirectumRX ، ستحتاج أيضًا إلى تكوين الوكلاء العكسيين ، كما في حالة إعداد Redis Sentiel.

بدلا من الاستنتاج

لم تؤخذ هذه المقالة في الاعتبار طريقة أخرى لزيادة التسامح مع الخطأ Redis - باستخدام مدير موارد نظام مجموعة خارجية ، على سبيل المثال ، منظم ضربات القلب . في هذه الحالة ، سيكون من الممكن الحصول على عقدتين ، ومع ذلك ، هناك احتمال كبير بفقدان البيانات في حالة الطوارئ.

بالنسبة للوكيل العكسي (في هذه الحالة ، HAProxy) ، من المستحسن أيضًا توفير التسامح مع الخطأ ، ولكن هذه المشكلة كانت أيضًا خارج نطاق هذه المقالة. إذا كنت مهتمًا بالموضوع ، فيمكن أيضًا النظر في خيارات النشر هذه في مقالات منفصلة مع التوليف التدريجي واختبار النتائج.

يمكنك العثور على الروابط أدناه لمعرفة المزيد حول الموضوع:
Redis كتلة البرنامج التعليمي
وثائق الحارس Redis
دليل تكوين HAProxy .