Redis amalan ketersediaan tinggi

Redis ialah pangkalan data Nilai Kunci jenis log sumber terbuka yang ditulis dalam bahasa ANSI C, menyokong rangkaian, boleh berasaskan memori dan berterusan serta menyediakan API dalam berbilang bahasa.

Kini, data perniagaan Internet berkembang pada kadar yang lebih pantas, dan jenis data menjadi semakin banyak, yang mengemukakan keperluan yang lebih tinggi untuk kelajuan dan keupayaan pemprosesan data. Redis ialah pangkalan data bukan perkaitan dalam ingatan sumber terbuka yang membawa pengalaman yang mengganggu kepada pembangun. Direka dari awal hingga akhir dengan mengambil kira prestasi tinggi, Redis ialah pangkalan data NoSQL terpantas yang tersedia hari ini.

Sambil mempertimbangkan prestasi tinggi, ketersediaan tinggi juga merupakan pertimbangan penting. Internet menyediakan perkhidmatan tanpa gangguan 7×24 dan Failover pada kelajuan terpantas semasa kegagalan, yang boleh membawa kerugian minimum kepada perusahaan.

Jadi, apakah seni bina ketersediaan tinggi dalam aplikasi praktikal? Apakah kebaikan dan keburukan antara seni bina? Bagaimana kita harus memilih? Apakah beberapa amalan terbaik?

Sebelum menerangkan penyelesaian ketersediaan tinggi Redis, mari kita lihat dahulu prinsip Redis Sentinel.

1. Kluster Sentinel menemui induk melalui fail konfigurasi yang diberikan dan memantau induk apabila ia bermula. Dapatkan semua pelayan hamba di bawah pelayan ini dengan menghantar maklumat maklumat kepada tuan.
2. Kluster Sentinel menghantar maklumat helo (sekali sesaat) kepada pelayan induk dan hamba yang dipantau melalui sambungan arahan Maklumat ini termasuk IP, port, id, dsb. Sentinel sendiri, untuk mengumumkan kewujudannya kepada Sentinel lain.
3. Kluster Sentinel menerima maklumat helo yang dihantar oleh Sentinel lain melalui sambungan langganan untuk menemui Sentinel lain yang memantau pelayan induk yang sama akan membuat sambungan arahan antara satu sama lain untuk komunikasi, kerana sudah ada pelayan tuan-hamba yang menghantar dan menerima helo Tiada langganan; sambungan dibuat antara Sentinel dan Sentinel.
4. Kluster Sentinel menggunakan perintah ping untuk mengesan status tika itu Jika tiada balasan dalam masa yang ditentukan (turun selepas milisaat) atau balasan yang salah dikembalikan, tika itu dinilai sebagai di luar talian.
5. Apabila suis failover aktif/siap sedia dicetuskan, failover tidak akan meneruskan serta-merta Ia juga memerlukan kebenaran majoriti Sentinel dalam Sentinel sebelum failover boleh dijalankan, iaitu, Sentinel yang melakukan failover akan dapatkan kebenaran kuorum Sentinels yang ditetapkan Selepas berjaya, Masukkan keadaan ODOWN. Sebagai contoh, jika 2 korum dikonfigurasikan antara 5 Penjaga, failover akan dilaksanakan apabila 2 Penjaga menganggap bahawa tuan sudah mati.
6. Sentinel menghantar arahan SLAVEOF NO ONE kepada hamba yang dipilih sebagai tuan. Jika keutamaan adalah sama, semak subskrip replikasi, mana-mana yang menerima lebih banyak data replikasi daripada induk akan diletakkan pada kedudukan pertama. Jika keutamaan dan indeks adalah sama, yang mempunyai ID proses yang lebih kecil akan dipilih.
7. Selepas Sentinel diberi kuasa, ia akan memperoleh nombor versi konfigurasi terkini (zaman konfigurasi) induk yang gagal Apabila pelaksanaan failover selesai, nombor versi ini akan digunakan untuk konfigurasi terkini dan memberitahu orang lain melalui siaran Sentinel, Sentinel lain. kemas kini konfigurasi induk yang sepadan.

1 hingga 3 ialah mekanisme penemuan automatik:

• Hantar arahan info kepada induk yang dipantau setiap 10 saat dan dapatkan maklumat induk semasa berdasarkan balasan.
• Hantar arahan PING ke semua pelayan redis, termasuk Sentinel, pada kekerapan 1 saat dan tentukan sama ada pelayan dalam talian melalui balasan.
• Hantar mesej maklumat induk Sentinel semasa kepada semua pelayan induk dan hamba yang dipantau pada kekerapan 2 saat.

4 ialah mekanisme pengesanan, 5 dan 6 ialah mekanisme failover, dan 7 ialah mekanisme konfigurasi kemas kini. [1]

Selepas menerangkan prinsip Redis Sentinel, mari terangkan Seni bina ketersediaan tinggi Redis yang biasa digunakan.

• Kluster Redis Sentinel + DNS intranet + skrip tersuai
• Kluster Redis Sentinel + VIP + Skrip Tersuai
• Enkapsulasi klien untuk menyambung terus ke port Redis Sentinel
  • JedisSentinelPool, sesuai untuk Java
  • PHP dibungkus sendiri berdasarkan phpredis
• Kluster Redis Sentinel + Keepalived/Haproxy
• Redis M/S + Keepalived
• Kluster Redis
• Twemproxy
• Codis

Berikut akan diterangkan satu persatu dengan gambar dan teks.

Gambar di atas adalah penyelesaian yang telah diaplikasikan dalam persekitaran dalam talian. Lapisan bawah ialah gugusan Redis Sentinel, yang bertindak sebagai ejen untuk induk dan hamba Redis Bahagian Web menyambung ke DNS intranet untuk menyediakan perkhidmatan. DNS Intranet diperuntukkan mengikut peraturan tertentu, seperti xxxx.redis.cache/queue.port.xxx.xxx Segmen pertama menunjukkan singkatan perniagaan, segmen kedua menunjukkan bahawa ini ialah nama domain intranet Redis dan. segmen ketiga Mewakili jenis Redis, cache mewakili cache, baris gilir mewakili baris gilir, segmen keempat mewakili port Redis, dan segmen kelima dan keenam mewakili nama domain utama intranet.

Apabila nod induk gagal, seperti kegagalan mesin, kegagalan nod Redis atau kebolehcapaian rangkaian, kelompok Sentinel akan memanggil skrip terkonfigurasi client-reconfig-script untuk mengubah suai nama domain intranet port yang sepadan. Nama domain intranet port yang sepadan menghala ke nod induk Redis baharu.

Kelebihan:

• Pensuisan peringkat kedua, selesaikan keseluruhan operasi pensuisan dalam masa 10s
• Penyesuaian skrip dan seni bina boleh dikawal
• Telus kepada aplikasi, bahagian hadapan tidak perlu risau tentang perubahan di bahagian belakang

Keburukan:

• Kos penyelenggaraan adalah tinggi sedikit Adalah disyorkan untuk melabur dalam lebih daripada 3 mesin untuk kelompok Redis Sentinel
• Bergantung pada DNS, terdapat kelewatan resolusi
• Perkhidmatan mod Sentinel tidak akan tersedia untuk tempoh masa yang singkat
• Penyelesaian ini tidak boleh digunakan jika perkhidmatan itu diakses melalui rangkaian luaran

Pelan ini sedikit berbeza daripada yang sebelumnya. Penyelesaian pertama menggunakan DNS intranet, dan penyelesaian kedua menggantikan DNS intranet dengan IP maya. Lapisan bawah ialah kelompok Redis Sentinel, yang bertindak sebagai ejen untuk tuan dan hamba Redis, dan bahagian Web menyediakan perkhidmatan melalui VIP. Apabila menggunakan Redis master-slave, anda perlu mengikat IP maya ke nod induk Redis semasa. Apabila nod induk gagal, seperti kegagalan mesin, kegagalan nod Redis atau kebolehcapaian rangkaian, gugusan Sentinel akan memanggil skrip yang dikonfigurasikan oleh client-reconfig-script untuk mengapungkan VIP ke nod induk baharu.

Kelebihan:

• Pensuisan peringkat kedua, selesaikan keseluruhan operasi pensuisan dalam masa 5s
• Penyesuaian skrip dan seni bina boleh dikawal
• Telus kepada aplikasi, bahagian hadapan tidak perlu risau tentang perubahan di bahagian belakang

Keburukan:

• Kos penyelenggaraan adalah tinggi sedikit Adalah disyorkan untuk melabur dalam lebih daripada 3 mesin untuk kelompok Redis Sentinel
• Menggunakan VIP meningkatkan kos penyelenggaraan dan risiko IP huru-hara
• Perkhidmatan mod Sentinel tidak akan tersedia untuk tempoh masa yang singkat

Some businesses can only access Redis through the external network. Neither of the above two solutions are available, so this solution was derived. Web uses the client to connect to a certain port of a machine in one of the Redis Sentinel clusters, and then obtains the current master node through this port, and then connects to the real Redis master node to perform corresponding salesman operations. It is important to note that both the Redis Sentinel port and the Redis master node require open access. If the front-end business uses Java, JedisSentinelPool can be reused; if the front-end business uses PHP, secondary encapsulation can be done based on phpredis.

Advantages:

• Service detects faults promptly
• DBA maintenance cost is low

Disadvantages:

• Depends on client support Sentinel
• Sentinel server and Redis nodes require open access
• Intrusive to the application

The bottom layer is the Redis Sentinel cluster, which acts as an agent for Redis master and slave, and the Web side provides services through VIP. When the master node fails, such as machine failure, Redis node failure, or network unreachability, switching between Redis is guaranteed by the internal mechanism of Redis Sentinel, and VIP switching is guaranteed by Keepalived.

Advantages:

• Switch in seconds
• Transparent to application

Disadvantages:

• High maintenance cost
• Having split brain
• Sentinel mode service will be unavailable for a short period of time

This solution does not use Redis Sentinel. This solution uses native master-slave and Keepalived. VIP switching is guaranteed by Keepalived. Switching between Redis master-slave requires custom scripts.

Advantages:

• Switch in seconds
• Transparent to application
• Simple deployment and low maintenance cost

Disadvantages:

• Requires script to implement switching function
• Having split brain

From: http://intro2libsys.com/focused-redis-topics/day-one/intro-redis-cluster

Redis 3.0.0 was officially released on April 2, 2015, more than two years ago. Redis cluster adopts P2P mode and is non-centralized. Divide the key into 16384 slots, and each instance is responsible for a part of the slots. The client requests the corresponding data. If the instance slot does not have corresponding data, the instance will be forwarded to the corresponding instance. In addition, the Redis cluster synchronizes node information through the Gossip protocol.

Advantages:

• Components are all-in-box, easy to deploy and save machine resources
• Performance is better than proxy mode
• Automatic failover and data available during slot migration
• Official native cluster solution, guaranteed updates and support

Disadvantages:

• The architecture is relatively new and there are few best practices
• Multi-key operation support is limited (the driver can save the country through curves)
• In order to improve performance, the client needs to cache routing table information
• Node discovery and reshard operations are not automated enough

From: http://engineering.bloomreach.com/the-evolution-of-fault-tolerant-redis-cluster

Multiple isomorphic Twemproxy (same configuration) works at the same time, accepts client requests, and forwards them to the corresponding Redis according to the hash algorithm.

Twemproxy solution is relatively mature. Our team has used this solution for a long time, but the effect is not very satisfactory. On the one hand, the positioning problem is more difficult, and on the other hand, its support for automatically eliminating nodes is not very friendly.

Advantages:

• Easy to develop and almost transparent to the application
• Long history and mature solutions

Disadvantages:

• Proxy affects performance
• LVS and Twemproxy will have node performance bottlenecks
• Redis expansion is very troublesome
• Twitter has abandoned the use of this solution internally, and the new architecture is not open source

From: https://github.com/CodisLabs/codis

Codis is an open source product by Wandoujia and involves many components. Among them, ZooKeeper stores routing tables and proxy node metadata, and distributes Codis-Config commands; Codis-Config is an integrated management tool with a Web interface for use; Codis-Proxy is A stateless proxy compatible with the Redis protocol; Codis-Redis is a secondary development based on Redis 2.8 version, adding slot support to facilitate data migration.

Advantages:

• Easy to develop and almost transparent to the application
• Performance is better than Twemproxy
• Has a graphical interface, easy expansion, and convenient operation and maintenance

Disadvantages:

• Proxy still affects performance
• Too many components, requiring a lot of machine resources
• The Redis code has been modified, resulting in the inability to synchronize with the official, and the follow-up of new features is slow
• The development team is preparing to promote reborndb based on Redis transformation

The so-called best practices are practices that are most suitable for specific scenarios.

We mainly recommend the following plans:

• Redis Sentinel cluster + intranet DNS + custom script
• Redis Sentinel Cluster + VIP + Custom Script

The following are the best practices summarized during actual combat:

• Redis Sentinel cluster is recommended to use >= 5 machines
• Different large businesses can use a Redis Sentinel cluster to proxy all ports under the business
• Divide the Redis port range according to different businesses
• Custom scripts are recommended to be implemented in Python for easy expansion
• Custom scripts need to pay attention to determine the current Sentinel role
• Pass in the parameters of the custom script:
• Custom scripts require remote ssh to operate the machine. It is recommended to use the paramiko library to avoid repeatedly establishing SSH connections and consuming time
• To accelerate SSH connection, it is recommended to turn off the following two parameters
  • UseDNS no
  • GSSAPIAuthentication no
• If you receive an alert via WeChat or email, it is recommended to fork a process to avoid blocking the main process
• Automatic switching and failover, it is recommended that all operations be completed within 15s

This event shared the necessity of Redis high availability, the Sentinel principle, the common architecture of Redis high availability and the best practices summarized in the actual combat process. I hope it will be helpful to readers. If you need follow-up communication, you can add me WeChat (Wentasy), or send an email to: dbarobinwen@gmail.com

Attached PPT download: https://github.com/dbarobin/slides

Video Playback: Best Practices for Redis High Availability Architecture

Thank you to Tingyun and Operation and Maintenance Gang for their careful organization, and thank you to everyone who came to participate in this event despite the heavy rain. This sharing was videotaped by the IT guru, and I would like to thank the IT guru for his technical support.

[1] jyzhou (2016-06-12). Redis replication, Sentinel construction and principle explanation. Retrieved from http://www.cnblogs.com/zhoujinyi/p/5570024.html.

Atas ialah kandungan terperinci Redis amalan ketersediaan tinggi. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!