Perisian Pertama Tempatan

negeri

Apabila web berkembang, bilangan elemen yang berinteraksi dan tunjukkan pengguna meningkat. Elemen ini mengubah skrin yang dilihat pengguna. Perkara yang menukar skrin boleh ditakrifkan sebagai 'keadaan.'

Sebagai contoh, dalam kes halaman web bermaklumat seperti halaman pendaratan, 'status' ialah satu maklumat untuk ditunjukkan.

Seterusnya, dalam kes GitHub, terdapat pelbagai maklumat seperti maklumat saya, maklumat repositori saya, bilangan bintang, dll. Memandangkan skrin yang ditunjukkan kepada pengguna berbeza-beza bergantung pada ini, semua ini boleh dianggap sebagai 'status '.

Sebagai contoh yang lebih kompleks, anda boleh mengambil contoh seperti Figma. Semua grafik pada skrin, seperti titik, garisan dan permukaan, semuanya 'keadaan'. Selain itu, fungsi kerjasama memerlukan anda berkongsi status orang selain diri anda.

Negeri & Data

Negeri adalah semua data. Maklumat tentang pengguna, maklumat tersuai pengguna, dsb. adalah semua data yang disimpan di suatu tempat, dan data ini tidak lama lagi menjadi keadaan skrin yang dilihat pengguna. Biasanya, data ini disimpan pada pelayan sebagai satu sumber kebenaran. Jika anda log masuk ke tapak web, ia akan disimpan sebagai satu baris dalam jadual pengguna pada pelayan tapak tersebut.

Data terlalu jauh

Web hari ini adalah rumit. Terdapat banyak butang dan banyak data yang dipaparkan pada satu skrin. Terdapat banyak maklumat yang ketepatan masanya penting. Setiap kali keadaan ini berubah, data mesti berulang-alik ke pelayan untuk memastikan konsistensi. Jika anda hanya perlu menerima 'halaman seterusnya' seminit, seperti dokumen, ia bukan masalah besar. Walau bagaimanapun, dalam kes seperti Notion di mana pengguna mengubah suai data secara berterusan, ia menjadi masalah besar. Jika saya terpaksa memuatkannya setiap kali saya menetapkan sesuatu seperti ciri pada halaman, saya akan kecewa

Kemas Kini Optimis

Fikirkan untuk mengklik butang suka pada laman media sosial seperti Instagram. Apabila saya mengklik suka, saya perlu pergi ke pelayan dan menyimpan maklumat yang saya suka siaran itu, tingkatkan bilangan suka untuk siaran itu sebanyak satu, dan kemudian dapatkan suka untuk siaran semasa dan tunjukkan kepada saya.

Tetapi pada Instagram, suka diklik dan bilangannya meningkat bersama-sama dengan animasi dalam 0.001 saat.

Ini boleh dilakukan dengan mengemas kini keadaan pelanggan sebelum maklumat itu sampai ke pelayan. Ideanya adalah untuk mengemas kini status pelanggan, dengan mengandaikan bahawa data seperti itu akan direkodkan dengan baik pada pelayan. Dalam kebanyakan kes, komunikasi dengan pelayan akan berjaya, jadi kami secara optimis menilai ini sebagai satu kejayaan.

Sudah tentu, terdapat kes di mana permintaan yang dihantar kepada pelayan gagal, jadi berhati-hati mesti diambil untuk memulihkan keadaan pelanggan sekiranya berlaku kegagalan.

Responsif Daripada Konsisten

Sangat munasabah untuk menunjukkan secara optimum sama ada saya mengklik butang suka atau tidak. Tetapi apabila saya mengklik, orang lain turut mengklik, jadi bilangan suka mungkin telah meningkat sebanyak satu atau lebih. Bagaimana cara saya menangani perkara ini?

Ini boleh diselesaikan dengan mudah dengan hanya mengabaikan sedikit ketekalan data. Jika siaran itu adalah siaran yang popular, tidak mungkin bilangan suka tidak meningkat semasa saya melihat siaran itu. Ini hanyalah dasar perisian. Untuk respons pantas, beberapa ketekalan data dikorbankan

Teorem CAP

Dalam kajian sistem teragih, terdapat teori CAP. Teori ini menyatakan bahawa apabila mengkonfigurasi sistem teragih, hanya dua daripada C, A dan P boleh digunakan.

C bermaksud Konsistensi. Tidak kira dari mana nod anda membaca data, anda mesti membaca data yang sama

A ialah Ketersediaan, yang bermaksud sama ada semua permintaan boleh dijawab walaupun jika nod mati.

P ialah Partition-tolerance, iaitu berapa banyak nod yang boleh beroperasi apabila sambungan rangkaian terputus dan sama ada ia boleh dipulihkan selepas sambungan rangkaian.

Menurut teori ini, akhirnya, tiga sistem mungkin: CA, AP dan CP.

CA

Secara teorinya, sistem teragih boleh memilih CA, tetapi kami memutuskan untuk tidak memanggil sistem yang tidak beroperasi apabila sambungan rangkaian terputus sebagai sistem teragih.

Pada akhirnya, jika ia adalah sistem teragih, P mesti dijamin.

AP

Ketersediaan Melebihi Konsisten

Apabila beberapa nod diputuskan sambungan daripada rangkaian, nilai nod yang disambungkan akan diturunkan walaupun semua nod tidak bersetuju dengan status terkini nilai tersebut. Oleh itu, data terkini mungkin tidak sepadan antara nod yang terputus. Walau bagaimanapun, pengguna boleh terus menggunakan perkhidmatan tersebut seolah-olah mereka menerima data terkini.

Contoh wakil ialah media sosial. Walaupun ini tidak mungkin berlaku dalam realiti, mari kita anggap bahawa sambungan rangkaian antara nod Instagram di Eropah dan nod di Asia hilang. Tidak mengapa bilangan pengikut, suka, dsb. yang dilihat oleh pengguna yang mengakses dari Asia dan pengguna yang mengakses dari Eropah adalah berbeza sedikit semasa tempoh gangguan ini. Tetapi fungsi itu akan tetap berfungsi.

CP

Konsisten Daripada Ketersediaan

Ini ialah sistem yang tidak bertindak balas kepada permintaan pengguna dalam situasi di mana data terkini tidak dapat dipastikan dalam situasi kegagalan rangkaian.

Contoh biasanya berkaitan dengan wang (urus niaga). Katakan terdapat pemutusan rangkaian dalam keadaan hanya tinggal satu bilik hotel dengan diskaun 50%. Dalam sistem AP, tempahan dibuat dengan mengandaikan bahawa kedua-dua bilik akan tersedia, jadi terdapat kemungkinan tempahan berlebihan. Sistem CP tidak pasti tentang status terkini data ini, jadi ia menangguhkan atau menolak permintaan.

Teorem PACELC

Teori CAP sebenarnya adalah teori tentang partition. Jika partition telah berlaku, anda perlu memilih A atau C.

Tetapi sebenarnya, dalam keadaan biasa, partition tidak berlaku. Teori yang boleh diaplikasikan dalam situasi sebegini ialah teori PACELC.

jika (P) maka (AC) lain (LC)

Dalam erti kata lain, dalam kes partition, pertimbangkan AC, jika tidak, pertimbangkan LC.

LC

Latensi & Ketekalan

Dalam keadaan biasa, sistem menukar Latensi dan Konsisten. Ia adalah teori yang hebat, tetapi sebenarnya, ia seperti kebenaran sepanjang kejuruteraan komputer

Memikirkan tentang jual beli bermakna melihat tahap kompromi tertentu antara kedua-dua standard ini.

Latensi boleh ditentukan secara intuitif daripada lambat kepada cepat, tetapi sukar untuk mengetahui secara intuitif apa itu konsistensi.

Konsisten yang Kuat

Konsistensi yang kuat boleh dirasai hanya dengan mendengar namanya. Tidak kira nod yang anda akses, anda mesti melihat data yang sama. Dalam erti kata lain, ketekalan hanya boleh dilakukan apabila semua nod mempunyai data yang sama.

Saya rasa anda boleh memikirkan tentang bank.

Konsisten Akhirnya

Ia adalah konsistensi yang dipanggil

Suatu hari nanti ia akan konsisten. Ini bermakna bahawa tidak semua pelanggan akan melihat nilai yang sama pada masa yang sama untuk perubahan tertentu, tetapi mereka akhirnya akan melihat nilai yang sama selepas penyegerakan selesai.

Oleh itu, bergantung pada ciri perisian, ia diputuskan sama ada untuk menjaga konsistensi sambil mengorbankan kependaman atau mengorbankan konsistensi untuk tindak balas yang cepat.

Atas ialah kandungan terperinci Perisian Pertama Tempatan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!