expire key seconds 时间复杂度：O（1）
Tetapkan masa tamat tempoh key. Selepas tamat masa, key akan dipadamkan secara automatik. Tamat masa yang berkaitan bagi key tidak menentu dalam terminologi Redis. Selepas
tamat masa, ia hanya akan dikosongkan apabila DEL, SET atau GETSET dilaksanakan pada key. Ini bermakna secara konsep semua operasi yang berubah key tanpa menggantikannya dengan nilai baharu akan memastikan tamat masa tidak berubah. Contohnya, menggunakan INCR untuk menambah nilai kunci, melaksanakan LPUSH untuk menolak nilai baharu ke dalam senarai atau menggunakan HSET untuk menukar cincangan field semuanya mengekalkan tamat masa tidak berubah.
Gunakan perintah PERSIST untuk mengosongkan tamat masa dan menjadikannya kekal key
Jika key ialah RENAME Apabila arahan itu diubah suai, tamat masa yang berkaitan akan dipindahkan ke key
Jika key diubah oleh perintah RENAME yang baharu, contohnya, Key_A asalnya wujud, dan kemudian panggil perintah RENAME Key_B Key_A, pada masa ini, tidak kira sama ada Key_A asal kekal atau ditetapkan kepada tamat masa, ia akan ditimpa oleh status tempoh sah Key_B
Ambil perhatian bahawa menggunakan panggilan tamat masa bukan positif EXPIRE/PEXPIRE atau EXPIREAT/PEXPIREAT dengan masa pada masa lalu akan menyebabkan kunci dipadamkan dan bukannya tamat tempoh (jadi peristiwa utama yang dipancarkan akan del, tidak tamat tempoh).
Melakukan operasi key pada EXPIRE yang sudah mempunyai masa tamat tempoh akan mengemas kini masa tamat tempohnya. Terdapat banyak aplikasi dengan senario perniagaan ini, seperti rakaman sesi.
Dalam versi Redis sebelum 2.1.3, menukar kunci dengan set tamat tempoh menggunakan arahan yang mengubah nilainya mempunyai kesan memadamkan kunci sepenuhnya . Semantik ini diperlukan kerana batasan dalam lapisan replikasi yang kini telah ditetapkan.
TAMAT TEMPOH akan mengembalikan 0 dan tidak akan menukar tamat masa untuk kunci dengan set tamat masa.
1 Jika masa tamat tempoh berjaya ditetapkan.
0 Jika key tidak wujud atau masa tamat tempoh tidak boleh ditetapkan.
Andaikan terdapat perkhidmatan Web yang berminat dengan N halaman terkini yang dilawati oleh pengguna, jadi bahawa setiap paparan Halaman bersebelahan tidak lebih daripada 60 saat selepas halaman sebelumnya. Secara konsep, anggap set paparan halaman ini sebagai sesi navigasi untuk pengguna, yang mungkin mengandungi maklumat menarik tentang produk yang mereka cari pada masa ini supaya anda boleh mengesyorkan produk berkaitan.
Corak ini boleh dimodelkan dengan mudah dalam Redis menggunakan strategi berikut: Setiap kali pengguna melaksanakan paparan halaman, anda memanggil arahan berikut:
MULTI RPUSH pagewviews.user:<userid> http://..... EXPIRE pagewviews.user:<userid> 60 EXEC</userid></userid>
Jika pengguna melahu selama lebih daripada 60 saat, anda akan Padam kekunci dan hanya merekodkan paparan halaman berikutnya yang berbeza kurang daripada 60 saat. Mod ini mudah diubah suai untuk menggunakan INCR dan bukannya senarai menggunakan RPUSH.
Biasanya, kekunci Redis dicipta tanpa dikaitkan dengannya sepanjang hayat. Kunci akan berterusan melainkan pengguna memadamkannya secara eksplisit (seperti arahan DEL). Gunakan perintah EXPIRE untuk mengaitkan item yang telah tamat tempoh dengan kunci yang diberikan, tetapi ini akan menyebabkan kunci itu menduduki memori tambahan. Redis akan memadamkan kunci secara automatik dengan set yang telah tamat tempoh selepas masa yang ditetapkan untuk memastikan bahawa data tidak luput. Masa kritikal untuk hidup boleh dikemas kini atau dialih keluar sepenuhnya menggunakan perintah EXPIRE dan PERSIST (atau arahan ketat lain).
Masa tamat tempoh dalam Redis 2.4 boleh menjadi tidak tepat, turun naik antara 0 dan 1 saat. Sejak Redis 2.6, ralat tamat tempoh adalah antara 0 hingga 1 milisaat.
Simpan kunci maklumat tamat tempoh sebagai cap masa Unix mutlak Kaedah storan peringkat milisaat sesuai untuk Redis versi 2.6 dan lebih tinggi. Ini bermakna masa mengalir walaupun tika Redis tidak aktif. Untuk tamat tempoh berfungsi dengan baik, masa komputer mesti distabilkan. Jika anda mengalihkan fail RDB daripada dua mesin yang mempunyai desync yang besar dalam jamnya, perkara menarik boleh berlaku (seperti memuatkan semua kekunci yang sudah lapuk). Walaupun semasa menjalankan contoh, jam komputer sentiasa diperiksa, contohnya, jika anda menetapkan kunci kepada 1000 saat dan kemudian menetapkan masa komputer 2000 saat pada masa hadapan, kunci akan tamat tempoh serta-merta dan bukannya bertahan 1000 saat.
Terdapat dua cara untuk tamat tempoh kunci: cara pasif - pemadaman malas, cara aktif - pemadaman biasa.
Apabila pelanggan cuba mengakses kunci, kunci akan luput secara pasif, iaitu, Redis akan menyemak sama ada masa tamat tempoh ditetapkan untuk kunci dan jika ia tamat tempoh , ia akan dipadamkan, dan ia tidak akan mengembalikan apa-apa. Redis tidak akan memadamkan kunci secara automatik, tetapi apabila menanyakan kunci, Redis akan dengan malas menyemak sama ada ia telah dipadamkan. Ini serupa dengan permulaan tertunda Spring.
当然，这是不够的，因为有过期的key，永远不会再访问。无论如何，这些key都应过期，因此请定期 Redis 在具有过期集的key之间随机测试几个key。已过期的所有key将从key空间中删除。
具体来说，如下 Redis 每秒 10 次：
测试 20 个带有过期的随机键
删除找到的所有已过期key
如果超过 25% 的key已过期，从步骤 1 重新开始
这是一个微不足道的概率算法，基本上假设我们的样本代表整个key空间，继续过期，直到可能过期的key百分比低于 25%。在任何特定时刻，已失效的最大键数等于每秒最大写入操作数除以4，这是由内存使用所决定的。
为了在不牺牲一致性的情况下获得正确行为，当key过期时，DEL 操作将同时在 AOF 文件中合成并获取所有附加的从节点。这样做的好处是能够将过时的处理过程集中在主节点中，避免出现一致性错误的可能性。
但是，虽然连接到主节点的从节点不会独立过期key（但会等待来自master的 DEL），但它们仍将使用数据集中现有过期的完整状态，因此，当选择slave作为master时，它将能够独立过期key，完全充当master。
由于您没有及时查找和删除大量过期key，这些过期key在Redis中堆积，导致内存严重耗尽
因此还需有内存淘汰机制！
写请求无法继续服务 (DEL 请求除外)，但读请求可以继续进行。这样 可以保证不会丢失数据，但是会让线上的业务不能持续进行。
config.c
createEnumConfig("maxmemory-policy", NULL,
MODIFIABLE_CONFIG, maxmemory_policy_enum,
server.maxmemory_policy,
MAXMEMORY_NO_EVICTION, NULL, NULL),当内存不足以容纳新写入数据时，在键空间中，随机移除某key。凭啥随机呢，至少也是把最近最少使用的key删除。
当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key，没有设置过期时间的 key 也会被淘汰。
LRU的关键是看页面最后一次被使用到发生调度的时间长短，而LFU关键是看一定时间段内页面被使用的频率。
优先淘汰最少使用的 key，其中包括设置了过期时间的 key。 没有设置过期时间的 key 不会被淘汰，这样可以保证需要持久化的数据不会突然丢失。与allkey-lru不同，这种策略仅淘汰过期的键集合。
淘汰的 key 是过期 key 集合中随机的 key。
淘汰的策略不是 LRU，而是 key 的剩余寿命 ttl 的值，ttl 越小越优先被淘汰。
volatile-xxx 策略只会针对带过期时间的 key 进行淘汰，allkeys-xxx 策略会对所有的 key 进行淘汰。
如果你只是拿 Redis 做缓存，那应该使用 allkeys-xxx，客户端写缓存时不必携带过期时间。
如果你还想同时使用 Redis 的持久化功能，那就使用 volatile-xxx 策略，这样可以保留没有设置过期时间的 key，它们是永久的 key 不会被 LRU 算法淘汰。
确实有时会问这个，因为有些候选人如果确实过五关斩六将，前面的问题都答的很好，那么其实让他写一下LRU算法，可以考察一下编码功底
你可以现场手写最原始的LRU算法，那个代码量太大了，不太现实
public class LRUCache<k> extends LinkedHashMap<k> {
private final int CACHE_SIZE;
// 这里就是传递进来最多能缓存多少数据
public LRUCache(int cacheSize) {
// true指linkedhashmap将元素按访问顺序排序
super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
CACHE_SIZE = cacheSize;
}
@Override
protected boolean removeEldestEntry(Map.Entry eldest) {
// 当KV数据量大于指定缓存个数时，就自动删除最老数据
return size() > CACHE_SIZE;
}
}</k></k>Atas ialah kandungan terperinci Cara menggunakan strategi tamat tempoh Redis dan strategi penghapusan ingatan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
Perisian pangkalan data yang biasa digunakan
Apakah pangkalan data dalam memori?
Yang manakah mempunyai kelajuan bacaan yang lebih pantas, mongodb atau redis?
Cara menggunakan redis sebagai pelayan cache
Bagaimana redis menyelesaikan ketekalan data
Bagaimanakah mysql dan redis memastikan konsistensi penulisan dua kali?
Apakah data yang biasanya disimpan oleh redis cache?
Apakah 8 jenis data redis
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
