T: Satu server layanan, satu database, operasi: kueri saldo pengguna saat ini, kurangi 3% dari saldo saat ini sebagai biaya penanganan
disinkronkan
kunci
Kunci DB
T: Dua server layanan, satu database, operasi: kueri saldo pengguna saat ini, kurangi 3% dari saldo saat ini sebagai biaya penanganan
Kunci terdistribusi
Jenis kunci terdistribusi apa yang kita butuhkan?
Ini dapat memastikan bahwa dalam kluster aplikasi terdistribusi, metode yang sama hanya dapat dijalankan oleh satu utas pada satu mesin secara bersamaan.
Jika kunci ini adalah kunci masuk kembali (hindari kebuntuan)
Kunci ini paling baik adalah kunci pemblokir (pertimbangkan apakah Anda menginginkan yang ini sesuai dengan kebutuhan bisnis Anda)
Kunci ini paling baik adalah kunci yang adil (pertimbangkan apakah Anda menginginkan yang ini atau tidak sesuai dengan kebutuhan bisnis)
Ada fungsi kunci akuisisi dan pelepasan yang sangat tersedia
Kinerja kunci akuisisi dan pelepasan lebih baik
1. Kunci terdistribusi berdasarkan database
Kunci terdistribusi berdasarkan implementasi berbasis tabel
Saat kita ingin mengunci metode, jalankan SQL berikut:
masukkan ke dalam nilai methodLock(method_name,desc) ('method_name','desc')
Karena kita telah membuat batasan keunikan pada method_name, jika beberapa permintaan dikirimkan ke database secara bersamaan, database akan memastikan bahwa hanya satu operasi yang dapat berhasil, maka kita dapat berasumsi bahwa utas yang berhasil memperoleh metode mengunci dan dapat mengeksekusi konten isi metode.
Saat metode dieksekusi, jika Anda ingin melepaskan kunci, Anda perlu menjalankan SQL berikut:
delete from methodLock di mana method_name ='method_name'
Implementasi sederhana di atas ini memiliki masalah sebagai berikut:
- Kunci ini tergantung pada ketersediaan database, yang merupakan satu titik dan akan menyebabkan sistem bisnis tidak tersedia setelah database ditutup.
- Kunci ini tidak memiliki waktu kedaluwarsa, dan setelah operasi pembukaan kunci gagal, catatan kunci akan tetap ada di database dan utas lain tidak akan lagi dapat memperoleh kunci.
- Kunci ini hanya dapat non-pemblokiran, karena operasi penyisipan data akan langsung melaporkan kesalahan setelah penyisipan gagal. Utas yang tidak memperoleh kunci tidak akan masuk ke antrean, dan perlu memicu operasi akuisisi kunci lagi untuk mendapatkan kunci lagi.
- Kunci tidak masuk kembali, dan ulir yang sama tidak dapat mendapatkan kunci lagi sampai dilepaskan. Karena data dalam data sudah ada.
- Kunci ini adalah kunci yang tidak adil, dan semua benang yang menunggu kunci bersaing untuk mendapatkan kunci karena keberuntungan.
Tentu saja, kita juga dapat menyelesaikan masalah di atas dengan cara lain.
- Apakah database satu titik? Bangun dua database, dan data akan disinkronkan di kedua arah. Setelah ditutup, cepat beralih ke perpustakaan cadangan.
- Tidak ada waktu kedaluwarsa? Cukup lakukan tugas terjadwal untuk membersihkan data batas waktu dalam database secara berkala.
- Tidak memblokir? Lakukan perulangan while hingga sisipan berhasil dan kemudian mengembalikan keberhasilan.
- Tidak masuk kembali? Tambahkan bidang ke tabel database untuk merekam informasi host dan informasi utas dari mesin yang saat ini mendapatkan kunci, lalu lain kali Anda mendapatkan kunci, kueri database terlebih dahulu, jika informasi host dan informasi utas dari mesin saat ini dapat ditemukan di database, Anda dapat langsung menetapkan kunci kepadanya.
- Tidak adil? Buat tabel perantara lain untuk merekam semua utas yang menunggu kunci, dan urutkan sesuai dengan waktu pembuatan, dan hanya yang pertama dibuat yang diizinkan untuk memperoleh kunci
Kunci terdistribusi berdasarkan kunci eksklusif
Selain menambahkan dan menghapus catatan dalam tabel data, kunci terdistribusi juga dapat diimplementasikan dengan bantuan kunci yang disertakan dengan data.
Kami juga menggunakan tabel database yang baru saja kami buat. Kunci terdistribusi dapat diimplementasikan melalui kunci eksklusif pada database. Mesin InnoDB berbasis MySQL dapat menggunakan metode berikut untuk mengimplementasikan operasi penguncian:
Jika Anda menambahkan untuk pembaruan setelah pernyataan kueri, database akan menambahkan kunci eksklusif ke tabel database selama proses kueri. Saat kunci eksklusif ditambahkan ke rekaman, utas lain tidak dapat lagi menambahkan kunci eksklusif ke rekaman pada baris tersebut.
Kita dapat berpikir bahwa utas yang memperoleh kunci eksklusif dapat memperoleh kunci terdistribusi, dan ketika kunci diperoleh, logika bisnis metode dapat dieksekusi, dan kemudian dibuka melalui metode berikut:
public void unlock(){ connection.commit(); }
melalui connection.commit(); operasi untuk melepaskan kunci.
Metode ini dapat secara efektif memecahkan masalah yang disebutkan di atas tentang ketidakmampuan untuk melepaskan kunci dan memblokir kunci.
Memblokir kunci? Pernyataan for update kembali segera setelah eksekusi berhasil dan tetap diblokir hingga berhasil.
Layanan turun setelah penguncian, tidak bisa dilepaskan? Dengan cara ini, database melepaskan kunci sendiri setelah layanan mati.
Namun, itu masih belum secara langsung menyelesaikan masalah titik tunggal database, reentrancy, dan penguncian yang adil.
Untuk meringkas cara menggunakan database untuk mengimplementasikan kunci terdistribusi, yang keduanya mengandalkan tabel dalam database, satu adalah menentukan apakah ada kunci dengan keberadaan catatan dalam tabel, dan yang lainnya adalah dengan mengimplementasikan kunci terdistribusi melalui kunci eksklusif database.
Keuntungan Penguncian Terdistribusi di Database
Secara langsung dengan bantuan database, mudah dipahami.
Kerugian menerapkan kunci terdistribusi dalam database
Akan ada berbagai masalah, dan seluruh solusi akan menjadi semakin kompleks dalam proses pemecahan masalah.
Mengoperasikan database memerlukan overhead tertentu, dan masalah kinerja perlu dipertimbangkan.
2. Kunci terdistribusi berdasarkan cache
Dibandingkan dengan solusi penguncian terdistribusi berbasis database, implementasi berbasis cache akan berkinerja lebih baik dalam hal kinerja.
Ada banyak produk caching dewasa saat ini, termasuk Redis, memcached, dll. Di sini kami mengambil Redis sebagai contoh untuk menganalisis skema penggunaan cache untuk mengimplementasikan kunci terdistribusi.
Ada banyak artikel terkait di Internet tentang penerapan kunci terdistribusi berdasarkan Redis, dan metode implementasi utamanya adalah dengan menggunakan metode Jedis.setNX.
Ada juga beberapa masalah dengan implementasi di atas:
1. Masalah titik tunggal.
2. Kunci ini tidak memiliki waktu kedaluwarsa, setelah operasi pembukaan kunci gagal, itu akan menyebabkan catatan kunci berada dalam redis sepanjang waktu, dan benang lain tidak dapat lagi mendapatkan kunci.
3. Kunci ini hanya bisa non-blocking, dan akan kembali secara langsung terlepas dari keberhasilan atau kegagalan.
4. Kunci ini tidak masuk kembali, setelah utas mendapatkan kunci, ia tidak dapat memperoleh kunci lagi sebelum melepaskan kunci, karena kunci yang digunakan sudah ada di redis. Operasi setNX tidak dapat lagi dieksekusi.
5. Kunci ini tidak adil, semua utas menunggu memulai operasi setNX pada saat yang sama, dan utas keberuntungan bisa mendapatkan kunci.
Tentu saja, ada juga cara untuk mengatasinya.
- Saat ini, layanan caching arus utama mendukung penyebaran klaster untuk memecahkan masalah titik tunggal melalui pengelompokan.
- Tidak ada waktu kedaluwarsa? Metode setExpire redis mendukung waktu kedaluwarsa yang masuk, dan data secara otomatis dihapus setelah waktu tercapai.
- Tidak memblokir? sementara berulang kali dieksekusi.
- Bukankah mungkin untuk masuk kembali? Setelah utas memperoleh kunci, simpan informasi host dan informasi utas saat ini, dan periksa apakah Anda adalah pemilik kunci saat ini sebelum mendapatkannya di lain waktu.
- Tidak adil? Letakkan semua utas tunggu dalam antrean sebelum utas memperoleh kunci, lalu dapatkan kunci berdasarkan pertama masuk, pertama keluar.
Kebijakan sinkronisasi kluster redis membutuhkan waktu, dan ada kemungkinan bahwa utas A mendapatkan kunci setelah berhasil mengatur NX, tetapi nilai ini belum diperbarui ke server tempat utas B mengeksekusi setNX, yang akan menyebabkan masalah konkurensi.
Salvatore Sanfilippo, penulis redis, mengusulkan algoritma Redlock, yang mengimplementasikan manajemen kunci terdistribusi (DLM) yang lebih aman dan andal daripada satu node.
Algoritma Redlock mengasumsikan bahwa ada N node redis yang independen satu sama lain, umumnya diatur ke N=5, dan N node ini berjalan pada mesin yang berbeda untuk mempertahankan independensi fisik.
Langkah-langkah algoritma adalah sebagai berikut:
1. Klien memperoleh waktu saat ini dalam milidetik.
2. Klien mencoba mendapatkan kunci N node, (setiap node mendapatkan kunci dengan cara yang sama seperti kunci cache yang disebutkan sebelumnya), dan N node mendapatkan kunci dengan kunci dan nilai yang sama. Klien perlu mengatur batas waktu akses antarmuka, dan waktu tunggu antarmuka harus jauh lebih sedikit dari batas waktu penguncian, misalnya, waktu kunci yang dirilis secara otomatis adalah 10 detik, kemudian batas waktu antarmuka diatur menjadi sekitar 5-50 milidetik. Ini memungkinkan Anda untuk menghabiskan waktu sesegera mungkin saat mengakses node redis setelah mati, dan mengurangi penggunaan kunci secara normal.
3. Klien menghitung berapa banyak waktu yang dibutuhkan untuk mendapatkan kunci, dengan mengurangi waktu yang diperoleh pada langkah 1 dengan waktu saat ini, hanya ketika klien memperoleh lebih dari 3 node kunci, dan waktu untuk memperoleh kunci kurang dari waktu tunggu kunci, klien memperoleh kunci terdistribusi.
4. Waktu klien untuk memperoleh kunci adalah waktu tunggu kunci yang ditetapkan dikurangi waktu yang dihabiskan untuk mendapatkan kunci yang dihitung pada langkah 3.
5. Jika klien gagal mendapatkan kunci, klien akan menghapus semua kunci secara bergantian.
Dengan menggunakan algoritma Redlock, dapat dijamin bahwa layanan kunci terdistribusi masih dapat berfungsi saat menggantung hingga 2 node, yang sangat meningkatkan ketersediaan dibandingkan dengan kunci database dan kunci cache sebelumnya.
Namun, seorang ahli terdistribusi menulis artikel "Cara melakukan penguncian terdistribusi" yang mempertanyakan kebenaran Redlock.
Pakar menyebutkan bahwa ada dua aspek yang perlu dipertimbangkan saat mempertimbangkan kunci terdistribusi: kinerja dan kebenaran.
Jika Anda menggunakan kunci terdistribusi berperforma tinggi dan kebenarannya tidak diperlukan, maka menggunakan kunci cache sudah cukup.
Jika Anda menggunakan kunci terdistribusi yang sangat andal, maka Anda perlu mempertimbangkan masalah keandalan yang ketat. Redlock, di sisi lain, tidak memenuhi kebenaran. Mengapa tidak? Para ahli mencantumkan beberapa aspek.
Saat ini, banyak bahasa pemrograman menggunakan mesin virtual dengan fungsi GC, di GC Penuh, program akan berhenti memproses GC, terkadang GC Penuh membutuhkan waktu lama, dan bahkan program tersebut memiliki jeda beberapa menit, artikel tersebut mencantumkan contoh HBase, HBase terkadang GC selama beberapa menit, yang akan menyebabkan waktu sewa habis. Misalnya, pada gambar di bawah ini, klien 1 mendapatkan kunci dan akan memproses sumber daya bersama, dan ketika akan memproses sumber daya bersama, GC Penuh terjadi hingga kunci kedaluwarsa. Dengan cara ini, klien 2 mendapatkan kunci lagi dan mulai mengerjakan sumber daya bersama. Saat klien 2 sedang diproses, klien 1 menyelesaikan GC penuh dan mulai memproses sumber daya bersama, sehingga kedua klien memproses sumber daya bersama.
Para ahli memberikan solusi, seperti yang ditunjukkan pada gambar di bawah ini, terlihat seperti MVCC, bawa token ke kunci, token adalah konsep versi, setiap kali penguncian operasi selesai, token akan ditambahkan 1, bawa token saat memproses sumber daya bersama, hanya versi token yang ditentukan yang dapat menangani sumber daya bersama.
Kemudian ahli juga mengatakan bahwa algoritme mengandalkan waktu setempat, dan bahwa Redis mengandalkan metode getTimeOfDay untuk mendapatkan waktu alih-alih jam monoton saat menangani kedaluwarsa kunci, yang juga menyebabkan ketidakakuratan waktu. Misalnya, dalam skenario, dua klien 1 dan klien 2 memiliki 5 simpul redis (A, B, C, D dan E).
1. Klien 1 berhasil memperoleh kunci dari A, B, dan C, dan memperoleh batas waktu jaringan kunci dari D dan E.
2. Jam node C tidak akurat, menyebabkan batas waktu penguncian.
3. klien 2 berhasil memperoleh kunci dari C, D, dan E, dan memperoleh batas waktu jaringan kunci dari A dan B.
4. Dengan cara ini, klien 1 dan klien 2 mendapatkan kunci.
Untuk meringkas dua poin yang dikatakan para ahli tentang ketidaktersediaan Redlock:
1. GC dan skenario lainnya dapat terjadi kapan saja, menyebabkan klien mendapatkan kunci, dan batas waktu pemrosesan menyebabkan klien lain mendapatkan kunci. Para ahli juga memberikan solusi untuk menggunakan token self-incrementing.
2. Algoritme mengandalkan waktu setempat, dan jam akan tidak akurat, mengakibatkan dua klien mendapatkan kunci pada saat yang sama.
Oleh karena itu, kesimpulan yang diberikan oleh para ahli adalah bahwa Redlock hanya dapat bekerja secara normal dalam penundaan jaringan terbatas, gangguan program terbatas, dan rentang kesalahan clock terbatas, tetapi batas ketiga skenario ini tidak dapat dikonfirmasi, sehingga para ahli tidak merekomendasikan penggunaan Redlock. Untuk skenario dengan persyaratan kebenaran yang tinggi, para ahli merekomendasikan Zookeeper, yang akan dibahas nanti tentang penggunaan Zookeeper sebagai kunci terdistribusi.
Tanggapan dari penulis Redis
Penulis Redis menanggapi dengan menulis blog setelah melihat artikel ahlinya. Penulis dengan sopan berterima kasih kepada ahli, dan kemudian mengungkapkan ketidaksetujuannya dengan pandangan ahli.
Saya meminta analisis dalam spesifikasi Redlock asli di sini:http://redis.io/topics/distlock.Jadi terima kasih Martin. Namun saya tidak setuju dengan analisisnya.
Diskusi penulis REDIS tentang penggunaan token untuk memecahkan masalah batas waktu penguncian dapat diringkas dalam lima poin berikut:
Poin 1, penggunaan kunci terdistribusi umumnya tidak memiliki cara lain untuk mengontrol sumber daya bersama, para ahli menggunakan token untuk memastikan pemrosesan sumber daya bersama, maka tidak perlu kunci terdistribusi.
Poin 2: Untuk pembuatan token, untuk memastikan keandalan token yang diperoleh oleh klien yang berbeda, layanan yang menghasilkan token masih membutuhkan kunci terdistribusi untuk memastikan keandalan layanan.
Poin 3, untuk cara para ahli mengatakan bahwa token yang bertambah sendiri, penulis redis percaya bahwa itu sama sekali tidak perlu, setiap klien dapat menghasilkan uuid unik sebagai token, dan mengatur sumber daya bersama ke keadaan yang hanya dapat ditangani oleh klien dengan uuid, sehingga klien lain tidak dapat memproses sumber daya bersama sampai klien yang memperoleh kunci melepaskan kunci.
Seperti yang ditunjukkan pada gambar di atas, jika klien token 34 mengirim GC selama proses penulisan dan menyebabkan waktu penguncian habis, klien lain mungkin mendapatkan kunci token 35 dan mulai menulis lagi, yang mengakibatkan konflik kunci. Oleh karena itu, urutan token tidak dapat digabungkan dengan sumber daya bersama.
Poin 5, penulis redis percaya bahwa dalam sebagian besar skenario, kunci terdistribusi digunakan untuk menangani masalah pembaruan dalam skenario non-transaksional. Penulis harus bermaksud bahwa ada beberapa skenario di mana sulit untuk menggabungkan token untuk menangani sumber daya bersama, jadi Anda harus mengandalkan kunci untuk mengunci sumber daya dan memprosesnya.
Masalah jam lain yang dibicarakan oleh para ahli, penulis Redis juga memberikan penjelasan. Jika waktu yang dibutuhkan untuk mendapatkan kunci terlalu lama dan melebihi waktu tunggu default kunci, maka klien tidak dapat memperoleh kunci saat ini, dan tidak akan ada contoh yang diusulkan oleh para ahli.
Perasaan pribadi
Masalah pertama yang saya rangkum adalah bahwa setelah klien memperoleh kunci terdistribusi, kunci dapat dilepaskan setelah batas waktu selama pemrosesan klien. Sebelumnya, ketika berbicara tentang timeout yang ditetapkan oleh kunci database 2 menit, jika suatu tugas menempati kunci pesanan selama lebih dari 2 menit, maka pusat perdagangan lainnya dapat memperoleh kunci pesanan ini, sehingga kedua pusat perdagangan dapat memproses pesanan yang sama secara bersamaan. Dalam keadaan normal, tugas diproses dalam hitungan detik, tetapi terkadang, batas waktu yang ditetapkan dengan bergabung dengan permintaan RPC terlalu lama, dan ada beberapa permintaan batas waktu seperti itu dalam suatu tugas, maka kemungkinan waktu pembukaan kunci otomatis akan terlampaui. Jika kita menulis dalam java, mungkin ada GC Penuh di tengah, jadi setelah kunci dibuka setelah batas waktu penguncian, klien tidak dapat melihatnya, yang merupakan hal yang sangat serius. Saya tidak berpikir ini masalah dengan kunci itu sendiri, selama kunci terdistribusi yang disebutkan di atas memiliki karakteristik pelepasan batas waktu, masalah seperti itu akan terjadi. Jika Anda menggunakan fungsi batas waktu penguncian, klien harus mengatur batas waktu penguncian dan mengambil tindakan yang sesuai, alih-alih terus memproses sumber daya bersama. Algoritme Redlock mengembalikan waktu penguncian yang dapat ditempati klien setelah klien memperoleh kunci, dan klien harus memproses waktu ini untuk menghentikan tugas setelah waktu tersebut.
Masalah kedua adalah ahli terdistribusi tidak memahami Redlock. Fitur utama Redlock adalah bahwa waktu untuk memperoleh kunci adalah total waktu kunci default ke batas waktu dikurangi waktu yang dibutuhkan untuk memperoleh kunci, sehingga waktu yang dibutuhkan klien untuk memproses adalah waktu relatif, terlepas dari waktu setempat.
Dari sudut pandang ini, kebenaran Redlock dapat dijamin dengan baik. Analisis Redlock yang cermat, dibandingkan dengan redis node, fitur utama yang disediakan oleh Redlock adalah keandalan yang lebih tinggi, yang merupakan fitur penting dalam beberapa skenario. Tapi saya pikir Redlock telah menghabiskan terlalu banyak uang untuk mencapai keandalan.
- Pertama, 5 node harus dikerahkan untuk membuat Redlock lebih andal.
- Kemudian Anda perlu meminta 5 simpul untuk mendapatkan kunci, dan melalui metode Future, Anda dapat terlebih dahulu meminta ke 5 simpul secara bersamaan, dan kemudian mendapatkan hasil respons bersama-sama, yang dapat mempersingkat waktu respons, tetapi masih membutuhkan lebih banyak waktu daripada kunci redis simpul tunggal.
- Kemudian karena lebih dari 3 dari 5 node harus diperoleh, mungkin ada konflik kunci, yaitu setiap orang telah memperoleh 1-2 kunci, dan akibatnya, tidak ada yang bisa mendapatkan kunci, masalah ini, penulis Redis meminjam esensi algoritma rakit, melalui tabrakan pada waktu acak, waktu konflik dapat sangat berkurang, tetapi masalah ini tidak dapat dihindari dengan baik, terutama ketika kunci diperoleh untuk pertama kalinya, sehingga biaya waktu untuk memperoleh kunci meningkat.
- Jika 2 dari 5 node down, ketersediaan kunci akan sangat berkurang, pertama-tama, Anda harus menunggu hasil dari dua node yang jatuh ini habis sebelum kembali, dan hanya ada 3 node, dan klien harus mendapatkan kunci dari semua 3 node untuk memiliki kunci, yang juga lebih sulit.
- Jika ada partisi jaringan, maka mungkin ada situasi di mana klien tidak akan pernah bisa mendapatkan kunci.
Setelah menganalisis begitu banyak alasan, saya pikir poin paling kritis dari masalah Redlock adalah bahwa Redlock mengharuskan klien untuk memastikan konsistensi penulisan, dan 5 node backend benar-benar independen, dan semua klien harus mengoperasikan 5 node ini. Jika ada leader di antara 5 node, klien dapat menyinkronkan data leader selama klien mendapatkan kunci dari leader, sehingga tidak akan ada masalah seperti partisi, timeout, dan konflik. Oleh karena itu, untuk memastikan kebenaran kunci terdistribusi, saya pikir menggunakan layanan koordinasi terdistribusi dengan konsistensi yang kuat dapat menyelesaikan masalah dengan lebih baik.
Pertanyaan muncul lagi, berapa lama saya harus mengatur waktu kedaluwarsa? Cara mengatur waktu pembatalan terlalu singkat, dan kunci dilepaskan secara otomatis sebelum metode dieksekusi, maka akan ada masalah konkurensi. Jika memakan waktu terlalu lama, ulir lain yang terkunci mungkin harus menunggu lama.
Masalah ini juga ada dengan penggunaan database untuk mengimplementasikan kunci terdistribusi.
Pendekatan arus utama saat ini untuk masalah ini adalah mengatur waktu tunggu yang singkat untuk setiap kunci yang diperoleh, dan memulai utas untuk menyegarkan waktu tunggu penguncian setiap kali akan mencapai batas waktu. Akhiri utas ini bersamaan dengan melepaskan kunci. Misalnya, redisson, komponen kunci terdistribusi resmi dari redis, menggunakan solusi ini.
Keuntungan menggunakan caching untuk mengimplementasikan kunci terdistribusi
Performa bagus.
Kerugian menggunakan caching untuk mengimplementasikan kunci terdistribusi
Implementasinya terlalu bertanggung jawab, terlalu banyak faktor yang perlu dipertimbangkan.
Kunci terdistribusi berdasarkan implementasi Zookeeper
Kunci terdistribusi berdasarkan node yang dipesan sementara Zookeeper.
Ide umumnya adalah bahwa ketika setiap klien mengunci metode, node yang diurutkan sesaat yang unik dihasilkan di direktori node yang ditentukan yang sesuai dengan metode di zookeeper. Cara menentukan apakah akan mendapatkan kunci sederhana, Anda hanya perlu menentukan yang memiliki nomor seri terkecil di node yang dipesan. Saat kunci dilepaskan, cukup hapus simpul seketika. Pada saat yang sama, dapat menghindari masalah kebuntuan yang disebabkan oleh waktu henti layanan yang tidak dapat dilepaskan.
Mari kita lihat apakah Zookeeper dapat menyelesaikan masalah yang disebutkan sebelumnya.
- Kunci tidak mau dirilis? Menggunakan Zookeeper dapat secara efektif memecahkan masalah kunci yang tidak dilepaskan, karena saat membuat kunci, klien akan membuat node sementara di ZK, dan setelah klien mendapatkan kunci dan tiba-tiba menggantungnya (koneksi sesi terputus), maka node sementara akan dihapus secara otomatis. Klien lain bisa mendapatkan kunci lagi.
- Kunci non-pemblokiran? Setelah node berubah, Zookeeper akan memberi tahu klien, dan klien dapat memeriksa apakah node yang dibuatnya adalah nomor ordinal terkecil di antara semua node.
- Tidak bisa masuk kembali? Saat klien membuat simpul, klien secara langsung menulis informasi host dan informasi utas klien saat ini ke simpul, dan lain kali Anda ingin mendapatkan kunci, Anda dapat membandingkannya dengan data di simpul terkecil saat ini. Jika informasinya sama dengan milik Anda, maka Anda dapat langsung mendapatkan kuncinya, dan jika berbeda, buat simpul berurutan sementara untuk berpartisipasi dalam antrean.
Pertanyaan muncul lagi, kita tahu bahwa Zookeeper perlu disebarkan dalam klaster, apakah akan ada masalah sinkronisasi data seperti klaster Redis?
Zookeeper adalah komponen terdistribusi yang menjamin konsistensi yang lemah, yaitu konsistensi akhirnya.
Zookeeper menggunakan protokol sinkronisasi data yang disebut Protokol Berbasis Kuorum. Jika ada N server Zookeeper di kluster Zookeeper (N biasanya ganjil, 3 dapat memenuhi keandalan data dan memiliki kinerja baca dan tulis yang tinggi, dan 5 memiliki keseimbangan terbaik antara keandalan data dan performa baca dan tulis), maka operasi tulis pengguna pertama-tama disinkronkan ke server N/2 + 1, dan kemudian dikembalikan ke pengguna, mendorong pengguna untuk berhasil menulis. Protokol sinkronisasi data berdasarkan Protokol Berbasis Kuorum menentukan konsistensi kekuatan yang dapat didukung Zookeeper.
Dalam lingkungan terdistribusi, penyimpanan data yang memenuhi konsistensi yang kuat pada dasarnya tidak ada, dan mengharuskan semua simpul diperbarui secara sinkron saat memperbarui data satu simpul. Strategi sinkronisasi ini muncul di database replikasi sinkron master-slave. Namun, strategi sinkronisasi ini memiliki terlalu banyak dampak pada performa tulis dan jarang terlihat dalam praktik. Karena Zookeeper menulis node N/2+1 secara sinkron, dan node N/2 tidak diperbarui secara sinkron, Zookeeper tidak sangat konsisten.
Operasi pembaruan data pengguna tidak menjamin bahwa pembacaan berikutnya akan membaca nilai yang diperbarui, tetapi pada akhirnya akan menunjukkan konsistensi. Mengorbankan konsistensi tidak berarti sepenuhnya mengabaikan konsistensi data, jika tidak, data akan kacau, jadi tidak peduli seberapa tinggi ketersediaan sistemnya, tidak peduli seberapa baik distribusinya, itu tidak ada nilainya. Mengorbankan konsistensi hanya saja konsistensi yang kuat dalam database relasional tidak lagi diperlukan, tetapi selama sistem dapat mencapai konsistensi akhirnya.
Satu pertanyaan poin? Menggunakan Zookeeper dapat secara efektif memecahkan masalah satu titik, ZK dikerahkan dalam kelompok, selama lebih dari setengah mesin di kluster bertahan, layanan dapat diberikan ke dunia luar.
Masalah keadilan? Menggunakan Zookeeper dapat memecahkan masalah kunci yang adil, node sementara yang dibuat oleh klien di ZK teratur, dan setiap kali kunci dilepaskan, ZK dapat memberi tahu node terkecil untuk mendapatkan kunci, memastikan keadilan.
Pertanyaan muncul lagi, kita tahu bahwa Zookeeper perlu disebarkan dalam klaster, apakah akan ada masalah sinkronisasi data seperti klaster Redis?
Zookeeper adalah komponen terdistribusi yang menjamin konsistensi yang lemah, yaitu konsistensi akhirnya.
Zookeeper menggunakan protokol sinkronisasi data yang disebut Protokol Berbasis Kuorum. Jika ada N server Zookeeper di kluster Zookeeper (N biasanya ganjil, 3 dapat memenuhi keandalan data dan memiliki kinerja baca dan tulis yang tinggi, dan 5 memiliki keseimbangan terbaik antara keandalan data dan performa baca dan tulis), maka operasi tulis pengguna pertama-tama disinkronkan ke server N/2 + 1, dan kemudian dikembalikan ke pengguna, mendorong pengguna untuk berhasil menulis. Protokol sinkronisasi data berdasarkan Protokol Berbasis Kuorum menentukan konsistensi kekuatan yang dapat didukung Zookeeper.
Dalam lingkungan terdistribusi, penyimpanan data yang memenuhi konsistensi yang kuat pada dasarnya tidak ada, dan mengharuskan semua simpul diperbarui secara sinkron saat memperbarui data satu simpul. Strategi sinkronisasi ini muncul di database replikasi sinkron master-slave. Namun, strategi sinkronisasi ini memiliki terlalu banyak dampak pada performa tulis dan jarang terlihat dalam praktik. Karena Zookeeper menulis node N/2+1 secara sinkron, dan node N/2 tidak diperbarui secara sinkron, Zookeeper tidak sangat konsisten.
Operasi pembaruan data pengguna tidak menjamin bahwa pembacaan berikutnya akan membaca nilai yang diperbarui, tetapi pada akhirnya akan menunjukkan konsistensi. Mengorbankan konsistensi tidak berarti sepenuhnya mengabaikan konsistensi data, jika tidak, data akan kacau, jadi tidak peduli seberapa tinggi ketersediaan sistemnya, tidak peduli seberapa baik distribusinya, itu tidak ada nilainya. Mengorbankan konsistensi hanya saja konsistensi yang kuat dalam database relasional tidak lagi diperlukan, tetapi selama sistem dapat mencapai konsistensi akhirnya.
Apakah Zookeeper memenuhi konsistensi kausal tergantung pada bagaimana klien diprogram.
Praktik yang tidak memenuhi konsistensi kausal
- Proses A menulis sepotong data ke /z Zookeeper dan berhasil mengembalikan
- Proses A menginformasikan proses B bahwa A telah memodifikasi data /z
- B membaca data /z Penjaga Kebun Binatang
- Karena server Zookeeper yang terhubung ke B mungkin belum diperbarui dengan data tertulis A, maka B tidak akan dapat membaca data tertulis A
Praktik yang memenuhi konsistensi kausal
- Proses B mendengarkan perubahan data dalam /z di Zookeeper
- Proses A menulis sepotong data ke /z Zookeeper, dan sebelum berhasil kembali, Zookeeper perlu memanggil pendengar yang terdaftar di /z, dan pemimpin akan memberi tahu B tentang perubahan data
- Setelah metode respons peristiwa dari proses B ditanggapi, dibutuhkan data yang diubah, sehingga B pasti akan bisa mendapatkan nilai yang diubah
- Konsistensi kausal di sini mengacu pada konsistensi kausal antara Pemimpin dan B, yaitu, pemimpin memberi tahu data perubahan
Mekanisme mendengarkan peristiwa kedua juga merupakan metode yang harus digunakan untuk memprogram Zookeeper dengan benar, sehingga Zookeeper harus memenuhi konsistensi kausal
Oleh karena itu, ketika kita menerapkan kunci terdistribusi berdasarkan Zookeeper, kita harus menggunakan praktik memuaskan konsistensi kausal, yaitu utas yang menunggu kunci mendengarkan perubahan kunci Zookeeper, dan ketika kunci dilepaskan, Zookeeper akan memberi tahu utas tunggu yang memenuhi kondisi kunci yang adil.
Anda dapat menggunakan klien perpustakaan pihak ketiga Zookeeper secara langsung, yang merangkum layanan kunci peserta kembali.
Kunci terdistribusi yang diterapkan dengan ZK tampaknya sesuai persis dengan apa yang kami harapkan dari kunci terdistribusi di awal artikel ini. Namun, sebenarnya tidak, dan kunci terdistribusi yang diterapkan oleh Zookeeper sebenarnya memiliki kelemahan, yaitu kinerjanya mungkin tidak setinggi layanan caching. Karena setiap kali dalam proses membuat dan melepaskan kunci, node instan harus dibuat dan dihancurkan secara dinamis untuk mewujudkan fungsi kunci. Membuat dan menghapus node di ZK hanya dapat dilakukan melalui server pemimpin, dan kemudian data dibagikan dengan semua mesin pengikut.
Keuntungan menggunakan Zookeeper untuk menerapkan kunci terdistribusi
Secara efektif memecahkan masalah titik tunggal, masalah non-reentry, masalah non-pemblokiran, dan kegagalan kunci untuk melepaskan. Ini relatif sederhana untuk diterapkan.
Kerugian menggunakan Zookeeper untuk menerapkan kunci terdistribusi
Kinerjanya tidak sebaik menggunakan cache untuk mengimplementasikan kunci terdistribusi. Diperlukan pemahaman tentang prinsip-prinsip ZK.
Perbandingan ketiga opsi
Dari perspektif kemudahan pemahaman (dari rendah ke tinggi)
Database > Cache > Zookeeper
Dari perspektif kompleksitas implementasi (dari rendah ke tinggi)
Zookeeper > cache > database
Dari perspektif kinerja (dari tinggi ke rendah)
Caching > Zookeeper >= database
Dari perspektif keandalan (dari tinggi ke rendah)
Zookeeper > cache > database
|
Diposting pada 30/08/2018 15.04.32
|
|
|
|
Tuan tanah|
Diposting pada 22/09/2020 17.34.33
|
