Datang ke produk yang telah dibangunkan selama lebih dari satu dekad, sama sekali tidak menghairankan untuk mencari teknologi lapuk di dalamnya. Tetapi bagaimana jika dalam enam bulan anda perlu mengekalkan beban 10 kali lebih tinggi, dan kos jatuh akan meningkat ratusan kali ganda? Dalam kes ini, anda memerlukan Jurutera Muatan Tinggi yang hebat. Tetapi dengan ketiadaan pembantu rumah, mereka mengamanahkan saya untuk menyelesaikan masalah itu. Di bahagian pertama artikel saya akan memberitahu anda bagaimana kami berpindah dari Redis ke Redis-cluster, dan di bahagian kedua saya akan memberi nasihat tentang cara mula menggunakan cluster dan apa yang perlu diberi perhatian apabila menggunakannya.

Pemilihan teknologi

Adakah ia begitu teruk? berasingan Redis (standalone redis) dalam konfigurasi 1 tuan dan N hamba? Mengapa saya memanggilnya teknologi usang?

Tidak, Redis tidak seteruk itu... Namun, terdapat beberapa kekurangan yang tidak boleh diabaikan.

• Pertama, Redis tidak menyokong mekanisme pemulihan bencana selepas kegagalan induk. Untuk menyelesaikan masalah ini, kami menggunakan konfigurasi dengan pemindahan automatik VIP kepada tuan baharu, menukar peranan salah seorang hamba dan menukar yang lain. Mekanisme ini berfungsi, tetapi ia tidak boleh dipanggil penyelesaian yang boleh dipercayai. Pertama, penggera palsu berlaku, dan kedua, ia boleh guna, dan selepas operasi tindakan manual diperlukan untuk mengecas spring.

• Kedua, hanya mempunyai seorang tuan membawa kepada masalah sharding. Kami terpaksa mencipta beberapa kluster bebas "1 tuan dan hamba N," kemudian mengedarkan pangkalan data secara manual di antara mesin ini dan berharap esok salah satu pangkalan data tidak akan membengkak sehingga ia perlu dialihkan ke contoh yang berasingan.

Apakah pilihan?

• Penyelesaian yang paling mahal dan terkaya ialah Redis-Enterprise. Ini adalah penyelesaian kotak dengan sokongan teknikal penuh. Walaupun pada hakikatnya ia kelihatan ideal dari sudut pandangan teknikal, ia tidak sesuai dengan kami atas sebab ideologi.
• Redis-cluster. Di luar kotak terdapat sokongan untuk master failover dan sharding. Antara muka hampir tidak berbeza daripada versi biasa. Ia kelihatan menjanjikan, kita akan bercakap tentang perangkap kemudian.
• Tarantool, Memcache, Aerospike dan lain-lain. Semua alat ini melakukan perkara yang hampir sama. Tetapi masing-masing ada kekurangannya sendiri. Kami memutuskan untuk tidak meletakkan semua telur kami dalam satu bakul. Kami menggunakan Memcache dan Tarantool untuk tugas lain, dan, melihat ke hadapan, saya akan mengatakan bahawa dalam amalan kami terdapat lebih banyak masalah dengan mereka.

Spesifikasi penggunaan

Mari kita lihat masalah yang telah kami selesaikan secara sejarah dengan Redis dan fungsi yang kami gunakan:

• Cache sebelum permintaan kepada perkhidmatan jauh seperti 2GIS | Golang
  

  DAPATKAN SET MGET MSET "PILIH DB"

• Cache sebelum MYSQL | PHP
  

  GET SET MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• Storan utama untuk perkhidmatan bekerja dengan sesi dan koordinat pemandu | Golang
  

  GET SET MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" SCAN

Seperti yang anda lihat, tiada matematik yang lebih tinggi. Lalu apakah kesukarannya? Mari lihat setiap kaedah secara berasingan.

Kaedah
Описание
Ciri-ciri Redis-cluster
keputusan

DAPATKAN SET
Tulis/baca kekunci

MGET MSET
Tulis/baca berbilang kunci
Kekunci akan berada pada nod yang berbeza. Perpustakaan sedia boleh melakukan pelbagai operasi hanya dalam satu nod
Gantikan MGET dengan saluran paip operasi N GET

PILIH DB
Pilih pangkalan yang akan kami bekerjasama
Tidak menyokong berbilang pangkalan data
Letakkan semuanya dalam satu pangkalan data. Tambahkan awalan pada kekunci

SCAN
Pergi melalui semua kunci dalam pangkalan data
Memandangkan kami mempunyai satu pangkalan data, melalui semua kunci dalam kelompok adalah terlalu mahal
Kekalkan invarian dalam satu kunci dan lakukan HSCAN pada kunci ini. Atau menolak sepenuhnya

GEO
Operasi dengan geokey
Geokey tidak dipecahkan

KUNCI MENGIKUT CORAK
Mencari kunci mengikut corak
Memandangkan kami mempunyai satu pangkalan data, kami akan mencari merentasi semua kunci dalam kelompok. Terlalu mahal
Tolak atau kekalkan invarian, seperti dalam kes SCAN

Redis vs Redis-cluster

Apa yang kita rugi dan apa yang kita perolehi apabila bertukar kepada kluster?

• Kelemahan: kami kehilangan fungsi beberapa pangkalan data.
  • Jika kita ingin menyimpan data yang tidak berkaitan secara logik dalam satu kelompok, kita perlu membuat tongkat dalam bentuk awalan.
  • Kami kehilangan semua operasi "asas", seperti SCAN, DBSIZE, CLEAR DB, dsb.
  • Pelbagai operasi telah menjadi lebih sukar untuk dilaksanakan kerana ia mungkin memerlukan akses kepada beberapa nod.
• Plus:
  • Toleransi kesalahan dalam bentuk master failover.
  • Sharding di sebelah Redis.
  • Pindahkan data antara nod secara atom dan tanpa masa henti.
  • Tambah dan agihkan semula kapasiti dan beban tanpa masa henti.

Saya akan membuat kesimpulan bahawa jika anda tidak perlu menyediakan tahap toleransi kesalahan yang tinggi, maka berpindah ke kluster tidak berbaloi, kerana ia boleh menjadi tugas yang tidak remeh. Tetapi jika anda pada mulanya memilih antara versi berasingan dan versi kluster, maka anda harus memilih kluster, kerana ia tidak lebih buruk dan, sebagai tambahan, akan melegakan anda daripada beberapa sakit kepala

Bersedia untuk bergerak

Mari kita mulakan dengan keperluan untuk bergerak:

• Ia sepatutnya lancar. Perhentian perkhidmatan selama 5 minit tidak sesuai dengan kami.
• Ia sepatutnya selamat dan beransur-ansur yang mungkin. Saya mahu mengawal keadaan. Kami tidak mahu membuang segala-galanya sekaligus dan berdoa untuk butang tarik balik.
• Kehilangan data minimum apabila bergerak. Kami faham bahawa ia akan menjadi sangat sukar untuk bergerak secara atom, jadi kami membenarkan beberapa penyahsegerakan antara data dalam Redis biasa dan berkelompok.

Penyelenggaraan kluster

Sejurus sebelum bergerak, kita harus memikirkan sama ada kita boleh menyokong kluster:

• Carta. Kami menggunakan Prometheus dan Grafana untuk menggambarkan beban CPU, penggunaan memori, bilangan pelanggan, bilangan GET, SET, operasi AUTH, dsb.
• Kepakaran. Bayangkan esok anda akan mempunyai kumpulan besar di bawah tanggungjawab anda. Jika ia rosak, tiada sesiapa selain anda boleh memperbaikinya. Jika dia mula perlahan, semua orang akan berlari ke arah anda. Jika anda perlu menambah sumber atau mengagihkan semula beban, kembali kepada anda. Untuk tidak menjadi kelabu pada usia 25 tahun, adalah dinasihatkan untuk menyediakan kes ini dan menyemak terlebih dahulu bagaimana teknologi akan bertindak di bawah tindakan tertentu. Mari bincangkan perkara ini dengan lebih terperinci dalam bahagian "Kepakaran".
• Pemantauan dan makluman. Apabila kluster rosak, anda mahu menjadi orang pertama yang mengetahui tentangnya. Di sini kami mengehadkan diri kami kepada pemberitahuan bahawa semua nod mengembalikan maklumat yang sama tentang keadaan kluster (ya, ia berlaku secara berbeza). Dan masalah lain boleh diperhatikan dengan lebih cepat dengan makluman daripada perkhidmatan pelanggan Redis.

Bergerak

Bagaimana kita akan bergerak:

• Pertama sekali, anda perlu menyediakan perpustakaan untuk bekerja dengan kluster. Kami mengambil go-redis sebagai asas untuk versi Go dan mengubahnya sedikit untuk disesuaikan dengan diri kami sendiri. Kami melaksanakan Pelbagai kaedah melalui saluran paip, dan juga membetulkan sedikit peraturan untuk permintaan berulang. Versi PHP mempunyai lebih banyak masalah, tetapi kami akhirnya menyelesaikan pada php-redis. Mereka baru-baru ini memperkenalkan sokongan kluster dan ia kelihatan bagus pada pendapat kami.
• Seterusnya anda perlu menggunakan kluster itu sendiri. Ini dilakukan secara literal dalam dua arahan berdasarkan fail konfigurasi. Kami akan membincangkan tetapan dengan lebih terperinci di bawah.
• Untuk bergerak secara beransur-ansur kami menggunakan mod kering. Memandangkan kami mempunyai dua versi pustaka dengan antara muka yang sama (satu untuk versi biasa, satu lagi untuk kluster), tiada kos untuk membuat pembalut yang akan berfungsi dengan versi berasingan dan secara selari menduplikasi semua permintaan kepada kluster, bandingkan jawapan dan tulis percanggahan dalam log (dalam kes kami dalam NewRelic). Oleh itu, walaupun versi kluster pecah semasa pelancaran, pengeluaran kami tidak akan terjejas.
• Setelah melancarkan kluster dalam mod kering, kita boleh melihat dengan tenang pada graf percanggahan tindak balas. Jika kadar ralat perlahan tetapi pasti bergerak ke arah beberapa pemalar kecil, maka semuanya baik-baik saja. Mengapa masih terdapat percanggahan? Kerana rakaman dalam versi berasingan berlaku sedikit lebih awal daripada dalam kelompok, dan disebabkan mikrolag, data mungkin menyimpang. Apa yang tinggal ialah melihat log percanggahan, dan jika semuanya dijelaskan oleh ketidakatoman rekod, maka kita boleh meneruskan.
• Kini anda boleh menukar mod kering ke arah yang bertentangan. Kami akan menulis dan membaca daripada kluster, dan menduplikasikannya ke dalam versi yang berasingan. Untuk apa? Pada minggu hadapan saya ingin memerhatikan kerja kluster. Jika tiba-tiba ternyata terdapat masalah pada beban puncak, atau kami tidak mengambil kira sesuatu, kami sentiasa mempunyai pemulangan kecemasan kepada kod lama dan data semasa terima kasih kepada mod kering.
• Yang tinggal hanyalah untuk melumpuhkan mod kering dan bongkar versi berasingan.

Kepakaran

Pertama, secara ringkas tentang reka bentuk kluster.

Pertama sekali, Redis ialah kedai nilai utama. Rentetan sewenang-wenangnya digunakan sebagai kunci. Nombor, rentetan dan keseluruhan struktur boleh digunakan sebagai nilai. Terdapat banyak yang terakhir, tetapi untuk memahami struktur umum ini tidak penting bagi kami.
Tahap abstraksi seterusnya selepas kekunci ialah slot (SLOT). Setiap kunci kepunyaan satu daripada 16 slot. Terdapat beberapa bilangan kunci di dalam setiap slot. Oleh itu, semua kunci dibahagikan kepada 383 set terputus.

Seterusnya, mesti ada N nod induk dalam kluster. Setiap nod boleh dianggap sebagai contoh Redis berasingan yang mengetahui segala-galanya tentang nod lain dalam kelompok. Setiap nod induk mengandungi beberapa slot. Setiap slot hanya dimiliki oleh satu nod induk. Semua slot perlu diedarkan antara nod. Jika beberapa slot tidak diperuntukkan, maka kunci yang disimpan di dalamnya tidak akan dapat diakses. Adalah masuk akal untuk menjalankan setiap nod induk pada mesin logik atau fizikal yang berasingan. Perlu diingat juga bahawa setiap nod hanya berjalan pada satu teras, dan jika anda ingin menjalankan berbilang contoh Redis pada mesin logik yang sama, pastikan ia berjalan pada teras yang berbeza (kami belum mencuba ini, tetapi secara teori ia sepatutnya berfungsi) . Pada asasnya, nod induk menyediakan sharding biasa, dan lebih banyak nod induk membenarkan permintaan tulis dan baca untuk skala.

Selepas semua kunci diedarkan di antara slot, dan slot bertaburan di antara nod induk, bilangan nod hamba boleh ditambah pada setiap nod induk. Dalam setiap pautan tuan-hamba sedemikian, replikasi biasa akan berfungsi. Hamba diperlukan untuk skala permintaan baca dan untuk failover sekiranya berlaku kegagalan master.

Sekarang mari kita bercakap tentang operasi yang lebih baik untuk dapat dilakukan.

Kami akan mengakses sistem melalui Redis-CLI. Memandangkan Redis tidak mempunyai satu titik masuk, anda boleh melakukan operasi berikut pada mana-mana nod. Pada setiap titik saya secara berasingan menarik perhatian kepada kemungkinan melakukan operasi di bawah beban.

• Perkara pertama dan paling penting yang kita perlukan ialah operasi nod kluster. Ia mengembalikan keadaan kluster, menunjukkan senarai nod, peranannya, pengedaran slot, dsb. Maklumat lanjut boleh diperoleh menggunakan maklumat kluster dan slot kluster.
• Alangkah baiknya jika dapat menambah dan mengalih keluar nod. Untuk tujuan ini terdapat operasi jumpa cluster dan lupa cluster. Sila ambil perhatian bahawa klaster lupa mesti digunakan pada SETIAP nod, kedua-dua induk dan replika. Dan pertemuan kluster hanya perlu dipanggil pada satu nod. Perbezaan ini boleh membingungkan, jadi sebaiknya ketahui tentangnya sebelum anda menyiarkan secara langsung dengan kluster anda. Menambah nod dilakukan dengan selamat dalam pertempuran dan tidak menjejaskan operasi kluster dalam apa jua cara (yang logik). Jika anda akan mengalih keluar nod daripada kluster, anda harus memastikan bahawa tiada slot yang tinggal padanya (jika tidak, anda berisiko kehilangan akses kepada semua kekunci pada nod ini). Juga, jangan padamkan tuan yang mempunyai hamba, jika tidak undi yang tidak perlu untuk tuan baru akan dilakukan. Jika nod tidak lagi mempunyai slot, maka ini adalah masalah kecil, tetapi mengapa kita memerlukan pilihan tambahan jika kita boleh memadamkan hamba terlebih dahulu.
• Jika anda perlu menukar kedudukan induk dan hamba secara paksa, maka perintah failover kelompok akan dilakukan. Apabila memanggilnya dalam pertempuran, anda perlu memahami bahawa tuan tidak akan tersedia semasa operasi. Biasanya suis berlaku dalam masa kurang dari satu saat, tetapi bukan atom. Anda boleh menjangkakan bahawa beberapa permintaan kepada tuan akan gagal pada masa ini.
• Sebelum mengalih keluar nod daripada kluster, sepatutnya tiada slot yang tinggal padanya. Adalah lebih baik untuk mengagihkannya menggunakan perintah reshard kelompok. Slot akan dipindahkan dari satu master ke master yang lain. Keseluruhan operasi mungkin mengambil masa beberapa minit, ia bergantung kepada jumlah data yang dipindahkan, tetapi proses pemindahan adalah selamat dan tidak menjejaskan operasi kluster dalam apa jua cara. Oleh itu, semua data boleh dipindahkan dari satu nod ke nod lain secara langsung di bawah beban, dan tanpa perlu risau tentang ketersediaannya. Walau bagaimanapun, terdapat juga kehalusan. Pertama, pemindahan data dikaitkan dengan beban tertentu pada nod penerima dan penghantar. Jika nod penerima sudah banyak dimuatkan pada pemproses, maka anda tidak seharusnya memuatkannya dengan menerima data baharu. Kedua, sebaik sahaja tiada satu slot yang tinggal pada tuan pengirim, semua hambanya akan segera pergi ke tuan tempat slot ini dipindahkan. Dan masalahnya ialah semua hamba ini akan mahu menyegerakkan data sekaligus. Dan anda akan bernasib baik jika penyegerakan separa dan bukannya penyegerakan lengkap. Ambil kira perkara ini dan gabungkan operasi pemindahan slot dan melumpuhkan/memindahkan hamba. Atau berharap anda mempunyai margin keselamatan yang mencukupi.
• Apakah yang perlu anda lakukan jika, semasa pemindahan, anda mendapati bahawa anda telah kehilangan slot anda di suatu tempat? Saya harap masalah ini tidak menjejaskan anda, tetapi jika ia berlaku, terdapat operasi pembetulan kluster. Sekurang-kurangnya, dia akan menyerakkan slot merentasi nod dalam susunan rawak. Saya mengesyorkan menyemak operasinya dengan terlebih dahulu mengeluarkan nod dengan slot yang diedarkan daripada kluster. Memandangkan data dalam slot yang tidak diperuntukkan sudah tidak tersedia, sudah terlambat untuk bimbang tentang masalah dengan ketersediaan slot ini. Sebaliknya, operasi tidak akan menjejaskan slot yang diedarkan.
• Satu lagi operasi berguna ialah monitor. Ia membolehkan anda melihat dalam masa nyata keseluruhan senarai permintaan yang pergi ke nod. Selain itu, anda boleh melihatnya dan mengetahui sama ada terdapat trafik yang diperlukan.

Ia juga bernilai menyebut prosedur master failover. Pendek kata, ia wujud, dan, pada pendapat saya, ia berfungsi dengan baik. Walau bagaimanapun, jangan fikir bahawa jika anda mencabut palam kord kuasa pada mesin dengan nod induk, Redis akan bertukar serta-merta dan pelanggan tidak akan menyedari kehilangan itu. Dalam amalan saya, penukaran berlaku dalam beberapa saat. Pada masa ini, beberapa data tidak akan tersedia: ketiadaan induk dikesan, nod mengundi yang baharu, hamba ditukar, data disegerakkan. Cara terbaik untuk memastikan sendiri bahawa skim itu berfungsi adalah dengan menjalankan latihan tempatan. Naikkan kluster pada komputer riba anda, berikan beban minimum, simulasikan ranap sistem (contohnya, dengan menyekat port) dan nilaikan kelajuan pensuisan. Pada pendapat saya, hanya selepas bermain dengan cara ini selama satu atau dua hari anda boleh yakin dengan operasi teknologi. Baiklah, atau berharap perisian yang separuh daripada Internet gunakan mungkin berfungsi.

Konfigurasi

Selalunya, konfigurasi ialah perkara pertama yang anda perlukan untuk mula bekerja dengan alat. Dan apabila semuanya berfungsi, anda tidak mahu menyentuh konfigurasi pun. Ia memerlukan sedikit usaha untuk memaksa diri anda kembali ke tetapan dan melaluinya dengan teliti. Dalam ingatan saya, kami mempunyai sekurang-kurangnya dua kegagalan yang serius disebabkan oleh ketidakpedulian terhadap konfigurasi. Beri perhatian khusus kepada perkara berikut:

• masa tamat 0
  Masa selepas sambungan tidak aktif ditutup (dalam saat). 0 - jangan tutup
  Tidak semua perpustakaan kami dapat menutup sambungan dengan betul. Dengan melumpuhkan tetapan ini, kami berisiko mencapai had bilangan pelanggan. Sebaliknya, jika terdapat masalah sedemikian, maka penamatan automatik sambungan yang hilang akan menutupinya, dan kami mungkin tidak perasan. Selain itu, anda tidak seharusnya mendayakan tetapan ini apabila menggunakan sambungan berterusan.
• Jimat xy & appendonly ya
  Menyimpan syot kilat RDB.
  Kami akan membincangkan isu RDB/AOF secara terperinci di bawah.
• stop-writes-on-bgsave-error no & slave-serve-basi-data ya
  Jika didayakan, jika petikan RDB rosak, induk akan berhenti menerima permintaan perubahan. Jika sambungan kepada tuan terputus, hamba boleh terus membalas permintaan (ya). Atau akan berhenti bertindak balas (tidak)
  Kami tidak berpuas hati dengan situasi di mana Redis bertukar menjadi labu.
• repl-ping-hamba-tempoh 5
  Selepas tempoh masa ini, kita akan mula bimbang bahawa tuan telah rosak dan sudah tiba masanya untuk menjalankan prosedur failover.
  Anda perlu mencari keseimbangan secara manual antara positif palsu dan mencetuskan failover. Dalam amalan kami ini adalah 5 saat.
• repl-backlog-saiz 1024mb & epl-backlog-ttl 0
  Kami boleh menyimpan data sebanyak ini dalam penimbal untuk replika yang gagal. Jika penimbal kehabisan, anda perlu menyegerakkan sepenuhnya.
  Amalan mencadangkan bahawa adalah lebih baik untuk menetapkan nilai yang lebih tinggi. Terdapat banyak sebab mengapa replika mungkin mula ketinggalan. Jika ia ketinggalan, maka kemungkinan besar tuan anda sudah bergelut untuk mengatasinya, dan penyegerakan penuh akan menjadi yang terakhir.
• maxclients 10000
  Bilangan maksimum pelanggan sekali sahaja.
  Mengikut pengalaman kami, adalah lebih baik untuk menetapkan nilai yang lebih tinggi. Redis mengendalikan 10k sambungan dengan baik. Cuma pastikan terdapat soket yang mencukupi pada sistem.
• maxmemory-policy volatile-ttl
  Peraturan yang mana kekunci dipadamkan apabila had memori yang tersedia dicapai.
  Apa yang penting di sini bukanlah peraturan itu sendiri, tetapi pemahaman tentang bagaimana ini akan berlaku. Redis boleh dipuji kerana keupayaannya berfungsi secara normal apabila had ingatan dicapai.

Masalah RDB dan AOF

Walaupun Redis sendiri menyimpan semua maklumat dalam RAM, terdapat juga mekanisme untuk menyimpan data ke cakera. Lebih tepat lagi, tiga mekanisme:

• RDB-snapshot - petikan lengkap semua data. Tetapkan menggunakan konfigurasi SAVE XY dan baca "Simpan petikan penuh semua data setiap X saat jika sekurang-kurangnya kekunci Y telah berubah."
• Fail tambah sahaja - senarai operasi mengikut susunan ia dilakukan. Menambah operasi masuk baharu pada fail setiap X saat atau setiap operasi Y.
• RDB dan AOF adalah gabungan dua sebelumnya.

Semua kaedah mempunyai kelebihan dan kekurangannya, saya tidak akan menyenaraikan semuanya, saya hanya akan menarik perhatian kepada perkara yang, pada pendapat saya, tidak jelas.

Pertama, menyimpan petikan RDB memerlukan panggilan FORK. Jika terdapat banyak data, ini boleh menggantung semua Redis untuk tempoh beberapa milisaat hingga satu saat. Di samping itu, sistem perlu memperuntukkan memori untuk syot kilat sedemikian, yang membawa kepada keperluan untuk menyimpan bekalan RAM berganda pada mesin logik: jika 8 GB diperuntukkan untuk Redis, maka 16 GB harus tersedia pada mesin maya dengan ia.

Kedua, terdapat masalah dengan penyegerakan separa. Dalam mod AOF, apabila hamba disambungkan semula, bukannya penyegerakan separa, penyegerakan penuh boleh dilakukan. Mengapa ini berlaku, saya tidak faham. Tetapi ia patut diingati ini.

Kedua-dua perkara ini sudah membuatkan kita berfikir sama ada kita benar-benar memerlukan data ini pada cakera jika semuanya sudah diduplikasi oleh hamba. Data hanya boleh hilang jika semua hamba gagal, dan ini adalah masalah tahap "kebakaran dalam DC". Sebagai kompromi, anda boleh mencadangkan untuk menyimpan data hanya pada hamba, tetapi dalam kes ini anda perlu memastikan bahawa hamba ini tidak akan menjadi tuan semasa pemulihan bencana (untuk ini terdapat tetapan keutamaan hamba dalam konfigurasi mereka). Bagi diri kita sendiri, dalam setiap kes tertentu kita memikirkan sama ada perlu untuk menyimpan data ke cakera, dan selalunya jawapannya ialah "tidak".

Kesimpulan

Sebagai kesimpulan, saya berharap saya dapat memberikan gambaran umum tentang cara redis-cluster berfungsi untuk mereka yang tidak pernah mendengarnya sama sekali, dan juga menarik perhatian kepada beberapa perkara yang tidak jelas bagi mereka yang telah menggunakannya untuk masa yang lama.
Terima kasih atas masa anda dan, seperti biasa, ulasan mengenai topik itu dialu-alukan.

Sumber: www.habr.com