PHP - Pilihan antara penguncian pesimis dan penguncian optimistik di bawah konkurensi tinggi

Question

Beritahu saya apa yang anda fikirkan dan sila betulkan saya jika saya salah. Prinsip pelaksanaan penguncian optimistik ialah operasi cas, dan kunci ringan di Jawa juga dilaksanakan berdasarkan cas. Masalah terbesar dengan penguncian pesimis ialah menyekat. Dalam pemahaman yang mendalam tentang mesin maya Java, disebutkan bahawa kunci ringan secara amnya lebih baik daripada kunci berat (mutex lock)...

怪我咯 · Answer

Ringkasnya, dalam keadaan biasa, penguncian optimistik sesuai untuk operasi yang hanya membaca dan tidak menulis, dan penguncian pesimis sesuai untuk operasi membaca dan menulis bercampur. Jika operasi tulis adalah sangat mudah dan pendek, seperti meningkatkan bilangan pelawat, anda juga boleh menggunakan penguncian optimistik, atau apabila tidak perlu memastikan bahawa data yang dibaca adalah yang terkini. Menggunakan penguncian optimistik sememangnya merupakan pilihan yang lebih baik dalam 80% kes.

CAS bergantung pada sokongan arahan CPU perkakasan untuk melaksanakan operasi tahap atom, jadi ia secara amnya lebih pantas dalam keadaan serentak yang tinggi Walau bagaimanapun, kelajuan ini bukan tanpa kekurangannya ialah apabila terdapat bacaan dan penulisan, cache CPU gagal kadar mungkin meningkat, melainkan CPU anda adalah teras tunggal (platform bukan Intel terbenam).

Ringkasnya, untuk meningkatkan prestasi konkurensi yang tinggi, kami masih memerlukan data terukur yang sebenar untuk menjelaskan masalah yang saya nyatakan di atas adalah semua teori. Semoga ia membantu.

阿神 · Answer

Sama ada kunci pesimis atau kunci optimistik, ia sebenarnya merupakan idea kawalan serentak, dan ia tidak terhad kepada pangkalan data Pilihan khusus kunci optimis dan kunci pesimis adalah berdasarkan senario perniagaan.
Kunci pesimistik:
Secara amnya, kunci pesimis yang kami gunakan adalah untuk menambah kunci eksklusif di peringkat pangkalan data Jika kunci berjaya, data boleh diubah suai dan penyerahan transaksi berjaya dibuka gagal, ini bermakna data sedang diubah suai. Jika anda menggunakan innodb mysql, berhati-hati untuk mematikan atribut auto-commit mysql, kerana mysql menggunakan mod autocommit secara lalai, maksudnya, apabila anda melakukan operasi kemas kini, MySQL akan segera menyerahkan hasilnya, dan juga memberi perhatian ke peringkat kunci , secara lalai innodb menggunakan kunci peringkat baris, tetapi kunci peringkat baris adalah berdasarkan indeks Jika sql anda tidak menggunakan indeks, maka mysql akan menggunakan kunci peringkat jadual untuk mengunci jadual. set autocommit=0Kebaikan dan Kelemahan:
Kunci pesimis ialah strategi konservatif "dapatkan kunci dahulu dan kemudian akses", yang memberikan jaminan untuk keselamatan pemprosesan data. Walau bagaimanapun, dari segi kecekapan, mekanisme penguncian akan menyebabkan overhed tambahan kepada pangkalan data dan meningkatkan peluang kebuntuan. Di samping itu, kerana tidak akan ada konflik dalam pemprosesan transaksi baca sahaja, tidak perlu menggunakan kunci, yang hanya akan meningkatkan beban sistem. Ia juga mengurangkan keselarian Jika transaksi mengunci baris data tertentu, urus niaga lain mesti menunggu transaksi diproses sebelum memproses baris data tersebut.

Kunci optimis:

Kunci optimis sebenarnya mengandaikan bahawa data tidak akan menyebabkan konflik dalam keadaan biasa, jadi apabila data diserahkan untuk kemas kini, konflik data akan dikesan secara rasmi Jika konflik ditemui, pengguna akan dikembalikan Maklumat ralat dan biarkan pengguna memutuskan perkara yang perlu dilakukan.
Secara amnya, ia boleh ditulis terus dalam lapisan logik kod Berbanding dengan kunci pesimis, apabila memproses pangkalan data, kunci optimis tidak menggunakan mekanisme kunci yang disediakan oleh pangkalan data. Ia biasanya dilaksanakan dengan menggunakan nombor versi atau cap waktu. Apabila menggunakan nombor versi, anda boleh menentukan nombor versi semasa pemulaan data, dan setiap operasi kemas kini pada data akan menambah 1 pada nombor versi. Dan tentukan sama ada nombor versi semasa ialah nombor versi terkini data. Seperti:

1.查询出商品信息
select (status,version) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

Kebaikan dan Kelemahan:

Penguncian yang optimis percaya bahawa kebarangkalian persaingan data adalah sangat kecil Oleh itu, teruskan secara terus yang mungkin dan jangan kunci sehingga penyerahan, jadi tiada kunci dan kebuntuan akan berlaku. Tetapi jika anda melakukan ini secara ringkas, anda mungkin masih menemui hasil yang tidak dijangka Contohnya, jika dua transaksi membaca baris tertentu pangkalan data dan kemudian menulisnya kembali ke pangkalan data selepas pengubahsuaian, anda akan menghadapi masalah.
Kegagalan penguncian optimistik adalah peristiwa kebarangkalian kecil dan memerlukan kerjasama pelbagai keadaan untuk berlaku. Seperti:

Aplikasi ini menggunakan strateginya sendiri untuk mengurus ID kunci utama. Sebagai contoh, adalah perkara biasa untuk mengambil nilai maksimum medan ID semasa + 1 sebagai ID baharu.
Nilai lalai versi medan nombor versi ialah 0.
Pengguna A membaca rekod tertentu dan bersedia untuk mengubah suainya. Rekod ini merupakan rekod dengan ID terbesar dan tidak pernah diubah suai sebelum ini. Versi ialah nilai lalai 0.
Selepas pengguna A selesai membaca, pengguna B kebetulan memadamkan rekod tersebut. Selepas itu, pengguna C memasukkan rekod baharu.
Pada masa ini, secara tidak sengaja, ID rekod yang baru dimasukkan adalah konsisten dengan ID rekod yang dibaca oleh pengguna A, dan kedua-dua nombor versi ialah nilai lalai 0.
Selepas pengguna C menyelesaikan operasi, pengguna A mengubah suai rekod yang lengkap dan menyimpannya. Memandangkan kedua-dua ID dan versi boleh dipadankan, pengguna A berjaya menyimpan. Walau bagaimanapun, rekod yang dimasukkan oleh pengguna C telah ditimpa.
Sebab asas kegagalan penguncian optimistik pada masa ini ialah strategi pengurusan ID kunci utama yang digunakan oleh aplikasi tidak serasi dengan penguncian optimistik pada tahap yang sangat kecil.

PHPz · Answer

Sebelum saya mula bekerja, saya mempunyai idea yang sama dengan penyoal Dalam kerja sebenar, sebenarnya tidak banyak perbezaan antara kedua-dua bahagian sistem yang paling memakan masa di bawah konkurensi tinggi yang sebenar adalah sambungan rangkaian, pertanyaan pangkalan data dan tidur aktif benang. Pada asasnya boleh diabaikan

我想大声告诉你 · Answer

Persoalan utama ialah, adakah fakta itu pesimis atau optimis?

Jika persaingan sumber anda sengit dan tidak boleh dikongsi, penguncian optimistik hanya akan mengalahkan harapan sejumlah besar permintaan.

Jika tiada persaingan untuk sumber anda (ini tidak semestinya berkaitan dengan tahap konkurensi, tetapi mempunyai kesan yang lebih besar kepada perniagaan), maka penguncian pesimis bermakna penguncian yang tidak perlu. Jika sumber itu pada asalnya boleh dikongsi (contohnya, sumber itu menyokong berbilang parti baca sahaja), maka penguncian pesimis bermakna kehilangan masa boleh guna asal.

Dalam pemahaman mendalam tentang mesin maya Java, disebutkan bahawa kunci ringan secara umumnya lebih baik daripada kunci kelas berat (kunci mutex); jika persaingan untuk kunci konkurensi tinggi adalah sengit, kunci ringan akan dikunci untuk tempoh yang lama masa. Putaran masa menggunakan CPU, menjadikan prestasi kunci ringan lebih perlahan daripada kunci kelas berat tradisional. Kemudian penguncian optimistik juga termasuk putaran dan cas, jadi penguncian pesimis di bawah konkurensi tinggi nampaknya bukan penyelesaian yang baik.

Saya tidak tahu banyak tentang JVM. Tetapi apakah maksud "Putaran dan cas juga wujud dalam penguncian optimistik"? cas ialah kaedah pelaksanaan kunci putaran Mengapakah ia perlu disejajarkan? Apakah maksud "juga"? Penguncian pesimis ialah operasi menyekat, tiada putaran, dan ia tidak terus menggunakan CPU.