Apakah pangkalan data dan skema ketekalan data cache untuk pengaturcaraan serentak Java?

1. Prakata

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.

2. Suara yang berbeza

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

1. Urutan operasi

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.

2. Sikap semasa berurusan dengan cache

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.

3. Analisis konkurensi benang

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.

Mencari data

1. Persekitaran bukan serentak

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.

2. Persekitaran serentak

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);
}

Kemas kini data

1 >

Dalam persekitaran bukan serentak, kod berikut mungkin menyebabkan ketidakkonsistenan data (data ditimpa). Walaupun menggunakan penguncian optimistik peringkat pangkalan data boleh menyelesaikan masalah data yang ditimpa, trafik kemas kini yang tidak sah akan tetap mengalir ke pangkalan data.

public Boolean editOrder(BuOrder order) {
    /* 更新数据库 */
    updateById(order);
    /* 删除缓存 */
    RedisUtils.deleteObject(OrderServiceImpl.ORDER_KEY_PREFIX + order.getOrderId());
    return true;
}

2. Persekitaran serentak

Dalam analisis di atas, penggunaan penguncian optimistik pangkalan data boleh menyelesaikan masalah data yang ditimpa dalam kemas kini serentak diubah suai, nombor versi berubah , permintaan serentak berikutnya kepada pangkalan data adalah trafik tidak sah. Strategi utama untuk mengurangkan tekanan pangkalan data adalah untuk memintas trafik tidak sah sebelum pangkalan data.

Menggunakan kunci teragih boleh memastikan trafik serentak mengakses pangkalan data dengan cara yang teratur Memandangkan penguncian optimistik telah digunakan pada peringkat pangkalan data, urutan kedua dan seterusnya yang memperoleh kunci mengendalikan pangkalan data sebagai trafik tidak sah.

Urutan menggunakan strategi keluar tamat masa apabila memperoleh kunci Ulir yang menunggu kunci akan tamat masa dan keluar dengan cepat, membalas permintaan pengguna dengan cepat dan mencuba semula operasi data kemas kini.

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;
}

Bergantung kepada alam sekitar

Kod di atas menggunakan kelas alat yang merangkum kunci.

<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

4. Pangkalan data dahulu, kemudian cache

Konsistensi data

1 Penerangan masalah

Seterusnya, kita akan membincangkan sama ada terdapat keselarasan dalam pengemaskinian pangkalan data. pertama dan kemudian memadamkan soalan cache.

(1) Cache baru sahaja tamat tempoh

(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.

2. Penyelesaian

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.

Keadaan khas

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)

Penyelesaian

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!