Pemahaman mendalam tentang mekanisme penyegerakan tuan-hamba dalam Redis

Artikel ini akan membawa anda memahami penyegerakan tuan-hamba dalam Redis Ia akan memperkenalkan dua model struktur tuan-hamba Redis, penubuhan hubungan tuan-hamba, replikasi tuan-hamba. strategi, dsb. Saya harap ia akan berguna kepada semua orang.

Ciri-ciri dan prinsip teras redis telah dianalisis secara terperinci dalam artikel sebelumnya Bermula daripada artikel ini, struktur penggunaan dan mod operasi redis akan dianalisis dan ditafsirkan. Dalam persekitaran pengeluaran sebenar, kami pada asasnya tidak akan menggunakan redis nod tunggal untuk menyediakan perkhidmatan, sekurang-kurangnya mod sentinel atau kluster struktur tuan-hamba untuk memastikan kebolehpercayaan perkhidmatan redis. Artikel ini akan menerangkan secara terperinci mekanisme penyegerakan tuan-hamba redis. [Cadangan berkaitan: Tutorial video Redis]

1 Terdapat dua model struktur tuan dan hamba Redis:

1.1 Replikasi induk-hamba

Struktur replikasi satu induk dan hamba N hanya mempunyai satu tahap perhubungan replikasi, yang juga merupakan bentuk yang paling biasa digunakan Biasanya redis yang membina struktur sentri atau kelompok menggunakan struktur replikasi ini , yang boleh dilalui melalui Hubungan replikasi antara nod tahap-hamba memastikan ketersediaan perkhidmatan dan membolehkan penukaran tuan-hamba dalam keadaan tidak normal.

1.2 Replikasi Lata

Hubungan replikasi struktur replikasi lata boleh mempunyai berbilang peringkat, dan nod hamba nod induk boleh menjadi nod induk nod hamba bawahan. Penggunaan struktur replikasi lata adalah agak jarang struktur ini boleh mengurangkan tekanan replikasi nod induk pada tahap tertentu dalam struktur dengan berbilang nod hamba.

2. Penubuhan hubungan tuan-hamba Redis

Penyegerakan tuan-hamba Redis bermula dengan arahan SLAVEOF port hos Melalui arahan ini, perintah SLAVEOF digunakan untuk menjalankan secara dinamik Redis Ubah suai tingkah laku fungsi salin. Dengan melaksanakan arahan port hos SLAVEOF, anda boleh menukar pelayan semasa menjadi pelayan hamba pelayan yang ditentukan. Jika pelayan semasa sudah menjadi pelayan hamba pelayan induk, melaksanakan port hos SLAVEOF akan menyebabkan pelayan semasa berhenti menyegerak dengan pelayan induk lama, membuang set data lama dan mula menyegerak dengan pelayan induk baharu. Selain itu, melaksanakan perintah SLAVEOF NO ONE pada pelayan hamba akan menyebabkan pelayan hamba mematikan fungsi replikasi dan peralihan dari pelayan hamba kembali ke pelayan induk Set data yang disegerakkan asal tidak akan dibuang. Mengambil kesempatan daripada ciri SLAVEOF NO ONE bahawa set data yang disegerakkan tidak akan dibuang, tanpa menyediakan sentinel dan kelompok, apabila pelayan induk gagal, pelayan hamba boleh digunakan sebagai pelayan induk baharu, dengan itu mencapai operasi tanpa gangguan.

Rajah berikut menunjukkan proses penubuhan hubungan tuan-hamba:

Nota:

Menurut proses pelaksanaan di atas, terdapat satu perkara yang perlu diperhatikan apabila kita melaksanakan perintah slaveof pada nod yang sudah mempunyai hubungan master-slave, hubungan master-slave yang sedia ada akan ditamatkan dan semua data di bawah nod. akan dibersihkan Dalam persekitaran pengeluaran, ini adalah operasi yang agak mengancam. Adakah terdapat cara yang lebih selamat? Apabila memperkenalkan arahan slaveof di atas, kami menyebut bahawa anda boleh lulus parameter NO ONE, iaitu, laksanakan arahan SLAVEOF NO ONE Perintah ini hanya akan menamatkan hubungan replikasi master-slave dan tidak akan mengosongkan data, yang secara relatifnya lebih selamat .

3. Penyegerakan data

Selepas mewujudkan hubungan tuan-hamba, tiba masanya untuk memasuki proses penyegerakan data tuan-hamba. Terdapat terutamanya tiga situasi di sini -perhubungan hamba baru sahaja diwujudkan disegerakkan sepenuhnya ;Peringkat penyebaran perintah selepas penyegerakan awal selesai;

3.1 Penyegerakan penuh

• Apabila nod hamba dimulakan atau diputuskan sambungan dan disambung semula (penyambungan semula tidak memenuhi syarat penyegerakan tambahan), arahan SYNC akan dihantar ke pangkalan data induk.

• Selepas menerima arahan SYNC, nod induk akan mula menyimpan syot kilat di latar belakang (iaitu kegigihan RDB, semasa replikasi induk-hamba, RDB akan dicetuskan tanpa syarat), dan akan menerima the The commands are cached.

• Selepas nod induk melengkapkan kegigihan RDB, ia menghantar fail RDB syot kilat ke semua nod hamba dan terus merekodkan arahan tulis yang dilaksanakan semasa menghantar syot kilat.

• Selepas menerima fail syot kilat, nod hamba membuang semua data lama (semua data akan dikosongkan) dan memuatkan syot kilat yang diterima.

• Selepas syot kilat nod induk dihantar dan nod hamba memuatkan syot kilat, nod induk mula menghantar arahan tulis dalam penimbal ke nod hamba.

• Nod hamba melengkapkan memuatkan syot kilat, mula menerima permintaan arahan dan melaksanakan arahan tulis daripada penimbal pangkalan data utama. (Permulaan selesai daripada pangkalan data)

• Setiap kali nod induk melaksanakan arahan tulis, ia akan menghantar arahan tulis yang sama kepada nod hamba, dan nod hamba menerima dan melaksanakan arahan tulis yang diterima. (Operasi penyebaran perintah, operasi selepas permulaan nod hamba selesai)

Proses penyegerakan penuh adalah seperti berikut:

dalam redis2 .8 Sebelum ini, nod hamba menggunakan penyegerakan penuh sama ada ia dimulakan atau diputuskan dan disambungkan semula Dalam versi selepas 2.8, arahan PSYNC telah diperkenalkan untuk menentukan sama ada untuk menggunakan penyegerakan tambahan selepas nod hamba diputuskan dan disambungkan semula.

3.2 Penyegerakan tambahan

PSYNC mempunyai penyegerakan semula data penuh dan mod penyegerakan tambahan.

• Penyegerakan semula penuh: Ia pada asasnya sama dengan versi replikasi lama, dan boleh difahami sebagai replikasi "penuh".

• Penyegerakan semula separa: Apabila hamba diputuskan sambungan dan disambungkan semula, dalam fasa penyebaran perintah, anda hanya perlu menghantar arahan yang dilaksanakan semasa tempoh pemutusan sambungan daripada tuan kepada hamba itu boleh difahami.

Terdapat tiga konsep penting semasa pelaksanaan PSYNC: runid, offset (copy offset) dan copy backlog buffer.

1.runid

Setiap pelayan Redis akan mempunyai ID yang menunjukkan identitinya. ID yang dihantar dalam PSYNC merujuk kepada ID Master yang disambungkan sebelum ini Jika ID ini tidak disimpan, arahan PSYNC akan menggunakan borang "PSYNC? -1" untuk menghantarnya kepada Master, menunjukkan bahawa salinan penuh diperlukan.

2.offset (replikasi offset)

Kedua-dua Tuan dan Hamba dalam replikasi tuan-hamba masing-masing akan mengekalkan offset. Selepas Master berjaya menghantar arahan N-bait, ofset dalam Master akan ditambah dengan N. Selepas Slave menerima arahan N-bait, Slave juga akan meningkatkan offset dalam Slave dengan N. Sekiranya status Tuan dan Hamba adalah konsisten, pengimbangan mereka juga harus konsisten.

3. Salin penimbal tunggakan

Penimbal tunggakan salinan ialah baris gilir tunggakan bulat panjang (FIFO baris gilir) yang diselenggarakan oleh Master Sebarkan arahan. Apabila Guru menyebarkan arahan, ia bukan sahaja menghantar arahan kepada semua Hamba, tetapi juga menulis arahan ke dalam penimbal tunggakan replikasi. Perbezaan antara proses pelaksanaan PSYNC dan SYNC ialah apabila salve disambungkan, ia dinilai sama ada penyegerakan penuh diperlukan Proses logik penyegerakan penuh adalah sama seperti SYNC. Langkah-langkah pelaksanaan PSYNC adalah seperti berikut:

• Pelanggan menghantar arahan SLAVEOF ke pelayan, iaitu, apabila hamba memulakan permintaan sambungan kepada tuan, hamba menentukan sama ada ia ialah sambungan pertama berdasarkan sama ada ia menyimpan runid Master.

• Jika ia adalah penyegerakan pertama, arahan PSYNC ? -1 akan dihantar kepada Master untuk penyegerakan lengkap, jika ia adalah penyambungan semula, perintah PSYNC runid offset akan dihantar ke Master (runid ialah ID Identiti tuan, offset ialah jumlah migrasi global perintah penyegerakan nod hamba).

• Selepas menerima arahan PSYNC, Master terlebih dahulu menentukan sama ada runid itu konsisten dengan id mesin tempatan Jika ia konsisten, ia akan menentukan semula sama ada offset offset berbeza daripada mengimbangi mesin tempatan Saiz penimbal tunggakan replikasi jika tidak, TERUS dihantar kepada Hamba Pada masa ini, Hamba hanya perlu menunggu untuk Master mengembalikan arahan yang hilang semasa kehilangan sambungan. Jika runid tidak konsisten dengan ID setempat atau jurang offset melebihi saiz penimbal tunggakan salinan, maka offset runid FULLRESYNC akan dikembalikan dan hamba akan menyimpan runid dan melakukan penyegerakan penuh.

Apabila nod induk menyebarkan arahan, pangkalan data induk akan menghantar setiap arahan tulis kepada pangkalan data hamba, dan pada masa yang sama, ia akan menyimpan arahan tulis dalam baris gilir tunggakan dan rekod storan semasa dalam baris gilir tertunggak. Apabila salve disambungkan semula, induk akan menemui arahan yang dilaksanakan semasa tempoh pemotongan dalam baris gilir tunggakan cincin berdasarkan offset yang diluluskan daripada nod hamba, dan menyegerakkannya ke nod salve untuk mencapai hasil penyegerakan tambahan.

Proses pelaksanaan PSYNC adalah seperti yang ditunjukkan di bawah:

Daripada proses pelaksanaan PSYNC di atas, dapat dilihat apabila nod hamba diputuskan dan disambungkan semula, ia dinilai sama ada untuk menggunakan penyegerakan tambahan Intinya ialah sama ada perbezaan antara ofset ofset hamba dan ofset master melebihi saiz penimbal tunggakan salinan Kemudian saiz ini dikonfigurasikan oleh parameter berikut. Penimbal tunggakan replikasi pada asasnya ialah baris gilir bulat panjang tetap Secara lalai, saiz baris gilir tunggakan ialah 1MB Saiz baris gilir boleh ditetapkan melalui fail konfigurasi: Tetapkan saiz penimbal tunggakan replikasi lebih besar pangkalan data tuan-hamba dibenarkan untuk diputuskan sambungannya Semakin lama masa

repl-backlog-size 1mb

Redis juga menyediakan tempoh masa yang diperlukan untuk melepaskan baris gilir cincin apabila tiada hamba yang perlu disegerakkan . Apabila tiada sambungan salve, berapa kerap penimbal tunggakan replikasi dikeluarkan

repl-backlog-ttl 3600

四、主从复制策略

Redis采用了乐观复制的策略，也就是在一定程度内容忍主从数据库的内容不一致，但是保持主从数据库数据的最终一致性。具体来说，Redis在主从复制的过程中，本身就是异步的，在主从数据库执行完客户端请求后会立即将结果返回给客户端，并异步的将命令同步给从数据库，但是这里并不会等待从数据库完全同步之后，再返回客户端。这一特性虽然保证了主从复制期间性能不受影响，但是也会产生一个数据不一致的时间窗口，如果在这个时间窗口期间网络突然断开连接，就会导致两者数据不一致。如果不在配置文件中添加其他策略，那就默认会采用这种方式。为了防止主从不一致不可控，redis提供了以下两个参数来做约束：

min-slaves-to-write 3
min-slaves-max-lag 10

当slave数量小于min-slaves-to-write，且延迟小于等于min-slaves-max-lag时，master停止写入操作。

还有一个参数也会影响主从之间的延时：

repl-disable-tcp-nodelay：

设置成yes，则redis会合并小的TCP包从而节省带宽，但会增加同步延迟，造成master与slave数据不一致。设置成no，则redis master会立即发送同步数据，几乎没有延迟。

Redis的主从同步无论那种场景可以抽象为以下七个步骤：

1.建立socket连接

从服务器根据设置的套接字创建连向主服务器的套接字连接，主服务器接收从服务器的套接字连接之后，为该套接字创建响应的客户端状态，并将此时的从服务器看做是主服务器的客户端，也就是该从服务器同时具备服务器与客户端两个身份。

2.发送PING命令

PING命令主要有两种作用：虽然建立了套接字连接，但是还未使用过，通过发送PING命令检查套接字的读写状态是否正常；通过发送PING命令检查主服务器能否正常处理命令请求，能处理主服务器回复PONG。

3.身份验证

从服务器接收到主服务器返回的“PONG”回复，接下来就需要考虑身份验证的事。如果从服务器设置了masterauth选项，那么进行身份验证，如果从服务器没有设置masterauth选项，那么不进行身份验证。

4.发送端口信息

在身份验证步骤之后，从服务器将执行命令REPLCONF listening-port ，向主服务器发送从服务器的监听端口号。

5.数据同步

从服务器向主服务器发送SYNC命令、PSYNC命令，执行同步操作。

6.命令传播

主从服务器就会进入命令传播阶段，主服务器只要将自己执行的写命令发送给从服务器，而从服务器只要一直执行并接收主服务器发来的写命令。

五、告一段落

本篇详细介绍了redis主从同步机制，不同场景下同步策略的选择，这也是redis高可用的基石。在此基础上，下一篇将对redis高可用的实现来进行分析讲解。

更多编程相关知识，请访问：编程视频！！

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