Redis系列六：redis相关功能

一、 慢查询原因分析

与mysql一样:当执行时间超过阀值，会将发生时间耗时的命令记录

redis命令生命周期：发送 排队 执行 返回慢查询只统计第3个执行步骤的时间预设阀值：两种方式，默认为10毫秒1，动态设置6379:> config set slowlog-log-slower-than 10000 //10毫秒10000微秒使用config set完后,若想将配置持久化保存到redis.conf，要执行config rewrite 2，redis.conf修改：找到slowlog-log-slower-than 10000 ，修改保存即可注意：slowlog-log-slower-than =0记录所有命令 -1命令都不记录原理：慢查询记录也是存在队列里的，slow-max-len 存放的记录最大条数，比如设置的slow-max-len＝10，当有第11条慢查询命令插入时，队列的第一条命令就会出列，第11条入列到慢查询队列中， 可以config set动态设置，也可以修改redis.conf完成配置。

2 命令：获取队列里慢查询的命令：slowlog get 查询返回的结构如下

获取慢查询列表当前的长度：slowlog len //返回7

对慢查询列表清理（重置）：slowlog reset //再查slowlog len 此时返回0 清空

对于线上slow-max-len配置的建议：线上可加大slow-max-len的值，记录慢查询存长命令时redis会做截断，不会占用大量内存，线上可设置1000以上对于线上slowlog-log-slower-than配置的建议：默认为10毫秒，根据redis并发量来调整，对于高并发比建议为1毫秒注意：

1，慢查询只记录命令在redis的执行时间，不包括排队、网络传输时间2，慢查询是先进先出的队列，访问日志记录出列丢失，需定期执行slow get,将结果存储到其它设备中（如mysql）

二、redis-cli详解

./redis-cli -r 3 -h 192.168.1.111 -a 12345678 ping //返回pong表示127.0.0.1:6379能通，r代表次数./redis-cli -r 100 -i 1 info |grep used_memory_human //每秒输出内存使用量,输100次，i代表执行的时间间隔./redis-cli -p 6379 -h 192.168.1.111 -a 12345678对于我们来说，这些常用指令以上可满足，但如果要了解更多执行./redis-cli --help,可百度

三、?redis-server详解

./redis-server ./redis.conf & //指定配置文件启动 ./redis-server --test-memory 1024 //检测操作系统能否提供1G内存给redis,常用于测试，想快速占满机器内存做极端条件的测试，可使用这个指令 redis上线前，做一次测试

四、redis-benchmark：redis

100个客户端同时请求redis,共执行10000次,会对各类数据结构的命令进行测试：

./redis-benchmark -h 127.0.0.1 -c 100 -n 10000 ?//100

测试存取大小为100字节的数据包的性能：

./redis-benchmark -h 127.0.0.1?-p 6379 -q -d 100?

只测试 set,lpush操作的性能，-q只显示每秒钟能处理多少请求数结果：

./redis-benchmark -h 127.0.0.1?-t set,lpush -n 100000 -q

只测试某些数值存取的性能,比如说我在慢查询中发现，大部分为set语句比较慢，我们自己可以测一下Set是不是真的慢：

./redis-benchmark -h 192.168.1.111 -n 100000 -q script load "redis.call('set','foo','bar')"

五、Pipeline（管道）

1.背景：

没有pipeline之前，一般的redis命令的执行过程都是：发送命令－〉命令排队－〉命令执行－〉返回结果。

多条命令的时候就会产生更多的网络开销

?

这个时候需要pipeline来解决这个问题：使用pipeline来打包执行N条命令，这样的话就只需简历一次网络连接，网络开销就少了

2. 使用pipeline和未使用pipeline的性能对比：

使用Pipeline执行速度与逐条执行要快，特别是客户端与服务端的网络延迟越大，性能体能越明显

3.原生批命令(mset,mget)与Pipeline对比

1) 原生批命令是原子性，pipeline是非原子性， (原子性概念:一个事务是一个不可分割的最小工作单位,要么都成功要么都失败。原子操作是指你的一个业务逻辑必须是不可拆分的. 处理一件事情要么都成功要么都失败，其实也引用了生物里概念，分子－〉原子，原子不可拆分)2) 原生批命令一命令多个key,但pipeline支持多命令（存在事务），非原子性3) 原生批命令是服务端实现，而pipeline需要服务端与客户端共同完成

4. pipeline正确使用方式：

使用pipeline组装的命令个数不能太多，不然数据量过大，增加客户端的等待时间，还可能造成网络阻塞，可以将大量命令的拆分多个小的pipeline命令完成

如：有300个命令需要执行，可以拆分成每30个一个pipeline执行

六、redis事务

pipeline是多条命令的组合，为了保证它的原子性，redis提供了简单的事务；redis的事物与mysql事物的最大区别是redis事物不支持事物回滚

事务：事务是指一组动作的执行，这一组动作要么都成功，要么都失败。

1. redis的简单事务，将一组需要一起执行的命令放到multi和exec两个命令之间，其中multi代表事务开始，exec代表事务结束

discard

3.?命令错误，语法不正确，导致事务不能正常执行，即事物的原子性

?

4.?watch命令：使用watch后， multi失效，事务失效，其他的线程任然可以对值进行修改

?在客户端1设置值使用watch监听key并使用multi开启事物，在客户端2追加完c之后再来客户端1追加redis，然后执行事物，可以看到在客户端1追加的redis没有起效果：

客户端1：

客户端2：

?

七、LUA语言与Redis配合使用

1. LUA脚本语言是C开发的，类似存储过程

1).减少网络开销：本来5次网络请求的操作，可以用一个请求完成，原先5次请求的逻辑放在redis服务器上完成。使用脚本，减少了网络往返时延。2).原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。3).复用：客户端发送的脚本会永久存储在Redis中，意味着其他客户端可以复用这一脚本而不需要使用代码完成同样的逻辑

语法：

eval+脚本+KEYS[1]+键个数+键——》eval script numkeys key [key ...]

eval "return redis.call('get',KEYS[1])" 1 name?

?语法示例1:

语法示例2:

JAVA

以上代码有两点缺陷?：可能会出现竞态条件: 解决方法是用 WATCH 监控 rate.limit:$IP 的变动,但较为麻烦;以上代码在不使用 pipeline 的情况下最多需要向Redis请求5条指令,传输过多.

b)使用lua脚本来处理，包括了原子性

lua脚本：

ipAccessCount.lua

使用redis命令获取lua脚本来执行：

./redis-cli -p 6379 -a 12345678 --eval ipAccessCount.lua ,10 20