超大批量删除redis中无用key+配置

2023-07-19 08:57:58

目前线上一个单实例redis中无用的key太多，决定删除一部分。

1、删除指定用户的key，使用redis的pipeline

根据一定条件把需要删除的用户统计出来，放到一个表里面，表为 del_user(int user_id)，rows大约在1千万。

要删除的key为 "login:%s" %s匹配 user_id .

写sql文如下：把sql文保存在一个文件里面，命名为 1.sql

SELECT CONCAT(

"*2\r\n",

'$3\r\n',  
  'DEL\r\n',  
  '$', LENGTH(redis_key), '\r\n',  
  redis_key, '\r'
)  
FROM (  
  SELECT 
  CONCAT('login:',user_id) AS redis_key
  FROM del_user
) AS t;

然后执行命令：

mysql --raw --skip-column-names --default-character-set utf8 -h2.6.3.101 -P1067 -uroot -p'123456' test -A < /data/sql/1.sql | /data/redis/bin/redis-cli -a "password" -n 0 -p 6379 --pipe

实际执行速度非常快，每分钟大概删除300多万个key。

这里需要reids协议的知识点，可以参考：http://redis.io/topics/protocol

2、删除模式匹配下的key，使用lua脚本

比如有个需求，需要删除以":login"结尾的所有key， 业务中key的设计是这样的 %s:login

第一种方式：

redis-cli -a "password" -n 0 -p 6379 keys "*:login" | xargs -i redis-cli -a "password" -n 0 -p 6379 del {}

这样一个坏处每次都要建立一个连接，量小的话还可以接受，量大的话，效率不行。

第二种方式：

redis-cli -a "password" -n 0 -p 6379  EVAL "return redis.call('del', unpack(redis.call('keys', ARGV[1])))" 0 *:login

这样的方式，通过内置的 Lua 解释器，可以使用 EVAL 命令对 Lua 脚本

但这种处理方式，量大的情况下，lua函数unpack会出现问题，会报错误

(error) ERR Error running script (call to f_e177a091510d969af3b388ee986dbe6658df6b57): user_script:1: too many results to unpack

第三种方式：

实际上是对第二种方式的改进，一次性unpack太多会出问题，那就干脆一次5000吧，这样就不会有问题了

redis-cli -a "password" -n 0 -p 6379 EVAL "local keys = redis.call('keys', ARGV[1]) for i=1,#keys,5000 do redis.call('del', unpack(keys, i, math.min(i+4999, #keys))) end return #keys" 0 *:login

这段脚本的意思，首先定义一个数组 keys，里面存储了模式匹配的所有的以 *:login结尾的key，然后for循环，每次处理5000个key，也就是说每次del 5000个key。

目前测试下来，1000万个key，也就需要2分30多秒，速度非常快。

这里需要redis命令EVAL的知识点，可以参考：http://redis.io/commands/eval

注意：以上是基于redis2.6.14来处理的，keys在线上是禁用的。

 

自从redis2.8以后就开始支持scan命令，模式匹配可以采取下面的形式来批删除大量的key

redis-cli -a "password" -n 0 -p 6379 --scan --pattern "*:login" | xargs -L 5000 redis-cli -a "password" -n 0 -p 6379 DEL

速度处理也是非常快的

2013-04-20 11:46 493人阅读 评论(0) 收藏 举报
超大批量删除redis中无用key+配置 分类：
Redis（12） 超大批量删除redis中无用key+配置
     使用场景一：高频率使用但不频繁更新的业务数据。由于不频繁更新，所以可以在系统启动时，从数据库中加载，放入redis。如果更新，需重启服务，当然这比较笨。更好的做法下面会列出。
        使用场景二：高频率使用更新还算频繁的业务数据。由于有一定频率的更新，所以可以在用户访问时，查询缓存，如果没有值，则从数据库中加载入redis，并设置过期时间。这样，过期时间内的访问就都走缓存了。这种策略也有问题，就是大并发访问时，容易造成数据库瞬间高并发读，如果程序再写的烂点，查询语句再复杂点，那可能造成数据库死锁。更好的办法，下面列出。
        使用场景三：高频率使用高频率更新的业务数据。这种数据就需要在写入数据库的同时放入缓存，不设置过期时间，这样用户每次访问都走缓存。为了保证数据的一致，还有数据对内存的占用，还需要有一些额外的策略。
 
        对于场景一：更好的做法是在系统启动的同时，利用redis的pub/sub功能，启动一个监听通道。当数据发生更新时，往通道publish一个消息，系统接收到消息后，重新从数据库中加载数据，放入缓存。这样系统实现了无中断的更新缓存。
        对于场景二：更好的做法是单独启动一个定时任务，把定时任务看做是一个用户，他每隔一段时间从数据库中读取数据，然后放入缓存。而前台用户访问的始终是缓存数据，不会触发数据库的相关操作。这个策略也可以用在场景一中。
 
        当然，使用memcached也可以实现类似的功能，但是我更喜欢用redis，基于他强大的性能和数据结构，可以实现多种复杂的业务需求。
 
 

日常中有时为了做实验需要向redis导入大量数据

下面提供一些思路：

1、循环导入

key的类型为string，下面是例子脚本

for((i=1;i<=1000000;i++))
do
redis-cli -a "password" -n 0 -p 6379 set "k"$i "v"$i
done

这样的坏处显而易见，每次都要建立连接，效率低下，不可取。

当然你导入几百几千个key倒是没什么问题。

2、pipeline方式导入

先把预先的命令导入到一个文本里面

for((i=1;i<=1000000;i++))
do
echo "set k$i v$i" >> /tmp/_t.txt
done

执行格式转换

unix2dos /tmp/_t.txt

pipeline导入

cat /tmp/_t.txt | redis-cli -a "password" -n 0 -p 6379 --pipe

以上测试下来，100万的数据，在几十秒中搞定，速度嗷嗷的

参考：http://redis.io/topics/mass-insert

还有一种情况，比如需要把MySQL中的数据批量导入redis

假如目前需要把用户元宝表导入到redis中，表 user_gold(user_id, amount) ,每个用户一个key，string类型。

我们可以这样操作：

-- 1.sql 保存sql到 1.sql中

SELECT CONCAT(  
  "*3\r\n",  
  '$3\r\n',  
  'SET\r\n',  
  '$', LENGTH(redis_key), '\r\n',  
  redis_key, '\r\n',
  '$', LENGTH(redis_value), '\r\n',
  redis_value, '\r'
)  
FROM (  
  SELECT 
  CONCAT('user:gold:',user_id) AS redis_key,
  amount AS redis_value
  FROM test.user_gold
) AS t;

执行导入操作：

mysql --raw --skip-column-names -h2.6.3.101 -P1067 -uroot -p'123456' test -A < /data/sql/1.sql | /data/redis/bin/redis-cli -a "password" -n 0 -p 6379 --pipe

2013-05-22 11:11 1224人阅读 评论(0) 收藏 举报
超大批量删除redis中无用key+配置 分类：
Redis（12） 超大批量删除redis中无用key+配置
简介

Redis是一种高级key-value的NoSQL数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合。所以Redis也可以被看成是一个数据结构服务器。本次主要考虑key-list。

Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上。

【注】NoSQL(NoSQL = Not Only SQL )，指的是非关系型的数据库，相对传统的关系数据库：

1、 对数据库高并发读写的需求

2、对海量数据的高效率存储和访问的需求

3、对数据库的高可扩展性和高可用性的需求

安装、启动

tar -zxvf redis-2.4.2.tar.gz

cd redis-2.4.2/

make

make install

./redis-server /root/redis-2.4.2/redis.conf

使用、数据测试

主要研究key-list方式

for (int i = 0; i < 10000000; i++) {

jedis.lpush(key, String.valueOf(i));

}

通过该方式一次插入1千万条记录，所需时间为1小时40分钟到2小时，插入10万条记录1分钟左右。

在测试中发现一个问题，无法一次取出1千万条记录，对于key-list方式。再多就会出现read timed out，即使在服务端不限制timeout时间也会出现。

使用jedis操作，版本2.0.0，通过使用连接池，设置客户端的超时时间，可以解决read timed out问题，取1千万条记录需要27秒，1百万条记录2秒（平均每条数据10b），在进行取操作的时候，redis的内存使用会增加，与所取数据量有关，取操作完成后该部分内存释放。

以下数据都是估计值

取1百万条记录约2秒（平均每条数据约10b）

取1百万条记录约8秒（平均每条数据约100b），和每条数据大小也有关系

Java中连接池的创建和使用

JedisPoolConfig config = new JedisPoolConfig();

config.setMaxActive(100);

config.setMaxIdle(20);

config.setMaxWait(1000l);

pool = new JedisPool(config, "192.168.126.124", 6379, 10*1000, "password");

/*

config：连接池配置

"192.168.126.124":ip地址

6379：端口

10*1000：超时时间 (ms)

"password"：登录密码

*/

Jedis jedis=pool.getResource();

pool.returnResource(jedis);

jedis操作list介绍

lpush(key) 在key对应list的头部添加字符串元素，返回1表示成功，0表示key存在且不是list类型
rpush(key)  同上，在尾部添加
llen(key)  返回key对应list的长度，key不存在返回0,如果key对应类型不是list返回错误
lrange(key,start,end) 返回指定区间内的元素，下标从0开始，负值表示从后面计算，-1表示倒数第一个元素 ，key不存在返回空列表
ltrim(key,start,end)  截取list，保留指定区间内元素，成功返回1，key不存在返回错误
lset( key,index,value) 设置list中指定下标的元素值，成功返回1，key或者下标不存在返回错误
lrem(key,count,value) 从key对应list中删除count个和value相同的元素。count为0时候删除全部
lpop(key)从list的头部删除元素，并返回删除元素。如果key对应list不存在或者是空返回nil，如果key对应值不是list返回错误
rpop(key) 同上，但是从尾部删除

规划使用方式

根据数据量分配足够内存

普遍使用key-list方式存储数据，可将key理解为表名，list理解为记录列表，从而经行增删改查。

因为redis都是已字符串存储，对于list的每一个value可以考虑使用json数据结构，在底层做一个json与对象互转的封装。

就目前的了解，在使用redis的key-list方式，在通过key获取list后，对list的查询，修改还没有发现很好的方式，目前只能全部取出再经行查询。对list的更新只能通过下标经行。

持久化

Redis所具备的持久化是使用文件快照的方式，可以在配置文件中配置快照持久化的策略，可以设置多个，这里要考虑到具体的数据变化规律和性能的考虑（对磁盘文件的读写也较为费时），还有一点redis的文件快照持久化非增量持久化，也就是说每次进行快照都是全量数据。对于该种策略文件快照，在断电、宕机的情况下会丢失尚未进行快照的数据，在设置策略的时候需要考虑。

插入速度与每条记录大小关系不大，在进行save 60 10000策略插入1千万条数据与没有持久化策略插入1千万时间分别是 1小时50分钟、1小时20分钟

文件快照设置方式如下：

#save 900 1       在900秒内 如果有1条记录更新经行快照

#save 300 10      在300秒内 如果有10条记录更新经行快照

#save 60 10000    在60秒内 如果有10000条记录更新经行快照

事务

redis对事务的支持目前还比较简单。redis只能保证一个client发起的事务中的命令可以连续的执行，而中间不会插入其他client的命令。 由于redis是单线程来处理所有client的请求的所以做到这点是很容易的。一般情况下redis在接受到一个client发来的命令后会立即处理并 返回处理结果，但是当一个client在一个连接中发出multi命令有，这个连接会进入一个事务上下文，该连接后续的命令并不是立即执行，而是先放到一个队列中。当从此连接受到exec命令后，redis会顺序的执行队列中的所有命令。并将所有命令的运行结果打包到一起返回给client.然后此连接就 结束事务上下文.

Transaction t=jedis.multi();

System.out.println(t.lrange(key, 0, 1));

System.out.println(t.lrange(key, 0, 1));

t.exec();

基本配置参数

1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程

daemonize no

2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定

pidfile /var/run/redis.pid

3. 指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字

port 6379

4. 绑定的主机地址

bind 127.0.0.1

5.当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能

timeout 300

6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose

loglevel verbose

7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null

logfile stdout

8. 设置数据库的数量，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id

databases 16

9. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合

save <seconds> <changes>

Redis默认配置文件中提供了三个条件：

save 900 1

    save 300 10

    save 60 10000

分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。

10. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大

rdbcompression yes

11. 指定本地数据库文件名，默认值为dump.rdb

dbfilename dump.rdb

12. 指定本地数据库存放目录

dir ./

13. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步

slaveof <masterip> <masterport>

14. 当master服务设置了密码保护时，slav服务连接master的密码

masterauth <master-password>

15. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭

requirepass foobared

16. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息

maxclients 128

17. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区

maxmemory <bytes>

18. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no

appendonly no

19. 指定更新日志文件名，默认为appendonly.aof

appendfilename appendonly.aof

20. 指定更新日志条件，共有3个可选值： 
    no：表示等操作系统进行数据缓存同步到磁盘（快） 
    always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全） 
    everysec：表示每秒同步一次（折衷，默认值）

appendfsync everysec

21. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）

vm-enabled no

22. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享

vm-swap-file /tmp/redis.swap

23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0

vm-max-memory 0

24. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值

vm-page-size 32

25. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。

vm-pages 134217728

26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4

vm-max-threads 4

27. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启

glueoutputbuf yes

28. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法

hash-max-zipmap-entries 64

    hash-max-zipmap-value 512

29. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）

activerehashing yes

30. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

include /path/to/local.conf

上一篇：python2核心类库：urllib、urllib2的区别和使用


下一篇：BZOJ 1051: [HAOI2006]受欢迎的牛 缩点