Dalam sistem serentak teragih, pangkalan data dan ketekalan data cache ialah kesukaran teknikal yang mencabar. Dengan mengandaikan terdapat penyelesaian transaksi teragih gred industri yang lengkap, maka konsistensi pangkalan data dan data cache akan dapat diselesaikan dengan mudah Malah, transaksi yang diedarkan pada masa ini tidak matang.
Dalam pangkalan data dan penyelesaian ketekalan data cache, terdapat pelbagai suara.
Pangkalan data operasi dahulu dan kemudian cache atau cache dahulu dan kemudian pangkalan data
Sekiranya cache dikemas kini atau dipadamkan
Dalam sistem serentak, dalam senario dwi-tulis pangkalan data dan cache, untuk mengejar keselarasan yang lebih besar, operasi pada pangkalan data dan cache jelas tidak akan dilakukan secara serentak. Operasi terdahulu berjaya dan operasi kedua dilakukan dalam cara tak segerak.
Sebagai penyelesaian storan data gred industri yang matang, pangkalan data hubungan mempunyai mekanisme pemprosesan transaksi yang lengkap Setelah data diletakkan pada cakera, tanpa mengira kegagalan perkakasan, ia boleh dikatakan secara bertanggungjawab bahawa data itu tidak akan berlaku hilang.
Cache yang dipanggil tidak lebih daripada data yang disimpan dalam memori Setelah perkhidmatan dimulakan semula, semua data cache akan hilang. Oleh kerana ia dipanggil caching, bersiaplah untuk kehilangan data cache pada setiap masa. Walaupun Redis mempunyai mekanisme kegigihan, bolehkah ia menjamin 100% kegigihan? Redis menyimpan data ke cakera secara tidak segerak Cache adalah cache, dan pangkalan data adalah dua perkara yang berbeza. Menggunakan cache sebagai pangkalan data adalah sangat berbahaya.
Dari perspektif keselamatan data, pangkalan data dikendalikan dahulu, dan kemudian cache dikendalikan secara tak segerak untuk bertindak balas kepada permintaan pengguna.
Sama ada cache dikemas kini atau dipadamkan, sepadan dengan gaya malas dan gaya penuh Dari perspektif amalan keselamatan benang, pemadaman operasi cache adalah agak sukar. Jika prestasi pertanyaan berpuas hati di bawah premis pemadaman cache, maka pemadaman cache lebih diutamakan.
Walaupun mengemas kini cache boleh meningkatkan kecekapan pertanyaan, data kotor serentak yang disebabkan oleh urutan lebih menyusahkan untuk diproses Mukadimah memperkenalkan perisian tengah mesej lain seperti MQ, jadi ia tidak disyorkan melainkan perlu.
Kunci untuk memahami masalah yang disebabkan oleh konkurensi benang adalah terlebih dahulu memahami gangguan sistem Apabila sistem pengendalian menjadualkan tugas, gangguan berlaku pada bila-bila masa oleh ketidakkonsistenan data benang. Mengambil CPU 4 dan 8 utas sebagai contoh, sehingga 8 utas boleh diproses pada masa yang sama Walau bagaimanapun, sistem pengendalian menguruskan lebih daripada 8 utas, jadi utas berjalan dalam cara yang kelihatan selari.
Dalam persekitaran bukan serentak, tiada salahnya menanyakan data dengan cara berikut: tanya cache dahulu. Jika data cache tidak wujud, Tanya pangkalan data, kemas kini cache dan kembalikan hasilnya.
public BuOrder getOrder(Long orderId) {
String key = ORDER_KEY_PREFIX + orderId;
BuOrder buOrder = RedisUtils.getObject(key, BuOrder.class);
if (buOrder != null) {
return buOrder;
}
BuOrder order = getById(orderId);
RedisUtils.setObject(key, order, 5, TimeUnit.MINUTES);
return order;
}Jika terdapat kecacatan serius dalam persekitaran berkonkurensi tinggi: apabila cache gagal, sejumlah besar permintaan pertanyaan masuk, semuanya mencecah DB dalam sekelip mata Sumber sambungan pangkalan data keletihan, dan pelanggan bertindak balas dengan Ralat 500, atau lebih serius, pangkalan data mungkin berada di bawah tekanan terlalu banyak dan perkhidmatan mungkin ditutup.
Oleh itu, dalam persekitaran serentak, kod di atas perlu diubah suai dan kunci yang diedarkan digunakan. Apabila sebilangan besar permintaan masuk, benang yang memperoleh kunci mempunyai peluang untuk mengakses pangkalan data untuk menanyakan data, dan benang yang tinggal disekat. Apabila data disoal dan cache dikemas kini, kunci kemudiannya dilepaskan. Benang menunggu menyemak semula cache dan mendapati bahawa data boleh diperolehi dan bertindak balas terus kepada data cache.
Kunci teragih disebut di sini, jadi patutkah kita menggunakan kunci meja atau kunci baris? Gunakan kunci baris yang diedarkan untuk meningkatkan konkurensi; gunakan mekanisme semakan kedua untuk memastikan bahawa urutan yang menunggu untuk mendapatkan kunci dapat mengembalikan hasil dengan cepat
@Override
public BuOrder getOrder(Long orderId) {
/* 如果缓存不存在，则添加分布式锁更新缓存 */
String key = ORDER_KEY_PREFIX + orderId;
BuOrder order = RedisUtils.getObject(key, BuOrder.class);
if (order != null) {
return order;
}
String orderLock = ORDER_LOCK + orderId;
RLock lock = redissonClient.getLock(orderLock);
if (lock.tryLock()) {
order = RedisUtils.getObject(key, BuOrder.class);
if (order != null) {
LockOptional.ofNullable(lock).ifLocked(RLock::unlock);
return order;
}
BuOrder buOrder = getById(orderId);
RedisUtils.setObject(key, buOrder, 5, TimeUnit.MINUTES);
LockOptional.ofNullable(lock).ifLocked(RLock::unlock);
}
return RedisUtils.getObject(key, BuOrder.class);
}public Boolean editOrder(BuOrder order) {
/* 更新数据库 */
updateById(order);
/* 删除缓存 */
RedisUtils.deleteObject(OrderServiceImpl.ORDER_KEY_PREFIX + order.getOrderId());
return true;
}public Boolean editOrder(BuOrder order) {
String orderLock = ORDER_LOCK + order.getOrderId();
RLock lock = redissonClient.getLock(orderLock);
try {
/* 超时未获取到锁，快速失败，用户端重试 */
if (lock.tryLock(1, TimeUnit.SECONDS)) {
/* 更新数据库 */
updateById(order);
/* 删除缓存 */
RedisUtils.deleteObject(OrderServiceImpl.ORDER_KEY_PREFIX + order.getOrderId());
/* 释放锁 */
LockOptional.ofNullable(lock).ifLocked(RLock::unlock);
return true;
}
} catch (InterruptedException e) {
e.printStackTrace();
}
return false;
}<dependency> <groupId>xin.altitude.cms</groupId> <artifactId>ucode-cms-common</artifactId> <version>1.4.3.2</version> </dependency>
Lakukan operasi seterusnya berdasarkan status kunci. LockOptional
(2) Minta A untuk menanyakan pangkalan data dan dapatkan nilai lama
(3) Minta B untuk menulis nilai baharu ke dalam pangkalan data
( 4) Minta B untuk memadam Cache
(5) Minta A untuk menulis nilai lama yang ditemui pada cache
Kunci kepada masalah konkurensi di atas ialah langkah 5 berlaku selepas langkah 3 dan 4. Ia boleh dilihat daripada faktor gangguan sistem pengendalian yang tidak pasti bahawa situasi ini mungkin berlaku.
Dari sudut pandangan praktikal, menulis data ke Redis mengambil masa yang jauh lebih singkat daripada menulis data ke pangkalan data Walaupun kebarangkalian kejadian adalah rendah, ia akan tetap berlaku. .
(1) Tingkatkan masa tamat tempoh cache
Tingkatkan masa tamat tempoh cache untuk membenarkan data kotor wujud dalam julat masa tertentu sehingga kemas kini serentak seterusnya berlaku, Data kotor mungkin berlaku. Data kotor wujud secara berkala.
(2) Kemas kini dan pertanyaan berkongsi kunci baris
Kemas kini dan pertanyaan berkongsi kunci teragih baris, dan masalah di atas tidak wujud lagi wujud. Apabila permintaan baca memperoleh kunci, permintaan tulis berada dalam keadaan disekat (tamat masa akan gagal dan kembali dengan cepat), memastikan langkah 5 dilakukan sebelum langkah 3.
(3) Tangguhkan pemadaman cache
Gunakan RabbitMQ untuk menangguhkan pemadaman cache untuk mengalih keluar kesan langkah 5. Menggunakan kaedah tak segerak hampir tiada kesan ke atas prestasi.
Pangkalan data mempunyai mekanisme transaksi untuk memastikan kejayaan operasi satu arahan Redis, tetapi kemudian digabungkan ia tidak mempunyai ciri-ciri atomik berjaya, dan kemudian aplikasi Ia menutup secara tidak normal, menyebabkan cache Redis tidak dipadamkan. Masalah ini berlaku apabila sambungan rangkaian perkhidmatan Redis tamat masa.
Jika masa tamat tempoh cache ditetapkan, data kotor akan sentiasa wujud sebelum cache tamat tempoh. Jika masa tamat tempoh tidak ditetapkan, data kotor akan wujud sehingga kali berikutnya data diubah suai. (Data pangkalan data telah berubah dan cache belum dikemas kini)
Sebelum mengendalikan pangkalan data, tulis mesej pemadaman cache tertunda kepada RabbitMQ, kemudian laksanakan operasi pangkalan data dan laksanakan cache operasi pemadaman. Tidak kira sama ada cache peringkat kod berjaya dipadamkan, MQ memadamkan cache sebagai operasi terjamin.
Atas ialah kandungan terperinci Apakah pangkalan data dan skema ketekalan data cache untuk pengaturcaraan serentak Java?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
