Pemahaman mendalam tentang prinsip penyegerakan ketekalan data seni bina tuan-hamba dalam Redis

Artikel ini akan memperkenalkan kepada anda prinsip penyegerakan ketekalan data dalam seni bina tuan-hamba di Redis. Saya harap ia akan membantu anda!

Ketersediaan tinggi mempunyai dua makna: satu adalah untuk mengelakkan kehilangan data sebanyak mungkin, dan satu lagi adalah untuk menyediakan perkhidmatan sebanyak mungkin. AOF dan RDB memastikan kegigihan data tidak hilang sebanyak mungkin, manakala replikasi tuan-hamba adalah untuk menambah salinan dan menyimpan satu data kepada berbilang kejadian. Walaupun satu kejadian menurun, kejadian lain masih boleh menyediakan perkhidmatan.

Artikel ini memberi anda pemahaman menyeluruh tentang Seni bina replikasi tuan-hamba, salah satu daripada penyelesaian teknologi ketersediaan tinggi Redis.

Artikel ini adalah tegar Adalah disyorkan untuk mengumpulnya dan menikmatinya secara perlahan-lahan. Jika ada salah silap mohon diperbetulkan, terima kasih. Ikuti "Ma Ge Byte" dan tetapkan "bintang" untuk menerima artikel berkualiti tinggi secepat mungkin. Terima kasih pembaca atas sokongan anda.

Mata pengetahuan teras

Mesej pembukaan

Masalah = peluang. Apabila anda menghadapi masalah, anda sebenarnya gembira di dalam masalah yang lebih besar bermakna lebih besar peluang.

Semua ada harga, setiap untung mesti rugi, dan setiap kerugian mesti untung, jadi kita tak perlu risau tentang banyak perkara kita cuma perlu fikir apa yang kita nak buat dan apa yang kami sanggup bayar untuknya. Bayar harganya, dan kemudian teruskan dan lakukannya!

1. Gambaran keseluruhan replikasi tuan-hamba

65 Abang: Dengan RDB dan AOF, anda tidak lagi takut kehilangan data akibat masa henti, tetapi bagaimana untuk mencapai prestasi tinggi apabila instance Redis terputus?

Memandangkan satu mesin rosak dan tidak dapat menyediakan perkhidmatan, bagaimana pula dengan mesin yang lain? Bolehkah ia diselesaikan? Redis menyediakan mod tuan-hamba, yang menyalin salinan data yang berlebihan ke pelayan Redis lain melalui replikasi tuan-hamba.

Yang pertama dipanggil nod induk (master), dan yang kedua dipanggil nod hamba (replikasi data adalah sehala, dan hanya boleh dari nod induk ke nod hamba.

Secara lalai, setiap pelayan Redis ialah nod induk; dan nod induk boleh mempunyai berbilang nod hamba (atau tiada nod hamba), tetapi nod hamba hanya boleh mempunyai satu nod induk.

65 Abang: Bagaimana untuk memastikan ketekalan data antara tuan dan hamba?

Untuk memastikan ketekalan data replika, seni bina tuan-hamba menggunakan kaedah pemisahan baca-tulis.

• Kendalian baca: boleh dilaksanakan oleh kedua-dua perpustakaan induk dan hamba;

65 Abang: Kenapa kita perlu mengasingkan membaca dan menulis?

Kita boleh mengandaikan bahawa kedua-dua perpustakaan induk dan hamba boleh melaksanakan arahan tulis Jika data yang sama diubah suai beberapa kali, setiap pengubahsuaian dihantar ke contoh induk-hamba yang berbeza, menghasilkan satu salinan. instance. Data tidak konsisten.

Jika untuk memastikan ketekalan data, Redis perlu mengunci dan menyelaraskan pengubahsuaian berbilang kejadian, Redis secara semula jadi tidak akan melakukan ini!

65 Abang: Adakah replikasi tuan-hamba mempunyai fungsi lain?

Pemulihan kegagalan: apabila nod induk turun, nod lain masih boleh menyediakan perkhidmatan

1. Pengimbangan beban: nod Induk menyediakan perkhidmatan tulis, dan nod Hamba menyediakan; baca perkhidmatan untuk berkongsi tekanan ;
2. Asas ketersediaan tinggi: Ia adalah asas untuk pelaksanaan sentinel dan kelompok, dan asas ketersediaan tinggi.
3. 2. Sediakan replikasi tuan-hamba

Pengaktifan replikasi tuan-hamba dimulakan sepenuhnya daripada nod hamba dan tidak memerlukan kami melakukan apa-apa pada nod induk.

65 Abang: Bagaimana untuk membina seni bina replikasi tuan-hamba?

Hubungan antara pangkalan data induk dan pangkalan data hamba boleh dibentuk melalui perintah replika (slaveof digunakan sebelum Redis 5.0).

Dayakan replikasi induk-hamba pada nod hamba Terdapat tiga cara:

Fail konfigurasi

• Tambahkan

  pada fail konfigurasi. pelayan hamba

  replicaof <masterip> <masterport></masterport></masterip>

Perintah Mula

• perintah Mulakan pelayan-redis diikuti dengan menambah

  --replicaof <masterip> <masterport></masterport></masterip>

Perintah klien

• Selepas memulakan berbilang kejadian Redis, laksanakan arahan terus melalui klien:

  , kemudian tika Redis menjadi nod hamba.

  replicaof <masterip> <masterport></masterport></masterip>

Sebagai contoh, andaikan terdapat contoh 1 (172.16.88.1), contoh 2 (172.16.88.2) dan contoh 3 (172.16.88.3), laksanakan perkara berikut pada contoh 2 dan contoh 3 masing-masing, contoh 2 dan contoh 3 menjadi perpustakaan hamba contoh 1, dan contoh 1 menjadi induk.

3. Prinsip replikasi Master-slave

replicaof 172.16.88.1 6379复制代码

Setelah mod perpustakaan induk-hamba menggunakan pengasingan baca dan tulis, semua operasi penulisan data hanya akan dilakukan pada perpustakaan induk, tanpa menyelaraskan tiga contoh.

Selepas pangkalan data induk mempunyai data terkini, ia akan disegerakkan ke pangkalan data hamba, supaya data dalam pangkalan data induk dan hamba adalah konsisten.

65 Abang: Bagaimanakah penyegerakan pangkalan data tuan-hamba selesai? Adakah data pangkalan data induk dihantar ke pangkalan data hamba sekali gus, atau adakah ia disegerakkan dalam kelompok? Bagaimana untuk menyegerakkan semasa operasi biasa? Jika rangkaian antara pangkalan data induk dan hamba terputus sambungan, adakah data akan kekal konsisten selepas penyambungan semula?

65 Saudara, anda mempunyai begitu banyak soalan Penyegerakan dibahagikan kepada tiga situasi:

1. Salinan penuh pertama perpustakaan tuan-hamba; >Penyegerakan Induk-hamba semasa operasi biasa;
2. Pemutus rangkaian dan penyegerakan penyambungan semula antara perpustakaan induk dan hamba.
3. Salinan penuh pertama pangkalan data tuan-hamba

65 Abang: Saya sangat pening. Mari kita mulakan dengan penyegerakan pertama antara pangkalan data tuan-hamba.

Proses salinan pertama perpustakaan tuan-hamba boleh dibahagikan secara kasar kepada tiga peringkat: peringkat penubuhan sambungan (iaitu peringkat penyediaan), peringkat penyegerakan data daripada perpustakaan induk ke perpustakaan hamba, dan menghantar data baharu semasa penyegerakan menulis arahan ke peringkat perpustakaan hamba

; diperkenalkan secara terperinci kemudian.

Mewujudkan sambungan

Fungsi utama peringkat ini adalah untuk mewujudkan sambungan antara nod induk dan hamba untuk menyediakan penyegerakan data penuh.

Pustaka hamba akan mewujudkan sambungan dengan perpustakaan induk Perpustakaan hamba akan melaksanakan replika dan menghantar arahan pync dan memberitahu pustaka induk bahawa penyegerakan akan berlaku Selepas perpustakaan induk mengesahkan balasan, penyegerakan antara perpustakaan tuan dan hamba akan bermula

.

65 Abang: Bagaimanakah pangkalan data hamba mengetahui maklumat pangkalan data induk dan mewujudkan sambungan?

Selepas mengkonfigurasi IP dan port nod induk dalam item konfigurasi replika dalam fail konfigurasi nod hamba, nod hamba akan mengetahui nod induk yang ingin disambungkan.

Nod hamba mengekalkan dua medan, masterhost dan masterport, yang digunakan untuk menyimpan maklumat IP dan port nod induk.

Pustaka hamba melaksanakan

dan menghantar perintah

, menunjukkan bahawa penyegerakan data akan dilakukan Selepas menerima arahan, pustaka induk memulakan replikasi mengikut parameter. Perintah itu mengandungi dua parameter:

runID

pustaka utama dan replicaofmenyalin progres offsetpsync. runID

: Setiap tika Redis akan menjana ID pengenalan unik secara automatik apabila ia dimulakan Untuk replikasi master-slave yang pertama, runID pangkalan data utama belum diketahui dan parameter ditetapkan kepada "?"

• offset: Salinan pertama ditetapkan kepada -1, menunjukkan salinan pertama, merekodkan kemajuan salinan mengimbangi.
• Selepas pustaka utama menerima arahan psync, ia akan menggunakan perintah respons FULLRESYNC dengan dua parameter: runID perpustakaan utama dan mengimbangi kemajuan salinan semasa perpustakaan utama, dan mengembalikannya ke perpustakaan hamba
. Selepas menerima maklum balas daripada perpustakaan, kedua-dua parameter ini akan direkodkan.

Respons FULLRESYNC menunjukkan salinan penuh diterima pakai untuk replikasi pertama, iaitu pangkalan data induk akan menyalin semua data semasa ke pangkalan data hamba.

Pustaka induk menyegerakkan data ke pustaka hambaFasa kedua

master melaksanakan perintah

untuk menjana fail RDB dan menghantar fail ke pustaka hamba , dan pada masa yang sama

Pustaka utama

membuka penimbal replikasi untuk setiap hamba untuk merekodkan semua arahan tulis yang diterima sejak fail RDB dijana.

bgsaveSelepas menerima fail RDB daripada pustaka, simpannya ke cakera, kosongkan data pangkalan data semasa, dan kemudian muatkan data fail RDB ke dalam memori. Hantar arahan tulis baharu ke pustaka hamba

Fasa ketiga

Selepas nod hamba memuatkan RDB, nod induk menghantar data dalam penimbal replikasi ke nod hamba, Terima dan laksanakan, dan nod hamba menyegerak ke keadaan yang sama dengan nod induk.

65 Abang: Apabila pangkalan data induk sedang menyegerakkan data ke pangkalan data hamba, bolehkah permintaan itu diterima secara normal?

Pangkalan data utama tidak akan disekat Sebagai seorang lelaki yang hanya pantas dan tidak boleh dipecahkan, bagaimana Redis boleh disekat pada setiap masa.

Operasi tulis selepas menjana fail RDB tidak direkodkan dalam fail RDB sebentar tadi Bagi memastikan ketekalan data pangkalan data induk-hamba, pangkalan data induk akan menggunakan penimbal replikasi dalam memori untuk. merekodkan penjanaan fail RDB semua operasi tulis seterusnya.

65 Abang: Mengapa kita perlu mengosongkan pangkalan data semasa selepas menerima fail RDB daripada perpustakaan?

Oleh kerana perpustakaan hamba mungkin menyimpan data lain sebelum mula menyegerakkan dengan perpustakaan induk melalui perintah

, untuk mengelakkan pengaruh antara data tuan dan hamba.

Apakah sebenarnya penimbal replikasi? replcaof

Penimbal yang dibuat pada bahagian induk Data yang disimpan ialah semua operasi penulisan data induk dalam tiga tempoh berikut.

1) Operasi tulis apabila master melaksanakan bgsave untuk menjana RDB; rdb Operasi tulis fail semasa data dipulihkan ke ingatan.

Sama ada Redis berkomunikasi dengan pelanggan atau berkomunikasi dengan perpustakaan hamba, Redis memperuntukkan penimbal memori untuk interaksi data Pelanggan adalah pelanggan, dan perpustakaan hamba juga merupakan pelanggan kami Redis Akhir sekali, Redis akan memperuntukkan penimbal pelanggan khusus, dan semua interaksi data dijalankan melalui penimbal ini.

Tuan mula-mula menulis data ke penimbal ini, dan kemudian menghantarnya keluar melalui rangkaian, sekali gus melengkapkan interaksi data.

不管是主从在增量同步还是全量同步时，master 会为其分配一个 buffer ，只不过这个 buffer 专门用来传播写命令到从库，保证主从数据一致，我们通常把它叫做 replication buffer。

replication buffer 太小会引发的问题：

replication buffer 由 client-output-buffer-limit slave 设置，当这个值太小会导致主从复制连接断开。

1）当 master-slave 复制连接断开，master 会释放连接相关的数据。replication buffer 中的数据也就丢失了，此时主从之间重新开始复制过程。

2）还有个更严重的问题，主从复制连接断开，导致主从上出现重新执行 bgsave 和 rdb 重传操作无限循环。

当主节点数据量较大，或者主从节点之间网络延迟较大时，可能导致该缓冲区的大小超过了限制，此时主节点会断开与从节点之间的连接；

这种情况可能引起全量复制 -> replication buffer 溢出导致连接中断 -> 重连 -> 全量复制 -> replication buffer 缓冲区溢出导致连接中断……的循环。

具体详情：[top redis headaches for devops – replication buffer] 因而推荐把 replication buffer 的 hard/soft limit 设置成 512M。

config set client-output-buffer-limit "slave 536870912 536870912 0"复制代码

65 哥：主从库复制为何不使用 AOF 呢？相比 RDB 来说，丢失的数据更少。

这个问题问的好，原因如下：

• RDB 文件是二进制文件，网络传输 RDB 和写入磁盘的 IO 效率都要比 AOF 高。

• 从库进行数据恢复的时候，RDB 的恢复效率也要高于 AOF。

增量复制

65 哥：主从库间的网络断了咋办？断开后要重新全量复制么？

在 Redis 2.8 之前，如果主从库在命令传播时出现了网络闪断，那么，从库就会和主库重新进行一次全量复制，开销非常大。

从 Redis 2.8 开始，网络断了之后，主从库会采用增量复制的方式继续同步。

增量复制：用于网络中断等情况后的复制，只将中断期间主节点执行的写命令发送给从节点，与全量复制相比更加高效。

repl_backlog_buffer

断开重连增量复制的实现奥秘就是 repl_backlog_buffer 缓冲区，不管在什么时候 master 都会将写指令操作记录在 repl_backlog_buffer 中，因为内存有限， repl_backlog_buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。

master 使用 master_repl_offset记录自己写到的位置偏移量，slave 则使用 slave_repl_offset记录已经读取到的偏移量。

master 收到写操作，偏移量则会增加。从库持续执行同步的写指令后，在 repl_backlog_buffer 的已复制的偏移量 slave_repl_offset 也在不断增加。

正常情况下，这两个偏移量基本相等。在网络断连阶段，主库可能会收到新的写操作命令，所以 master_repl_offset会大于 slave_repl_offset。

当主从断开重连后，slave 会先发送 psync 命令给 master，同时将自己的 runID，slave_repl_offset发送给 master。

master 只需要把 master_repl_offset与 slave_repl_offset之间的命令同步给从库即可。

增量复制执行流程如下图：

65 哥：repl_backlog_buffer 太小的话从库还没读取到就被 Master 的新写操作覆盖了咋办？

我们要想办法避免这个情况，一旦被覆盖就会执行全量复制。我们可以调整 repl_backlog_size 这个参数用于控制缓冲区大小。计算公式：

repl_backlog_buffer = second * write_size_per_second复制代码

• second：从服务器断开重连主服务器所需的平均时间；

• write_size_per_second：master 平均每秒产生的命令数据量大小（写命令和数据大小总和）；

例如，如果主服务器平均每秒产生 1 MB 的写数据，而从服务器断线之后平均要 5 秒才能重新连接上主服务器，那么复制积压缓冲区的大小就不能低于 5 MB。

为了安全起见，可以将复制积压缓冲区的大小设为2 * second * write_size_per_second，这样可以保证绝大部分断线情况都能用部分重同步来处理。

基于长连接的命令传播

65 哥：完成全量同步后，正常运行过程如何同步呢？

当主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为基于长连接的命令传播，使用长连接的目的就是避免频繁建立连接导致的开销。

在命令传播阶段，除了发送写命令，主从节点还维持着心跳机制：PING 和 REPLCONF ACK。

主->从：PING

每隔指定的时间，主节点会向从节点发送 PING 命令，这个 PING 命令的作用，主要是为了让从节点进行超时判断。

从->主：REPLCONF ACK

在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令：

REPLCONF ACK <replication_offset>复制代码</replication_offset>

其中 replication_offset 是从服务器当前的复制偏移量。发送 REPLCONF ACK 命令对于主从服务器有三个作用：

• 检测主从服务器的网络连接状态。

• 辅助实现 min-slaves 选项。

• 检测命令丢失, 从节点发送了自身的 slave_replication_offset，主节点会用自己的 master_replication_offset 对比，如果从节点数据缺失，主节点会从 repl_backlog_buffer缓冲区中找到并推送缺失的数据。注意，offset 和 repl_backlog_buffer 缓冲区，不仅可以用于部分复制，也可以用于处理命令丢失等情形；区别在于前者是在断线重连后进行的，而后者是在主从节点没有断线的情况下进行的。

如何确定执行全量同步还是部分同步？

在 Redis 2.8 及以后，从节点可以发送 psync 命令请求同步数据，此时根据主从节点当前状态的不同，同步方式可能是全量复制或部分复制。本文以 Redis 2.8 及之后的版本为例。

关键就是 psync的执行：

• 从节点根据当前状态，发送 psync命令给 master：

  • 如果从节点从未执行过 replicaof ，则从节点发送 psync ? -1，向主节点发送全量复制请求；
  • 如果从节点之前执行过 replicaof 则发送 psync <runid> <offset></offset></runid>, runID 是上次复制保存的主节点 runID，offset 是上次复制截至时从节点保存的复制偏移量。

• 主节点根据接受到的psync命令和当前服务器状态，决定执行全量复制还是部分复制：

  • runID 与从节点发送的 runID 相同，且从节点发送的 slave_repl_offset 之后的数据在 repl_backlog_buffer 缓冲区中都存在，则回复 CONTINUE，表示将进行部分复制，从节点等待主节点发送其缺少的数据即可；
  • runID 与从节点发送的 runID 不同，或者从节点发送的 slave_repl_offset 之后的数据已不在主节点的 repl_backlog_buffer 缓冲区中 (在队列中被挤出了)，则回复从节点 FULLRESYNC <runid> <offset></offset></runid>，表示要进行全量复制，其中 runID 表示主节点当前的 runID，offset 表示主节点当前的 offset，从节点保存这两个值，以备使用。

一个从库如果和主库断连时间过长，造成它在主库 repl_backlog_buffer 的 slave_repl_offset 位置上的数据已经被覆盖掉了，此时从库和主库间将进行全量复制。

总结下

每个从库会记录自己的 slave_repl_offset，每个从库的复制进度也不一定相同。

在和主库重连进行恢复时，从库会通过 psync 命令把自己记录的 slave_repl_offset 发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制。

replication buffer 和 repl_backlog

• penimbal replikasi sepadan dengan setiap hamba dan ditetapkan oleh config set client-output-buffer-limit slave .

• repl_backlog_buffer ialah penimbal cincin hanya akan ada dalam keseluruhan proses induk dan ia adalah perkara biasa kepada semua hamba. Saiz repl_backlog ditetapkan oleh parameter repl-backlog-size Saiz lalai ialah 1M Saiz boleh dikira berdasarkan jumlah arahan yang dihasilkan sesaat, (master melaksanakan rdb bgsave) (master menghantar rdb kepada slave). (fail rdb beban hamba) masa Anggarkan saiz penimbal tunggakan, nilai saiz repl-backlog tidak kurang daripada hasil kedua-dua ini.

Secara amnya, replication buffer ialah penimbal pada pustaka induk untuk pelanggan menyambung ke pustaka hamba apabila pustaka induk-hamba sedang melakukan replikasi penuh dan repl_backlog_buffer adalah Untuk menyokong replikasi tambahan daripada perpustakaan hamba, penimbal khusus digunakan untuk menyimpan operasi tulis secara berterusan pada perpustakaan induk.

repl_backlog_buffer ialah penimbal khusus Selepas pelayan Redis dimulakan, ia mula menerima arahan operasi tulis Ini dikongsi oleh semua perpustakaan hamba. Pustaka induk dan perpustakaan hamba masing-masing akan merekodkan kemajuan replikasi mereka sendiri Oleh itu, apabila perpustakaan hamba yang berbeza pulih, mereka akan menghantar kemajuan replikasi mereka sendiri (slave_repl_offset) ke perpustakaan induk, dan perpustakaan induk boleh menyegerakkan dengannya secara bebas. .

Seperti yang ditunjukkan dalam rajah:

4. Isu aplikasi Master-slave

4.1 Isu pemisahan baca-tulis

Isu tamat tempoh data

65 Abang: Dalam senario replikasi tuan-hamba, adakah nod hamba akan memadamkan data yang telah tamat tempoh?

Ini adalah soalan yang bagus demi ketekalan data antara nod induk dan hamba, nod hamba tidak akan memadamkan data secara aktif. Kami tahu bahawa Redis mempunyai dua strategi pemadaman:

• Pemadaman malas: Apabila pelanggan menanyakan data yang sepadan, Redis menentukan sama ada data itu telah tamat tempoh dan memadamkannya jika ia tamat tempoh.

• Pemadaman biasa: Redis memadamkan data tamat tempoh melalui tugasan yang dijadualkan.

65 Abang: Adakah pelanggan akan membaca data tamat tempoh dengan membaca data daripada nod hamba?

Bermula dari Redis 3.2, apabila membaca data daripada nod, mula-mula tentukan sama ada data telah tamat tempoh. Jika ia tamat tempoh, ia tidak akan dikembalikan kepada pelanggan dan data akan dipadamkan.

4.2 Had saiz memori mesin tunggal

Jika memori mesin tunggal Redis mencapai 10GB, masa penyegerakan nod hamba akan menjadi beberapa minit jika terdapat lebih banyak nod hamba, pemulihan kelajuan akan menjadi lebih perlahan. Jika beban baca sistem sangat tinggi dan nod hamba tidak dapat menyediakan perkhidmatan dalam tempoh ini, ia akan memberi banyak tekanan kepada sistem.

Jika jumlah data terlalu besar, nod induk mengambil masa terlalu lama untuk menyimpan fail RDB semasa fasa replikasi penuh Nod hamba tidak boleh menerima data untuk masa yang lama dan mencetuskan a tamat masa. Penyegerakan data nod induk dan hamba juga boleh jatuh ke dalam volum penuh Salin->Tamat masa menyebabkan gangguan replikasi->Sambungan semula->Salinan penuh->Tamat masa menyebabkan gangguan replikasi. kitaran.

Selain itu, sebagai tambahan kepada jumlah mutlak memori mesin tunggal nod induk, perkadaran memori hos yang didudukinya tidak boleh terlalu besar: sebaiknya hanya menggunakan 50% - 65% daripada memori, meninggalkan 30% - 45% Memori digunakan untuk melaksanakan perintah bgsave dan mencipta penimbal salinan, dsb.

Ringkasan

• Peranan replikasi tuan-hamba: fail binari AOF dan RDB memastikan pemulihan data yang cepat sekiranya berlaku gangguan dan menghalang kehilangan data sebanyak mungkin . Walau bagaimanapun, perkhidmatan masih tidak dapat disediakan selepas masa henti, jadi seni bina tuan-hamba dan pemisahan baca-tulis berkembang.

• Prinsip replikasi tuan-hamba: fasa penubuhan sambungan, fasa penyegerakan data, fasa penyegerakan data terbahagi kepada replikasi penuh dan replikasi separa, di sana ialah Perintah PING dan REPLCONF ACK melakukan pengesanan degupan jantung antara satu sama lain.

• Walaupun replikasi tuan-hamba menyelesaikan atau mengurangkan masalah seperti redundansi data, pemulihan kegagalan dan pengimbangan beban baca, kelemahannya masih jelas: Pemulihan kegagalan tidak boleh diautomasikan; operasi Pengimbangan beban tidak boleh dicapai; kapasiti penyimpanan dihadkan oleh satu mesin;

Alamat asal: https://juejin.cn/post/6973928120332058654

Pengarang: Code Brother Byte

Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila layari:

Video Pengaturcaraan! !

Atas ialah kandungan terperinci Pemahaman mendalam tentang prinsip penyegerakan ketekalan data seni bina tuan-hamba dalam Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!