Apakah cara untuk mewujudkan seni bina tuan-hamba Redis?

Membina persekitaran tuan-hamba

Ketika Redis adalah semua nod induk secara lalai, jadi kita perlu mengubah suai beberapa konfigurasi untuk membina seni bina tuan-hamba Seni bina tuan-hamba redis agak mudah membina. Tiga cara disediakan untuk membina seni bina tuan-hamba, yang akan kami perkenalkan kemudian Sebelum memperkenalkan, kita mesti terlebih dahulu memahami ciri-ciri seni bina tuan-hamba: Dalam seni bina tuan-hamba, terdapat nod induk (master. ) dan sekurang-kurangnya satu nod hamba (slave ), dan replikasi data adalah sehala, ia hanya boleh disalin dari nod induk ke nod hamba, bukan dari nod hamba ke nod induk.

Cara mewujudkan seni bina tuan-hamba

Terdapat tiga cara untuk menubuhkan seni bina tuan-hamba:

• Dalam Redis. Tambahkan perintah slaveof {masterHost} {masterPort} pada fail konfigurasi conf, yang akan berkuat kuasa apabila tika Redis dimulakan

• Tambahkan --slaveof {masterHost} { parameter masterPort} selepas arahan permulaan pelayan redis

• Gunakan arahan terus dalam tetingkap interaktif redis-cli: slaveof {masterHost} {masterPort}

Tiga kaedah di atas boleh membina Redis Kami akan menunjukkan seni bina tuan-hamba dengan cara pertama, dan mencuba dua cara lain sendiri Memandangkan ia adalah demonstrasi, kami akan memulakan dua kejadian Redis secara tempatan dan bukannya memulakan kejadian redis pada berbilang mesin. Kami akan menyediakan port Untuk contoh nod induk 6379, sediakan contoh nod hamba dengan port 6480. Namakan fail konfigurasi instance redis port 6480 6480.conf dan tambahkan pernyataan slaveof di dalamnya pernyataan berikut pada penghujung fail konfigurasi.

slaveof 127.0.0.1 6379

Mulakan dua instance redis masing-masing Selepas bermula, mereka akan secara automatik mewujudkan hubungan tuan-hamba, kita akan bercakap secara terperinci kemudian Berjaya, kami mula-mula menambah sekeping data baharu pada nod induk 6379:

Nod induk menambah data baharu

dan kemudian memperoleh data pada nod hamba 6480:

Nod hamba memperoleh data

Dapat dilihat bahawa kita telah berjaya memperoleh nilai tambah dalam nod induk pada nod hamba, menunjukkan seni bina induk-hamba Ia telah berjaya disediakan Kami menggunakan arahan replikasi maklumat untuk melihat maklumat kedua-dua nod tersebut.

replikasi maklumat induk

Dapat dilihat bahawa peranan instance port 6379 adalah induk, terdapat instance penyambung, dan maklumat lain yang sedang berjalan, kami Mari kita lihat maklumat contoh redis port 6480.

replikasi maklumat hamba

Dapat diperhatikan bahawa kedua-dua nod merekodkan maklumat objek antara satu sama lain, dan maklumat ini akan digunakan semasa replikasi data. Satu perkara perlu dijelaskan di sini Secara lalai, nod hamba adalah baca sahaja dan tidak menyokong penulisan. Kami boleh mengesahkannya dan menulis sekeping data pada contoh 6480.

127.0.0.1:6480> set x 3 (error) READONLY You can't write against a read only replica. 127.0.0.1:6480>

menggesa baca sahaja dan tidak menyokong operasi tulis Sudah tentu, kami juga boleh mengubah suai konfigurasi Dalam fail konfigurasi, item konfigurasi replika baca sahaja digunakan untuk mengawal baca sahaja daripada pelayan. Mengapa hanya boleh baca sahaja? Kerana kita tahu bahawa replikasi adalah sehala, dan data hanya boleh dihantar dari induk ke nod hamba Jika penulisan didayakan pada nod hamba nod hamba diubah suai, dan nod induk tidak dapat merasakannya Nod hamba Data tidak boleh disalin ke nod induk, yang akan menyebabkan ketidakkonsistenan data, jadi disyorkan bahawa nod hamba hanya dibaca.

Pemutus sambungan seni bina tuan-hamba

Pemutus sambungan seni bina tuan-hamba juga merupakan perintah slaveof no one pada nod hamba untuk memutuskan sambungan daripada tuan Untuk membuka hubungan berikut, kami melaksanakan perintah slaveof no one pada nod 6480.

127.0.0.1:6480> slaveof no one OK 127.0.0.1:6480> info replication # Replication role:master connected_slaves:0 master_replid:a54f3ba841c67762d6c1e33456c97b94c62f6ac0 master_replid2:e5c1ab2a68064690aebef4bd2bd4f3ddfba9cc27 master_repl_offset:4367 second_repl_offset:4368 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:4367 127.0.0.1:6480>

Selepas melaksanakan perintah slaveof no one, peranan nod 6480 segera dipulihkan kepada master Mari kita lihat dan ia masih disambungkan ke instance 6379. Kami menambah nilai kunci baharu pada nod. 6379.

127.0.0.1:6379> set y 3 OK

dapatkan y pada nod 6480

127.0.0.1:6480> get y (nil) 127.0.0.1:6480>

Tidak boleh mendapatkan y pada nod 6480, kerana nod 6480 telah diputuskan sambungan daripada nod 6379, dan tiada hubungan tuan-hamba, slaveof arahan Bukan sahaja anda boleh memutuskan sambungan, tetapi anda juga boleh menukar pelayan induk Perintah ini ialah slaveof {newMasterIp} {newMasterPort}. lihat pada 6379 replikasi maklumat.

127.0.0.1:6379> info replication # Replication role:slave master_host:127.0.0.1 master_port:6480 master_link_status:up master_last_io_seconds_ago:2 master_sync_in_progress:0 slave_repl_offset:4367 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea master_replid2:0000000000000000000000000000000000000000 master_repl_offset:4367 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:4368 repl_backlog_histlen:0 127.0.0.1:6379>

Peranan nod 6379 sudah pun menjadi hamba, dan nod induk ialah 6480. Kita boleh melihat replikasi maklumat nod 6480.

127.0.0.1:6480> info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6379,state=online,offset=4479,lag=1 master_replid:99624d4b402b5091552b9cb3dd9a793a3005e2ea master_replid2:a54f3ba841c67762d6c1e33456c97b94c62f6ac0 master_repl_offset:4479 second_repl_offset:4368 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:4479 127.0.0.1:6480>

Terdapat maklumat tentang 6379 nod hamba pada nod 6480. Dapat dilihat bahawa arahan slaveof telah membantu kami melengkapkan suis pelayan utama.

复制技术的原理

redis 的主从架构好像很简单一样，我们就执行了一条命令就成功搭建了主从架构，并且数据复制也没有问题，使用起来确实简单，但是这背后 redis  还是帮我们做了很多的事情，比如主从服务器之间的数据同步、主从服务器的状态检测等，这背后 redis 是如何实现的呢?接下来我们就一起看看。

数据复制原理

我们执行完 slaveof 命令之后，我们的主从关系就建立好了，在这个过程中， master 服务器与 slave  服务器之间需要经历多个步骤，如下图所示：

redis 复制原理

slaveof 命令背后，主从服务器大致经历了七步，其中权限验证这一步不是必须的，为了能够更好的理解这些步骤，就以我们上面搭建的 redis  实例为例来详细聊一聊各步骤。

1、保存主节点信息

在 6480 的客户端向 6480 节点服务器发送 slaveof 127.0.0.1 6379 命令时，我们会立马得到一个 OK。

127.0.0.1:6480> slaveof 127.0.0.1 6379 OK 127.0.0.1:6480>

这时候数据复制工作并没有开始，数据复制工作是在返回 OK 之后才开始执行的，这时候 6480 从节点做的事情是将给定的主服务器 IP 地址  127.0.0.1 以及端口 6379 保存到服务器状态的 masterhost 属性和 masterport 属性里面。

2、建立 socket 连接

在 slaveof 命令执行完之后，从服务器会根据命令设置的 IP 地址和端口，跟主服务器创建套接字连接， 如果从服务器能够跟主服务器成功的建立  socket 连接，那么从服务器将会为这个 socket 关联一个专门用于处理复制工作的文件事件处理器，这个处理器将负责后续的复制工作，比如接受全量复制的  RDB 文件以及服务器传来的写命令。同样主服务器在接受从服务器的 socket 连接之后，将为该 socket  创建一个客户端状态，这时候的从服务器同时具有服务器和客户端两个身份，从服务器可以向主服务器发送命令请求而主服务器则会向从服务器返回命令回复。

3、发送 ping 命令

从服务器与主服务器连接成功后，做的第一件事情就是向主服务器发送一个 ping 命令，发送 ping 命令主要有以下目的：

• 检测主从之间网络套接字是否可用

• 检测主节点当前是否可接受处理命令

在发送 ping 命令之后，正常情况下主服务器会返回 pong 命令，接受到主服务器返回的 pong 回复之后就会进行下一步工作，如果没有收到主节点的  pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从服务器会断开复制连接，等待下一次定时任务的调度。

4、身份验证

从服务器在接收到主服务器返回的 pong 回复之后，下一步要做的事情就是根据配置信息决定是否需要身份验证：

• 如果从服务器设置了 masterauth 参数，则进行身份验证

• 如果从服务器没有设置 masterauth 参数，则不进行身份验证

在需要身份验证的情况下，从服务器将就向主服务器发送一条 auth 命令，命令参数为从服务器 masterauth  选项的值，举个例子，如果从服务器的配置里将 masterauth 参数设置为：123456，那么从服务器将向主服务器发送 auth 123456  命令，身份验证的过程也不是一帆风顺的，可能会遇到以下几种情况：

• 从服务器通过 auth 命令发送的密码与主服务器的 requirepass 参数值一致，那么将继续进行后续操作，如果密码不一致，主服务将返回一个  invalid password 错误

• 如果主服务器没有设置 requirepass 参数，那么主服务器将返回一个 no password is set 错误

所有的错误情况都会令从服务器中止当前的复制工作，并且要从建立 socket 开始重新发起复制流程，直到身份验证通过或者从服务器放弃执行复制为止。

5. Hantar maklumat port

Selepas pengesahan diluluskan, pelayan hamba akan melaksanakan arahan mendengar REPLCONF dan menghantar nombor port mendengar pelayan hamba ke pelayan induk, seperti dalam contoh kita Port yang didengari oleh pelayan hamba ialah 6480, maka pelayan hamba akan menghantar arahan REPLCONF listening 6480 ke pelayan induk Selepas pelayan induk menerima arahan ini, ia akan merekodkan nombor port dalam atribut slave_listening_port daripada status klien yang sepadan dengan pelayan hamba Ini adalah nilai port yang kita lihat dalam replikasi maklumat pelayan induk.

6. Replikasi data

Replikasi data ialah bahagian yang paling rumit dengan arahan psync Pelayan hamba akan menghantar arahan psync ke pelayan induk untuk memproses data. Penyegerakan, sebelum versi redis 2.8, arahan penyegerakan digunakan Selain daripada arahan yang berbeza, kaedah replikasi juga sangat berbeza nod induk dan rangkaian Banyak overhed Selepas redis versi 2.8, penyegerakan data akan dibahagikan kepada penyegerakan penuh dan penyegerakan separa.

• Replikasi penuh: Biasanya digunakan dalam senario replikasi awal Tidak kira versi lama atau baharu redis, replikasi penuh akan dilakukan apabila pelayan hamba menyambung ke perkhidmatan induk untuk yang pertama. masa. Ia akan menyalin induk Semua data nod dihantar ke nod hamba sekali gus Apabila data besar, ia akan menyebabkan banyak overhed pada nod induk dan versi awal redis hanya menyokong penuh replikasi, yang bukan kaedah replikasi data yang cekap

• Replikasi separa: digunakan untuk mengendalikan senario kehilangan data yang disebabkan oleh gangguan rangkaian dan sebab lain semasa replikasi induk-hamba Apabila nod hamba bersambung ke nod induk sekali lagi, jika keadaan membenarkan, nod induk akan menebus kehilangan tersebut. Hantar data yang hilang ke nod hamba. Oleh kerana data yang dikeluarkan semula adalah jauh lebih kecil daripada jumlah penuh data, ia boleh mengelakkan overhed penyalinan penuh yang berlebihan adalah pengoptimuman utama bagi versi lama penyalinan, dengan berkesan mengelakkan operasi penyalinan penuh yang tidak perlu

Sebab mengapa redis boleh menyokong salinan penuh dan salinan separa adalah terutamanya untuk mengoptimumkan perintah penyegerakan Selepas redis versi 2.8, arahan psync baharu digunakan Format arahan ialah: psync {runId} {offset}. Kedua-dua ini Maksud setiap parameter:

• runId: id nod induk yang berjalan

• offset: offset data yang disalin pada masa ini daripada nod hamba

Mungkin anda tidak biasa dengan runid dan offset di atas. Mari kita lihat tiga konsep berikut dahulu:

1. Salin offset

Nod induk dan hamba yang mengambil bahagian dalam replikasi masing-masing akan mengekalkan offset replikasi mereka sendiri: setiap kali pelayan induk menghantar N bait data ke pelayan hamba, ia menambah N kepada nilai offsetnya Setiap kali pelayan hamba menerima N bait data yang dihantar oleh pelayan induk, ia menambah N kepada nilai offsetnya sendiri. Dengan membandingkan offset replikasi pelayan master dan slave, anda boleh mengetahui sama ada data pelayan master dan slave adalah konsisten Jika offset pelayan master dan slave sentiasa sama, maka data master dan slave adalah konsisten. Sebaliknya, jika offset pelayan induk dan hamba adalah konsisten, Jika jumlah pemindahan tidak sama, ia bermakna pelayan induk dan hamba tidak berada dalam keadaan data yang konsisten Sebagai contoh, apabila terdapat beberapa pelayan hamba , pelayan tertentu menjadi luar talian semasa proses penghantaran, seperti yang ditunjukkan dalam rajah berikut:

Offset tidak konsisten

Semasa penghantaran data, pelayan hamba A adalah luar talian kerana sebab rangkaian, menyebabkan offset tidak konsisten dengan pelayan induk Kemudian apabila pelayan hamba A dimulakan semula dan sepadan Selepas pelayan induk berjaya disambungkan, hantar semula arahan psync ke pelayan induk replikasi data dilakukan sepenuhnya atau sebahagian? Jika replikasi separa dilakukan, bagaimanakah tuan boleh mengimbangi data yang hilang oleh hamba A semasa tempoh pemotongan?

2. Penimbal tunggakan replikasi

Penimbal tunggakan replikasi ialah baris gilir panjang tetap yang disimpan pada nod utama ialah 1MB disambungkan Nod hamba (hamba) dicipta Pada masa ini, apabila nod induk (master) bertindak balas kepada arahan tulis, ia bukan sahaja akan menghantar arahan ke nod hamba, tetapi juga menulisnya ke penimbal tunggakan replikasi, sebagai. ditunjukkan dalam rajah berikut:

Penimbal Replikasi Backlog

Oleh itu, penimbal tunggakan replikasi pelayan induk akan menyimpan sebahagian daripada arahan tulis yang disebarkan baru-baru ini , dan penimbal tunggakan replikasi akan menjadi Setiap bait merekodkan offset replikasi yang sepadan. Oleh itu, apabila pelayan hamba menyambung semula ke pelayan induk, pelayan hamba menghantar offset replikasinya ke pelayan induk melalui arahan psync Pelayan induk akan menggunakan ofset replikasi ini untuk memutuskan operasi penyegerakan data yang perlu dilakukan pada pelayan hamba:

• Jika data selepas replika mengimbangi pelayan hamba masih wujud dalam penimbal tunggakan replikasi, pelayan induk akan melakukan operasi salinan separa pada pelayan hamba

• 如果从服务器的复制偏移量之后的数据不存在于复制积压缓冲区里面，那么主服务器将对从服务器执行全量复制操作

3、服务器运行ID

每个 Redis 节点启动后都会动态分配一个 40 位的十六进制字符串作为运行 ID，运行 ID 的主要作用是用来唯一识别 Redis 节点，我们可以使用  info server 命令来查看

127.0.0.1:6379> info server # Server redis_version:5.0.5 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:2ef1d58592147923 redis_mode:standalone os:Linux 3.10.0-957.27.2.el7.x86_64 x86_64 arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:4.8.5 process_id:25214 run_id:7b987673dfb4dfc10dd8d65b9a198e239d20d2b1 tcp_port:6379 uptime_in_seconds:14382 uptime_in_days:0 hz:10 configured_hz:10 lru_clock:14554933 executable:/usr/local/redis-5.0.5/src/./redis-server config_file:/usr/local/redis-5.0.5/redis.conf 127.0.0.1:6379>

这里面有一个run_id 字段就是服务器运行的ID

在熟悉这几个概念之后，我们可以一起探讨 psync 命令的运行流程，具体如下图所示：

psync 运行流程

psync 命令的逻辑比较简单，整个流程分为两步：

1、从节点发送 psync 命令给主节点，参数 runId  是当前从节点保存的主节点运行ID，参数offset是当前从节点保存的复制偏移量，如果是第一次参与复制则默认值为 -1。

2、主节点接收到 psync 命令之后，会向从服务器返回以下三种回复中的一种：

• 回复 +FULLRESYNC {runId} {offset}：表示主服务器将与从服务器执行一次全量复制操作，其中 runid 是这个主服务器的运行  id，从服务器会保存这个id，在下一次发送 psync 命令时使用，而 offset  则是主服务器当前的复制偏移量，从服务器会将这个值作为自己的初始化偏移量

• 回复 +CONTINUE：那么表示主服务器与从服务器将执行部分复制操作，从服务器只要等着主服务器将自己缺少的那部分数据发送过来就可以了

• 回复 +ERR：那么表示主服务器的版本低于 redis 2.8，它识别不了 psync 命令，从服务器将向主服务器发送 sync  命令，并与主服务器执行全量复制

7、命令持续复制

当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。主从服务器之间的连接不会中断，因为主节点会持续发送写命令到从节点，以确保主从数据的一致性。

经过上面 7 步就完成了主从服务器之间的数据同步，由于这篇文章的篇幅比较长，关于全量复制和部分复制的细节就不介绍了，全量复制就是将主节点的当前的数据生产  RDB  文件，发送给从服务器，从服务器再从本地磁盘加载，这样当文件过大时就需要特别大的网络开销，不然由于数据传输比较慢会导致主从数据延时较大，部分复制就是主服务器将复制积压缓冲区的写命令直接发送给从服务器。

心跳检测

心跳检测是发生在主从节点在建立复制后，它们之间维护着长连接并彼此发送心跳命令，便以后续持续发送写命令，主从心跳检测如下图所示：

主从心跳检测

主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信，主从心跳检测的规则如下：

• 默认情况下，主节点会每隔 10 秒向从节点发送 ping 命令，以检测从节点的连接状态和是否存活。可通过修改 redis.conf 配置文件里面的  repl-ping-replica-period 参数来控制发送频率

• 从节点在主线程中每隔 1 秒发送 replconf ack {offset} 命令，给主节点  上报自身当前的复制偏移量，这条命令除了检测主从节点网络之外，还通过发送复制偏移量来保证主从的数据一致

主节点根据 replconf 命令判断从节点超时时间，体现在 info replication 统 计中的 lag 信息中，我们在主服务器上执行 info  replication 命令：

127.0.0.1:6379> info replication # Replication role:master connected_slaves:1 slave0:ip=127.0.0.1,port=6480,state=online,offset=25774,lag=0 master_replid:c62b6621e3acac55d122556a94f92d8679d93ea0 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:25774 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:25774 127.0.0.1:6379>

可以看出 slave0 字段的值最后面有一个 lag，lag 表示与从节点最后一次通信延迟的秒数，正常延迟应该在 0 和 1 之间。如果超过  repl-timeout 配置的值(默认60秒)，则判定从节点下线并断开复制客户端连接，如果从节点重新恢复，心跳检测会继续进行。

主从拓扑架构

Redis 的主从拓扑结构可以支持单层或多层复制关系，根据拓扑复杂性可以分为以下三种：一主一从、一主多从、树状主从架构。

一主一从结构

一主一从结构是最简单的复制拓扑结构，我们前面搭建的就是一主一从的架构，架构如图所示：

一主一从架构

Satu seni bina induk dan satu hamba

digunakan untuk menyediakan sokongan failover untuk nod hamba apabila nod induk turun Apabila konkurensi arahan tulis aplikasi adalah tinggi dan kegigihan diperlukan , ia hanya boleh mendayakan AOF pada nod hamba, yang bukan sahaja memastikan keselamatan data tetapi juga mengelakkan gangguan prestasi kegigihan pada nod induk. Tetapi terdapat lubang di sini yang memerlukan perhatian anda, iaitu, apabila nod induk mematikan fungsi kegigihan, elakkan mula semula automatik jika nod induk pergi ke luar talian. Oleh kerana nod induk tidak menghidupkan fungsi kegigihan sebelum ini, set data akan kosong selepas dimulakan semula secara automatik Pada masa ini, jika nod hamba terus menyalin nod induk, data nod hamba juga akan dikosongkan, dan maksudnya. kegigihan akan hilang. Pendekatan selamat adalah untuk melaksanakan slaveof no one pada nod hamba untuk memutuskan hubungan replikasi dengan nod induk, dan kemudian mulakan semula nod induk untuk mengelakkan masalah ini.

Seni bina satu tuan dan berbilang hamba Satu seni bina tuan dan berbilang hamba juga dipanggil topologi bintang Satu seni bina tuan dan berbilang hamba ditunjukkan dalam rajah di bawah:

<.> Satu seni bina master-ulti-hamba

seni bina satu-musas-hamba dapat merealisasikan pemisahan dan menulis untuk mengurangkan tekanan pada pelayan induk. arahan boleh dihantar ke nod hamba untuk berkongsi tekanan pada nod induk. Pada masa yang sama, jika anda perlu melaksanakan beberapa arahan baca yang memakan masa semasa pembangunan harian, seperti kekunci, isihan, dll., anda boleh melaksanakannya pada salah satu nod hamba untuk mengelakkan pertanyaan perlahan daripada menyekat nod induk dan menjejaskan kestabilan perkhidmatan dalam talian. Untuk senario dengan konkurensi tulis tinggi, berbilang nod hamba akan menyebabkan nod induk menghantar arahan tulis berbilang kali, menggunakan lebar jalur rangkaian secara berlebihan, dan juga meningkatkan beban pada nod induk dan menjejaskan kestabilan perkhidmatan.

Seni bina tuan-hamba pokok

Seni bina tuan-hamba pokok juga dipanggil seni bina topologi pokok Seni bina tuan-hamba pokok ditunjukkan dalam rajah di bawah:

Seni bina tuan-hamba seperti pokok

Seni bina tuan-hamba seperti pokok membolehkan nod hamba bukan sahaja menyalin data bahagian induk, tetapi juga berkhidmat sebagai nod induk nod hamba yang lain untuk terus menyalin ke peringkat yang lebih rendah. Ia menyelesaikan kekurangan seni bina satu induk-berbilang hamba dan memperkenalkan lapisan perantaraan replikasi, yang boleh mengurangkan beban nod induk dan jumlah data yang perlu dihantar ke nod hamba dengan berkesan. Seperti yang ditunjukkan dalam rajah seni bina, selepas data ditulis ke nod A, ia akan disegerakkan ke nod B dan C. Nod B kemudian menyegerakkan data ke nod D dan E. Data direplikasi lapisan demi lapisan. Untuk mengelakkan gangguan terhadap prestasi nod induk, nod induk boleh mengguna pakai struktur induk-hamba pokok apabila ia perlu memasang berbilang nod hamba untuk mengurangkan tekanan bebannya.

Atas ialah kandungan terperinci Apakah cara untuk mewujudkan seni bina tuan-hamba Redis?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!