Redis位图、配置文件

最新推荐文章于 2024-07-10 14:47:06 发布

天青色的烟雨.

最新推荐文章于 2024-07-10 14:47:06 发布

阅读量406

点赞数

分类专栏：【NoSql】

本文链接：https://blog.csdn.net/JinXYan/article/details/88726503

版权

【NoSql】专栏收录该内容

24 篇文章 0 订阅

订阅专栏

一、位图

在我们平时开发中，会有一些布尔型数据需要存取。比如你在很多睡眠软件里会看到早起打卡的活动，那么它就需要记录用户的签到记录，签了就是1，没签是0。如果使用普通的key/value，每个用户要记录365个，当用户千万、上亿的时候，无疑需要的存储空间时非常惊人的。

为了解决类似的这种需要存取大数据量的布尔类型问题，redis提供了位图数据结构，这样每天的签到记录只占据一个位，365个位只需要46个字节即可，这就大大节约了存储空间。

位图，其实就是byte数组（8位），我们可以使用普通的 get/set 直接获取和设置整个位图的内容，也可以使用位图操作 getbit/setbit 等将 byte 数组看成「位数组」来处理。

基本使用

Redis 的位数组是自动扩展，如果设置了某个偏移位置超出了现有的内容范围，就会自动将位数组进行零扩充。

比如，我们要使用位操作将字符串设置为hello，那么我们要得到hello的二进制

public void toBinary(){
    String str = "hello";
    char[] strChar=str.toCharArray();
    String result="";
    for(int i=0;i<strChar.length;i++){
        result +=Integer.toBinaryString(strChar[i])+ " ";
    }
    System.out.println(result);
}

这里我们拿h作为例子，h（01101000）需要转1的就是1/2/4位（第一位是符号位），位数组的顺序和字符的位顺序是相反的。

127.0.0.1:6379> setbit s 1 1
(integer) 0
127.0.0.1:6379> setbit s 2 1
(integer) 0
127.0.0.1:6379> setbit s 4 1
(integer) 0

这种位操作的方式是零存。零存就是使用setbit对位进行逐个设置，整存（set操作）就是使用字符串一次性填充全部位数组，覆盖旧数组。当然还有零取（getbit）和整取（get）。

统计和查找

Redis 提供了两种指令：

bitcount 用来统计指定位置范围内 1 的个数
bitpos 用来查找指定范围内出现的第一个 0 或 1。

我们可以用bitcount统计用户一共签到额多少天，通过bitpos查找用户从那一天开始第一次签到。如果指定了范围参数[start,end]，就可以统计在某个时间范围内用户签到了多少天，用户自某天以后的哪天开始签到。

127.0.0.1:6379> set a hello
OK
127.0.0.1:6379> bitcount a
(integer) 21
127.0.0.1:6379> bitcount a 0 0  # 第一个字符中 1 的位数
(integer) 3
127.0.0.1:6379> bitcount a 0 1  # 前两个字符中 1 的位数
(integer) 7
127.0.0.1:6379> bitpos a 0  # 第一个 0 位
(integer) 0
127.0.0.1:6379> bitpos a 1  # 第一个 1 位
(integer) 1
127.0.0.1:6379> bitpos a 1 1 1  # 从第二个字符算起，第一个 1 位
(integer) 9
127.0.0.1:6379> bitpos a 1 2 2  # 从第三个字符算起，第一个 1 位
(integer) 17

start 和 end 参数是字节索引，也就是说指定的位范围必须是8的倍数，而不能任意指定。如果我们想要计算出某个月内用户签到多少天，我们就得将这个月所福噶的字节内容全部取出来 (getrange 可以取出字符串的子串) ，再统计。

二、管道

Redis是一个响应式的服务，当客户端发送一个请求后，就处于阻塞状态等待Redis返回结果。这样一次命令消耗的时间就包括四个部分：请求从客户端到服务器的时间、命令排队的时间和命令真正执行时间、结果从服务器到客户端的时间，第一个和第四个消耗的时间总和称为RTT（Round Trip Time），当客户端与服务器存在网络延时时，RTT就可能会很大，这样就会导致性能问题。

管道（Pipeline）就是为了改善这个情况的，利用管道，客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后再一次性读取服务的响应，这样可以极大的降低RTT时间从而提升性能。需要注意到是用pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。

对比分析

1、Redis提供了批量操作命令,如mget,mset,但有些命令不支持批量操作,如果有一个场景需要批量操作某些key,假如有1000个，在我们没有使用批量操作时所需要的时间是1000次RTT时间+1000次命令执行时间：

2、使用pipeline操作一次传递命令时,所需要的时间是1次RTT时间+1000次命令执行时间：

测试不使用pipeline和使用pipeline分别向redis中存放一千条

@Test
public void testNoPipelineSet() {
	Jedis jedis = jedisPool.getResource();
	String keyPrefix = "normal";
	long begin = System.currentTimeMillis();
	for (int i = 1; i < 10000; i++) {
		String key = keyPrefix + "_" + i;
		String value = String.valueOf(i);
		jedis.set(key, value);
	}
	jedis.close();
	long end = System.currentTimeMillis();
	System.out.println("not use pipeline batch set total time：" + (end - begin));
}
 
@Test
public void testPipelineSet() {
	Jedis jedis = jedisPool.getResource();
	Pipeline pipelined = jedis.pipelined();
	String keyPrefix = "pipeline";
	long begin = System.currentTimeMillis();
	for (int i = 1; i < 10000; i++) {
		String key = keyPrefix + "_" + i;
		String value = String.valueOf(i);
		pipelined.set(key, value);
        }
        pipelined.sync();
        jedis.close();
        long end = System.currentTimeMillis();
        System.out.println("use pipeline batch set total time：" + (end - begin));
}

结果

not use pipeline batch set total time：998
use pipeline batch set total time：31

使用了pipeline后提升效果非常明显。

三、redis.conf配置文件参数说明

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

daemonize no

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

pidfile /var/run/redis.pid

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

port 6379

绑定的主机地址

bind 127.0.0.1

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

timeout 300

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

loglevel notice

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

logfile stdout

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

databases 16

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

save <seconds> <changes>

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

               save 900 1
   save 300 10
               save 60 10000

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

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

rdbcompression yes

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

dbfilename dump.rdb

指定本地数据库（dump.rdb）存放目录

dir ./

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

slaveof <masterip> <masterport>

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

masterauth <master-password>

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

requirepass foobared

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

maxclients 128

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

maxmemory <bytes>

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

appendonly no

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

appendfilename appendonly.aof

指定更新日志条件，共有3个可选值：

       no：表示等操作系统进行数据缓存同步到磁盘（快）
         always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
       everysec：表示每秒同步一次（折衷，默认值）

appendfsync everysec

指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中。

vm-enabled no

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

vm-swap-file /tmp/redis.swap

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

vm-max-memory 0

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

vm-page-size 32