慢查询原因分析:
与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完成配置。
命令：
获取队列里慢查询的命令：slowlog get 查询返回的结构如下
获取慢查询列表当前的长度：slowlog len //以上只有1条慢查询，返回1
对慢查询列表清理（重置）：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的性能
redis-benchmark -h 192.168.1.111 -c 100 -n 10000 //100个客户端同时请求redis,共执行10000次
会对各类数据结构的命令进行测试
测试命令事例：
1、redis-benchmark -h 192.168.1.111 -p 6379 -c 100 -n 100000
100个并发连接，100000个请求，检测host为localhost 端口为6379的redis服务器性能
2、redis-benchmark -h 192.168.1.111 -p 6379 -q -d 100
测试存取大小为100字节的数据包的性能
3、redis-benchmark -h 192.168.1.111 -t set,lpush -n 100000 -q
只测试 set,lpush操作的性能，-q只显示每秒钟能处理多少请求数结果
4、redis-benchmark -h 192.168.1.111 -n 100000 -q script load "redis.call('set','foo','bar')"
只测试某些数值存取的性能, 比如说我在慢查询中发现，大部分为set语句比较慢，我们自己可以测一下Set是不是真的慢，
Pipeline:
pipeline 出现的背景：
redis客户端执行一条命令分4个过程：
发送命令－〉命令排队－〉命令执行－〉返回结果
这个过程称为Round trip time(简称RTT, 往返时间)，mget mset有效节约了RTT，但大部分命令（如hgetall，并没有mhgetall）不支持批量操作，需要消耗N次RTT ，这个时候需要pipeline来解决这个问题
1，未使用pipeline执行N条命令
2，使用pipeline执行N条命令，后面会讲到JAVA的jedis如何使用pipeline功能
3，使用pipeline和未使用pipeline的性能对比：
小总结：使用pipeline执行速度比逐条执行要快，客户端与服务端的网络延迟越大，性能体现越明显
4，原生的批命令（mset, mget等）与pipeline的对比：
1.原生批命令是原子性，pipeline是非原子性， (原子性概念:一个事务是一个不可分割的最小工作单位,要么都成功要么都失败。原子操作是指你的一个业务逻辑必须是不可拆分的. 处理一件事情要么都成功要么都失败，其实也引用了生物里概念，分子－〉原子，原子不可拆分)
2.原生批命令一命令多个key, 但pipeline支持多命令（存在事务），非原子性
3.原生批命令是服务端实现，而pipeline需要服务端与客户端共同完成
5，pipeline正确使用方式：
使用pipeline组装的命令个数不能太多，不然数据量过大，增加客户端的等待时间，还可能造成网络阻塞，可以将大量命令的拆分多个小的pipeline命令完成
事务
刚大家知道，pipeline是多条命令的组合，为了保证它的原子性，redis提供了简单的事务，什么是事务？事务是指一组动作的执行，这一组动作要么成功，要么失败。
1.redis的简单事务，将一组需要一起执行的命令放到multi和exec两个命令之间，其中multi代表事务开始，exec代表事务结束
2.停止事务discard
3.命令错误，语法不正确，导致事务不能正常结束
4.运行错误，语法正确，但类型错误，事务可以正常结束
可以看到redis不支持回滚功能
watch命令
redis提供了简单事务，之所以说简单，不支持事务回滚
LUA语言与redis
LUA脚本语言是C开发的，类似存储过程
使用脚本的好处如下:
•1.减少网络开销：本来5次网络请求的操作，可以用一个请求完成，原先5次请求的逻辑放在redis服务器上完成。使用脚本，减少了网络往返时延。
•2.原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。
•3.复用：客户端发送的脚本会永久存储在Redis中，意味着其他客户端可以复用这一脚本而不需要使用代码完成同样的逻辑。
6379>eval "return redis.call('get',KEYS[1])" 1 name //eval+脚本+KEYS[1]+键个数+键
eval script numkeys key [key ...]
语法1：
local int sum = 0
local int i =0
while i <= 100
do sum = sum+i
i = i+1
end
print(sum)语法2：
local tables myArray={“james”,”java”,false,34} //定义
local int sum = 0
print(myArray[3]) //返回false
for i = 1,100
do
sum = sum+1
end
print(sum)
for j = 1,#myArray //遍历数组
do
print(myArray[j])
if myArray[j] == “james”
then
print(“true”)
break
else
print(“false”)
end
end
案例-实现访问频率限制: 实现访问者 $ip 127.0.0.1在一定的时间 $time 20S内只能访问 $limit 10次.使用JAVA语言实现：
private boolean accessLimit(String ip, int limit,
int time, Jedis jedis) {
boolean result = true;
String key = "rate.limit:" + ip;
if (jedis.exists(key)) {
long afterValue = jedis.incr(key);
if (afterValue > limit) {
result = false;
}
} else {
Transaction transaction = jedis.multi();
transaction.incr(key);
transaction.expire(key, time);
transaction.exec();
}
return result;
}以上代码有两点缺陷
可能会出现竞态条件: 解决方法是用 WATCH 监控 rate.limit:$IP 的变动, 但较为麻烦;
以上代码在不使用 pipeline 的情况下最多需要向Redis请求5条指令, 传输过多.
使用lua脚本来处理，包括了原子性：如下
../redis-cli -p 6379 -a 12345678 --eval ipCount.lua 192.168.1.111, 10 20
ttl rate.limit:127.0.0.1
其中 keys[1] = rate.limit:127.0.0.1 argv[1]=10次, argv[2]=20S失效
ipCount.lua内容：
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local expire_time = ARGV[2]
local is_exists = redis.call("EXISTS", key)
if is_exists == 1 then
if redis.call("INCR", key) > limit then
return 0
else
return 1
end
else
redis.call("SET", key, 1)
redis.call("EXPIRE", key, expire_time)
return 1
end执行逻辑：使用redis-cli --eavl时，客户端把lua脚本字符串发给redis服务端，将结果返回客户端，如下图
redis对lua脚本的管理：
1,redis-cli -h 192.168.1.111 -a 12345678 script load "$(cat random.lua)"
将LUA脚本内容加载到redis， 得到 返回的sha1值：afe90689cdeec602e374ebad421e3911022f47c0
redis-cli -h localhost -p 6379 EVALSHA afe90689cdeec602e374ebad421e3911022f47c0 0
再执行得到的值调用
2, 6379〉script exists afe90689cdeec602e374ebad421e3911022f47c0
检查sha1值的LUA脚本是否加载到redis中， 返回1 已加载成功
3, 6379〉script flush
清空加载的lua脚本内容
4,6379〉script kill
杀掉正在执行的LUA脚本，比如LUA比较耗时阻塞，杀掉
发布与订阅
redis提供了“发布、订阅”模式的消息机制，其中消息订阅者与发布者不直接通信，发布者向指定的频道（channel）发布消息，订阅该频道的每个客户端都可以接收到消息
redis主要提供发布消息、订阅频道、取消订阅以及按照模式订阅和取消订阅
发布消息 publish channel:test "hello world"
订阅消息 subscrible channel:test
此时另一个客户端发布一个消息:publish channel:test "james test"当前订阅者客户端会收到如下消息：
和很多专业的消息队列（kafka rabbitmq）,redis的发布订阅显得很lower, 比如无法实现消息规程和回溯， 但就是简单，如果能满足应用场景，用这个也可以
查看订阅数 pubsub numsub channel:test //频道channel:test的订阅数
取消订阅 unsubscribe channel:test //客户端可以通过unsubscribe命令取消对指定频道的订阅，取消后，不会再收到该频道的消息
按模式订阅和取消订阅 psubscribe ch* //订阅以ch开头的所有频道
punsubscribe ch* //取消以ch开头的所有频道
应用场景：
1、今日头条订阅号、微信订阅公众号、新浪微博关注、邮件订阅系统
2、即使通信系统
3、群聊部落系统（微信群）
测试实践：微信班级群 class：20170101
1、学生C订阅一个主题叫 ：class:20170101
>subscribe class:20170101
2、学生A针对class:20170101主体发送消息，那么所有订阅该主题的用户都能够接收到该数据。
>publish class:20170101 "hello world! I am A"
3、学生B针对class:20170101主体发送消息，那么所有订阅该主题的用户都能够接收到该数据。
>publish class:20170101 "hello world! I am B"
展示学生C接受到的A\B同学发送过来的消息信息
1) "subscribe"
2) "class:20170101"
3) (integer) 1
1) "message"
2) "class:20170101"
3) "hello world! I am A"
1) "message"
2) "class:20170101"
3) "hello word! I am B"
代码例子见：redis-publish-subscribe工程