Bagaimana untuk menyelesaikan masalah avalanche cache Redis

Lapisan cache membawa sejumlah besar permintaan, melindungi lapisan storan dengan berkesan. Walau bagaimanapun, jika sebilangan besar permintaan tiba di lapisan storan disebabkan oleh sejumlah besar kegagalan cache atau keseluruhan cache tidak dapat menyediakan perkhidmatan, beban pada lapisan storan akan meningkat (sebilangan besar permintaan menanyakan pangkalan data). Ini adalah senario runtuhan cache;

Untuk menyelesaikan runtuhan cache, anda boleh bermula dari perkara berikut:

1 Pastikan lapisan cache sentiasa tersedia

Gunakan Redis mod sentri atau Redis Dalam kaedah penempatan kelompok, walaupun nod Redis individu pergi ke luar talian, keseluruhan lapisan cache masih boleh digunakan. Selain itu, Redis boleh digunakan dalam berbilang bilik komputer, supaya walaupun bilik komputer ranap, lapisan cache masih boleh didapati dengan sangat baik.

2. Komponen penurunan taraf mengehadkan semasa

Kedua-dua lapisan cache dan lapisan storan akan mempunyai kebarangkalian ralat, dan ia boleh dianggap sebagai sumber. Sebagai sistem teragih dengan jumlah konkurensi yang besar, jika sumber tidak tersedia, ia boleh menyebabkan pengecualian apabila semua urutan memperoleh sumber ini, menyebabkan keseluruhan sistem menjadi tidak tersedia. Turun taraf adalah sangat biasa dalam sistem konkurensi tinggi Contohnya, dalam perkhidmatan pengesyoran, jika perkhidmatan pengesyoran diperibadikan tidak tersedia, anda boleh menurunkan taraf untuk menambah data tempat liputan supaya keseluruhan perkhidmatan pengesyoran tidak akan tersedia. Komponen degradasi mengehadkan arus biasa termasuk Hystrix, Sentinel, dsb.

3. Cache tidak tamat tempoh

Kunci yang disimpan dalam Redis tidak akan tamat tempoh, jadi tidak akan ada masalah sebilangan besar cache tidak sah pada masa yang sama, tetapi yang berikut ialah bahawa Redis memerlukan lebih banyak ruang storan.

4. Optimumkan masa tamat tempoh cache

Apabila mereka bentuk cache, pilih masa tamat tempoh yang sesuai untuk setiap kunci untuk mengelakkan sejumlah besar kunci menjadi tidak sah pada masa yang sama, menyebabkan runtuhan cache.

5. Gunakan kunci mutex untuk membina semula cache

Dalam senario serentak tinggi, untuk mengelakkan sejumlah besar permintaan mencapai lapisan storan untuk menanyakan data dan membina semula cache pada masa yang sama , anda boleh menggunakan kawalan kunci mutex, seperti mengikut Kekunci pergi ke lapisan cache untuk menanyakan data Apabila lapisan cache dipukul, kunci dikunci, kemudian data ditanya dari lapisan storan, data ditulis. ke lapisan cache, dan akhirnya kunci dilepaskan. Jika benang lain mendapati bahawa memperoleh kunci gagal, biarkan benang tidur untuk satu tempoh masa dan cuba lagi. Mengenai jenis kunci, jika anda berada dalam persekitaran yang berdiri sendiri, anda boleh menggunakan Lock di bawah pakej serentak Java Jika anda berada dalam persekitaran teragih, anda boleh menggunakan kunci teragih (kaedah SETNX dalam Redis).

Pseudokod cache pembinaan semula kunci Mutex dalam persekitaran teragih

/**
 * 互斥锁建立缓存
 *
 **/
public String get(String key) {
   // redis中查询key对应的value
   String value = redis.get(key);
   // 缓存未命中
   if (value == null) {
      // 互斥锁
      String key_mutex_lock = "mutex:lock" + key; 
      // 互斥锁加锁成功
      if(redis.setnx(key_mutex_lock,"1")) { // 返回 0（false）,1（true）
          try {
              // 设置互斥锁超时时间,这里设置的是锁的失效时间,而不是key的失效时间
              redis.expire(key_mutex_lock,3*60);
              // 从数据库查询
              value = db.get(key);
              // 数据写入缓存
              redis.set(key,value);
            
          } finally {
               // 释放锁
              boolean keyExist = jedis.exists(key_mutex_lock);
              if(keyExist){
                  redis.delete(key_mutex_lock);
               }
      } else { 
              // 加锁失败,线程休息50ms后重试
               Thread.sleep(50);
               return get(key); // 直接返回缓存结果  
     }
   }
}

Kunci teragih Redis digunakan untuk melaksanakan pembinaan semula cache dalam persekitaran teragih Kelebihannya ialah idea reka bentuk adalah mudah dan ketekalan data dijamin ; Kelemahannya ialah kerumitan kod meningkat dan boleh menyebabkan pengguna menunggu. Andaikan bahawa di bawah konkurensi tinggi, kunci dikunci semasa pembinaan semula cache. Jika pada masa ini terdapat 1,000 permintaan serentak, 999 daripadanya disekat, yang akan menyebabkan 999 permintaan pengguna disekat dan menunggu.

6. Bina semula cache secara asinkron

Dalam skema ini, strategi tak segerak digunakan untuk membina cache akan diperoleh daripada kumpulan benang untuk membina cache secara tidak segerak, supaya semua permintaan tidak akan mencapai storan secara langsung, setiap kunci Redis dalam penyelesaian ini mengekalkan masa tamat logik apabila tamat masa logik adalah kurang daripada masa semasa, ini bermakna cache semasa telah tamat tempoh dan cache harus dikemas kini bahawa cache semasa belum tamat tempoh dan nilai dalam cache dikembalikan secara langsung. Sebagai contoh, dalam Redis, masa tamat tempoh kunci ditetapkan kepada 60 minit, dan masa tamat tempoh logik dalam nilai yang sepadan ditetapkan kepada 30 minit. Dengan cara ini, apabila kunci mencapai masa tamat tempoh logik selama 30 minit, cache kunci ini boleh dikemas kini secara tidak segerak, tetapi semasa tempoh mengemas kini cache, cache lama masih tersedia. Kaedah pembinaan semula cache tak segerak ini berkesan boleh menghalang sejumlah besar kunci daripada menjadi tidak sah pada masa yang sama.

rreeee

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan masalah avalanche cache Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!