本文目录
- php redis 怎么清除数据库
- JFinal中Redis如何进行清空缓存操作
- redis怎么清除key值前几个字符相同的缓存
- Redis内存满了怎么办
- redis清空db0库缓存
- Redis 的数据过期淘汰策略
php redis 怎么清除数据库
//DEL# 情况1： 删除单个key$redis-》set(’myname’,’ikodota’);echo $redis-》get(’myname’).’《br》’; # 返回:ikodota$redis-》del(’myname’);# 返回 TRUE(1)var_dump($redis-》get(’myname’)); # 返回 bool(false)# 情况2： 删除一个不存在的keyif(!$redis-》exists(’fake_key’)) # 不存在var_dump($redis-》del(’fake_key’)); # 返回 int(0)# 情况3： 同时删除多个key$array_mset=array(’first_key’=》’first_val’, ’second_key’=》’second_val’, ’third_key’=》’third_val’);$redis-》mset($array_mset); #用MSET一次储存多个值$array_mget=array(’first_key’,’second_key’,’third_key’);var_dump($redis-》mget($array_mget)); #一次返回多个值 //array(3) { =》 string(9) "third_val" }$redis-》del($array_mget); #同时删除多个keyvar_dump($redis-》mget($array_mget)); #返回 array(3) { =》 bool(false) }
JFinal中Redis如何进行清空缓存操作
RedisPlugin是作为JFinal的Plugin而存在的，所以使用时需要在JFinalConfig中配置RedisPlugin. 或 RedisPlugin也可以在非web环境下使用，只需引入jfinal.jar然后多调用一下redisPlugin.start()即可.
Redis与Cache联合起来可以非常方便地使用Redis服务，Redis对象通过use()方法来获取到Cache对象，Cache对象提供了丰富的API用于使用Redis服务，下面是具体使用示例：
public void redisDemo() { // 获取名称为bbs的Redis Cache对象 Cache bbsCache = Redis.use("bbs"); bbsCache.set("key", "value"); bbsCache.get("key"); // 获取名称为news的Redis Cache对象 Cache newsCache = Redis.use("news"); newsCache.set("k", "v"); newsCache.get("k"); // 最先创建的Cache将成为主Cache，所以可以省去cacheName参数来获取 bbsCache = Redis.use(); // 主缓存可以省去cacheName参数 bbsCache.set("jfinal", "awesome"); //删除给定的一个 key, 不存在的 key 会被忽略。 bbsCache.del("jfinal"); //删除给定的多个 key, 不存在的 key 会被忽略。 bbsCache.del("jfinal", "key"); //删除当前 db 所有数据 bbsCache.flushDB(); //删除所有 db 的所有数据 bbsCache.flushAll(); //获取redis.clients.jedis.Jedis 查阅官网API进行操作 Jedis jedis = bbsCache.getJedis();}
以上代码中通过”bbs”、”news”做为use方法的参数分别获取到了两个Cache对象，使用这两个对象即可操作其所对应的Redis服务端。
通常情况下只会创建一个RedisPlugin连接一个redis服务端，使用Redis.use().set(key,value)即可。
注意：使用 incr、incrBy、decr、decrBy 方法操作的计数器，需要使用 getCounter(key) 进行读取而不能使用 get(key)，否则会抛反序列化异常
redis怎么清除key值前几个字符相同的缓存
批量删除Redis下特定pattern的keys： 可以使用linux的xargs来做到，如： */redis-clikeys"prefix*" 如果是访问特定的数据库，则可以： */redis-cli-n0keys"prefix*" Redis是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。 redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sortedset--有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
Redis内存满了怎么办
长期把Redis做缓存用，总有一天Redis内存会满的，怎么处理呢？ 在Redis的配置文件 redis.conf 文件中，配置 maxmemory 的大小参数如下所示：
倘若实际的存储中超出了Redis的配置参数的大小时，Redis中有 淘汰策略 ，把 需要淘汰的key给淘汰掉，整理出干净的一块内存给新的key值使用 。 Redis提供了 6种的淘汰策略 ，其中默认的是 noeviction ，这6中淘汰策略如下：
LRU(Least Recently Used) 即表示最近最少使用，也就是在最近的时间内最少被访问的key，算法根据数据的历史访问记录来进行淘汰数据。 它的核心的思想就是： 假如一个key值在最近很少被使用到，那么在将来也很少会被访问 。 实际上Redis实现的LRU并不是真正的LRU算法，也就是名义上我们使用LRU算法淘汰键，但是实际上被淘汰的键并不一定是真正的最久没用的。 Redis使用的是近似的LRU算法， 通过随机采集法淘汰key，每次都会随机选出5个key，然后淘汰里面最近最少使用的key 。 这里的5个key只是默认的个数，具体的个数也可以在配置文件中进行配置，在配置文件中的配置如下图所示：
当近似LRU算法取值越大的时候就会越接近真实的LRU算法，可以这样理解，因为 取值越大那么获取的数据就越全，淘汰中的数据的就越接近最近最少使用的数据 。 那么为了实现根据时间实现LRU算法，Redis必须为每个key中额外的增加一个内存空间用于存储每个key的时间，大小是3字节。 在Redis 3.0中对近似的LRU算法做了一些优化，Redis中会维护大小是 16 的一个候选池的内存。 当第一次随机选取的采样数据，数据都会被放进候选池中，并且候选池中的数据会根据时间进行排序。 当第二次以后选取的数据，只有 小于候选池内的最小时间 的才会被放进候选池中。 当某一时刻候选池的数据满了，那么时间最大的key就会被挤出候选池。当执行淘汰时，直接从候选池中选取最近访问时间最小的key进行淘汰。 这样做的目的就是选取出最近似符合最近最少被访问的key值，能够正确的淘汰key值，因为随机选取的样本中的最小时间可能不是真正意义上的最小时间。 但是LRU算法有一个弊端：就是假如一个key值在以前都没有被访问到，然而最近一次被访问到了，那么就会认为它是热点数据，不会被淘汰。 然而有些数据以前经常被访问到，只是最近的时间内没有被访问到，这样就导致这些数据很可能被淘汰掉，这样一来就会出现误判而淘汰热点数据。 于是在Redis 4.0的时候除了LRU算法，新加了一种LFU算法， 那么什么是LFU算法算法呢？
LFU(Least Frequently Used) 即表示最近频繁被使用，也就是最近的时间段内，频繁被访问的key，它以最近的时间段的被访问次数的频率作为一种判断标准。 它的核心思想就是：根据key最近被访问的频率进行淘汰，比较少被访问的key优先淘汰，反之则优先保留。 LFU算法反映了一个key的热度情况，不会因为LRU算法的偶尔一次被访问被认为是热点数据。 在LFU算法中支持 volatile-lfu 策略和 allkeys-lfu 策略。
在Redis种有三种删除的操作此策略，分别是：
在Redis中持久化的方式有两种 RDB 和 AOF 在RDB中是以快照的形式获取内存中某一时间点的数据副本，在创建RDB文件的时候可以通过 save 和 bgsave 命令执行创建RDB文件。 这两个命令都不会把过期的key保存到RDB文件中 ，这样也能达到删除过期key的效果。 当在启动Redis载入RDB文件的时候， Master 不会把过期的key载入，而 Slave 会把过期的key载入。 在AOF模式下，Redis提供了Rewite的优化措施，执行的命令分别是 REWRITEAOF 和 BGREWRITEAOF ， 这两个命令都不会把过期的key写入到AOF文件中，也能删除过期key 。
RDB 是一种快照存储持久化方式，具体就是将 Redis 某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为 dump.rdb ，而在 Redis 服务器启动时，会重新加载 dump.rdb 文件的数据到内存当中恢复数据。 开启RBD持久化方式 开启 RDB 持久化方式很简单，客户端可以通过向 Redis 服务器发送 save 或 bgsave 命令让服务器生成 rdb 文件，或者通过服务器配置文件指定触发 RDB 条件。
save 命令是一个同步操作。
当客户端向服务器发送 save 命令请求进行持久化时，服务器会阻塞 save 命令之后的其他客户端的请求，直到数据同步完成。
与 save 命令不同， bgsave 命令是一个异步操作。
当客户端发服务发出 bgsave 命令时， Redis 服务器主进程会 forks 一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出。 所以，与 save 命令相比， Redis 服务器在处理 bgsave 采用子线程进行IO写入，而主进程仍然可以接收其他请求，但 forks 子进程是同步的，所以 forks 子进程时，一样不能接收其他请求，这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。
除了通过客户端发送命令外，还有一种方式，就是在 Redis 配置文件中的 save 指定到达触发RDB持久化的条件，比如【多少秒内至少达到多少写操作】就开启 RDB 数据同步。 例如我们可以在配置文件redis.conf指定如下的选项：
之后在启动服务器时加载配置文件。
这种通过服务器配置文件触发RDB的方式，与bgsave命令类似，达到触发条件时，会forks一个子进程进行数据同步，不过最好不要通过这方式来触发RDB持久化，因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能，时间设置太长则会造成数据丢失。
介绍了三种让服务器生成rdb文件的方式，无论是由主进程生成还是子进程来生成，其过程如下：
Redis 的另外一个持久化方式： AOF(Append-only file) 。 与 RDB 存储某个时刻的快照不同， AOF 持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以 Redis 协议追加保存到以后缀为 aof 文件末尾，在Redis服务器重启时，会加载并运行 aof 文件的命令，以达到恢复数据的目的。
Redis默认不开启AOF持久化方式，我们可以在配置文件中开启并进行更加详细的配置，如下面的redis.conf文件：
在上面的配置文件中，我们可以通过 appendfsync 选项指定写入策略,有三个选项
客户端的每一个写操作都保存到 aof 文件当，这种策略很安全，但是每个写请注都有IO操作，所以也很慢。
appendfsync 的默认写入策略，每秒写入一次 aof 文件，因此，最多可能会丢失1s的数据。
Redis 服务器不负责写入 aof ，而是交由操作系统来处理什么时候写入 aof 文件。更快，但也是最不安全的选择，不推荐使用。
AOF将客户端的每一个写操作都追加到 aof 文件末尾，比如对一个key多次执行incr命令，这时候， aof 保存每一次命令到aof文件中，aof文件会变得非常大。
aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：
通过在redis.conf配置文件中的选项no-appendfsync-on-rewrite可以设置是否开启重写，这种方式会在每次fsync时都重写，影响服务器性能，因此默认值为no，不推荐使用。
客户端向服务器发送bgrewriteaof命令，也可以让服务器进行AOF重写。
AOF重写方式也是异步操作，即如果要写入aof文件，则Redis主进程会forks一个子进程来处理，如下所示：
在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。
AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
我们可以从几个方面对比一下RDB与AOF,在应用时，要根本自己的实际需求，选择RDB或者AOF，其实，如果想要数据足够安全，可以两种方式都开启，但两种持久化方式同时进行IO操作，会严重影响服务器性能，因此有时候不得不做出选择。
当RDB与AOF两种方式都开启时，Redis会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。
redis清空db0库缓存
1.先确保redis进程存活 ps -ef|grep redis 2.执行./redis-cli或者./redis-cli -h 127.0.0.1 -p 6379 # /bin/redis-cli 3.执行dbsize命令 127.0.0.1:6379》 dbsize 4.清理 127.0.0.1:6379》 flushall 1 5.退出 127.0.0.1:6379》 exit ------------- 如遇到密码权限 先连接redis ，并输入auth 用户名 输入密码 password
Redis 的数据过期淘汰策略
Redis 中数据过期策略采用定期删除+惰性删除策略。定期删除策略：Redis 启用一个定时器定时监视所有的 key，判断key是否过期，过期的话就删除。这种策略可以保证过期的 key 最终都会被删除，但是也存在严重的缺点：每次都遍历内存中所有的数据，非常消耗 CPU 资源，并且当 key 已过期，但是定时器还处于未唤起状态，这段时间内 key 仍然可以用。惰性删除策略：在获取 key 时，先判断 key 是否过期，如果过期则删除。这种方式存在一个缺点：如果这个 key 一直未被使用，那么它一直在内存中，其实它已经过期了，会浪费大量的空间。2、定期删除+惰性删除策略是如何工作的？这两种策略天然的互补，结合起来之后，定时删除策略就发生了一些改变，不在是每次扫描全部的 key 了，而是随机抽取一部分 key 进行检查，这样就降低了对 CPU 资源的损耗，惰性删除策略互补了为检查到的key，基本上满足了所有要求。但是有时候就是那么的巧，既没有被定时器抽取到，又没有被使用，这些数据又如何从内存中消失？没关系，还有内存淘汰机制，当内存不够用时，内存淘汰机制就会上场。Redis 内存淘汰机制有以下几种策略：noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。（Redis 默认策略）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 Key。（推荐使用）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 Key。volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 Key。这种情况一般是把 Redis 既当缓存，又做持久化存储的时候才用。volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 Key。volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 Key 优先移除。修改内存淘汰机制只需要在 redis.conf 配置文件中配置 maxmemory-policy 参数即可。
