Redis 性能测试 及事务
Redis慢查询分析
与mysql一样:当执行时间超过极大值时，会将发生时间 耗时 命令记录
redis 命令生命周期: 发送 排队 执行 返回
慢查询只统计第3个执行步骤的时间。
慢查询极值设置
注: 有两种方式， 默认为10 毫秒
1). 动态设置6379:> config set slowlog-log-slower-than 10000 //10毫秒
使用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；
1).对慢查询列表清理（重置）：slowlog reset //再查slowlog len 此时返回0 清空；
2).对于线上slow-max-len配置的建议：线上可加大slow-max-len的值，记录慢查询存长命令时redis会做截断，不会占用大量内存，线上可设置1000以上
3).对于线上slowlog-log-slower-than配置的建议：默认为10毫秒，根据redis并发量来调整，对于高并发比建议为1毫秒
4).慢查询是先进先出的队列，访问日志记录出列丢失，需定期执行slowlog get,将结果存储到其它设备中（如mysql）
Redis 上线前应该做的事
1、redis-benchmark -h 192.168.42.111 -p 6379 -c 100 -n 10000
100个并发连接，10000个请求，检测服务器性能
2、redis-benchmark -h 192.168.42.111 -p 6379 -q -d 100
测试存取大小为100字节的数据包的性能
3、redis-benchmark -h 192.168.42.111 -p 6379 -t set,get -n 100000 -q
只测试 set,lpush操作的性能
4、redis-benchmark -h 192.168.42.111 -p 6379 -n 100000 -q script load "redis.call('set','foo','bar')"
只测试某些数值存取的性能
Redis 运行原理流程
发送命令-> 命令排队-> 命令执行-> 返回结果
单个指令批量操作误区
PIPELINE操作流程
性能对比实战
Redis 事务
pipeline是多条命令的组合，为了保证它的原子性，redis提供了简单的事务，。
redis的简单事务，将一组需要一起执行的命令放到multi和exec两个
命令之间，其中multi代表事务开始，exec代表事务结束
watch命令：使用watch后， multi失效，事务失效
总结：redis提供了简单的事务，不支持事务回滚
redis发布与订阅
redis提供了“发布、订阅”模式的消息机制，其中消息订阅者与发布者不直接通信，发布者向指定的频道（channel）发布消息，订阅该频道的每个客户端都可以接收到消息
redis发布与订阅命令
redis主要提供发布消息、订阅频道、取消订阅以及按照模式订阅和取消订阅，和很多专业的消息队列（kafka rabbitmq）,redis的发布订阅显得很lower, 比如
无法实现消息规程和回溯， 但就是简单，如果能满足应用场景，用这个也可以
1.发布消息：
publish channel:test "hello world"
2.订阅消息
subscrible channel:test
3.查看订阅数
pubsub numsub channel:test
4.取消订阅
unsubscribe channel:test
5.按模式订阅和取消订阅
psubscribe ch*
redis发布与订阅－应用场景
1.今日头条订阅号、微信订阅公众号、新浪微博关注、邮件订阅系统
2.即使通信系统
3.群聊部落系统（微信群）
键的迁移－move
把部分数据迁移到另一台redis服务器
move key db //reids有16个库， 编号为0－15
set name james1; move name 5 //迁移到第6个库
select 5 ;//数据库切换到第6个库， get name 可以取到james1
这种模式不建议在生产环境使用，在同一个reids里可以玩
键的迁移-dump
restore key ttl value//实现不同redis实例的键迁移
1,在A服务器上 192.168.42.111
set name james;
dump name; // 得到"\x00\x05james\b\x001\x82;f\"DhJ"
2,在B服务器上：192.168.42.112
restore name 0 "\x00\x05james\b\x001\x82;f\"DhJ" //0代表没有过期时间
get name //返回james
键的迁移-migrate
migrate用于在Redis实例间进行数据迁移，实际上migrate命令是将dump、restore、del三个命令进行组合，从而简化了操作流程。
migrate命令具有原子性，从Redis 3.0.6版本后已经支持迁移多个键的功能。
migrate命令的数据传输直接在源Redis和目标Redis上完成，目标Redis完成restore后会发送OK给源Redis。
比如：把111上的name键值迁移到112上的redis
192.168.42.111:6379> migrate 192.168.42.112 6379 name 0 1000 copy
Key的遍历
键全量遍历
mset country china city bj name james //设置3个字符串键值对
keys * //返回所有的键, *匹配任意字符多个字符
keys *y //以结尾的键，
keys n*e //以n开头以e结尾，返回name
keys n?me // ?问号代表只匹配一个字符 返回name,全局匹配
keys n?m* //返回name
keys [j,l]* //返回以j l开头的所有键 keys [j]ames 全量匹配james
考虑到是单线程， 在生产环境不建议使用，如果键多可能会阻塞
如果键少，可以
两种遍历对比
scan 相比 keys 具备有以下特点:
1，通过游标分布进行的，不会阻塞线程;
2，提供 limit 参数，可以控制每次返回结果的最大条数，limit 不准，返回的结果可多可少;
3，同 keys 一样，Scan也提供模式匹配功能;
4，服务器不需要为游标保存状态，游标的唯一状态就是 scan 返回给客户端的游标整数;
5，scan返回的结果可能会有重复，需要客户端去重复;
6，scan遍历的过程中如果有数据修改，改动后的数据能不能遍历到是不确定的;
7，单次返回的结果是空的并不意味着遍历结束，而要看返回的游标值是否为零;
其它数据结构的遍历
除scan字符串外：还有以下:
?SCAN 命令用于迭代当前数据库中的数据库键。
?SSCAN 命令用于迭代集合键中的元素。
?HSCAN 命令用于迭代哈希键中的键值对。
?ZSCAN 命令用于迭代有序集合中的元素（包括元素成员和元素分值).
用法和scan一样