高级命令
keys：全量遍历键，用来列出所有满足特定正则字符串规则的key，当redis数据量比较大时， 性能比较差，要避免使用
127.0.0.1:6379> set codehole1 a
OK
127.0.0.1:6379> set codehole2 b
OK
127.0.0.1:6379> set codehole3 c
OK
127.0.0.1:6379> set code1hole a
OK
127.0.0.1:6379> set code2hole b
OK
127.0.0.1:6379> set code3hole b
OK
127.0.0.1:6379>keys *
1) "codehole1"
2) "code3hole"
3) "codehole3"
4) "code2hole"
5) "codehole2"
6) "code1hole"
127.0.0.1:6379>keys codehole*
1) "codehole1"
2) "codehole2"
3) "codehole3"
127.0.0.1:6379>keys code*hole
1) "code3hole"
2) "code2hole"
3) "code1hole"
scan：渐进式遍历键
SCAN cursor [MATCH pattern] [COUNT count]
scan 参数提供了三个参数，第一个是 cursor 整数值，第二个是 key 的正则模式，第三个是一次遍历的key的数量，并不是符合条件的结果数量。第一次遍历时，cursor 值为 0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束。
127.0.0.1:6379>scan 0 match key99* count 1000
1) "13976"
2) 1) "key9911"
2) "key9974"
3) "key9994"
4) "key9910"
5) "key9907"
6) "key9989"
7) "key9971"
8) "key99"
9) "key9966"
10) "key992"
11) "key9903"
12) "key9905"
......
127.0.0.1:6379>scan 0 match key99* count 1000
1) "0"
2) 1) "key9969"
2) "key998"
3) "key9986"
4) "key9968"
5) "key9965"
6) "key9990"
7) "key9915"
8) "key9928"
9) "key9908"
10) "key9929"
11) "key9944"
Info：查看redis服务运行信息，分为9大块，每个块都有非常多的参数，这 9 个块分别是:
- Server 服务器运行的环境参数
- Clients 客户端相关信息
- Memory 服务器运行内存统计数据
- Persistence 持久化信息
- Stats 通用统计数据
- Replication 主从复制相关信息
- CPU使用情况
- Cluster 集群信息
- KeySpace 键值对统计数量信息
原子加减
//INCR key 将key中储存的数字值加1
//DECR key 将key中储存的数字值减1
//INCRBY key increment 将key所储存的值加上increment
//DECRBY key decrement 将key所储存的值减去decrement
redis> SET rank 50
OK
redis> INCRBY rank 20
(integer) 70
redis> GET rank
"70"
对象缓存
如果是数据完全可以使用JSON方式。redis可以直接set、get。
但担心JSON转对象会消耗资源的情况，这个问题需要考量几个地方。
- 就是使用的JSON转换lib是否就会存在性能问题。
- 第二点：就是数据的数据量级别，如果是存储百万级的大数据对象，建议采用存储序列化对象方式。
如果是少量的数据级对象，或者是数据对象字段不多，还是建议采用JSON转换成String方式。redis对存储字符类型这部分优化的非常好。具体采用的方式与方法，还要看你所使用的场景。
//SET user:1 value(可以是json格式数据)
//MSET user:1:name zhuge user:1:balance 1888
//MGET user:1:name user:1:balance
分布式锁
SETNX product:10001 true //返回1代表获取锁成功
SETNX product:10001 true //返回0代表获取锁失败
//。。。执行业务操作
DEL product:10001 //执行完业务释放锁
SET product:10001 true ex 10 nx //防止程序意外终止导致死锁
为什么可以使用分布式锁的方式？
Redis的单线程和高性能
Redis 单线程为什么还能这么快？
因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性能损耗问题。正因为 Redis 是单线程，所以要小心使用 Redis 指令，对于那些耗时的指令(比如 keys)，一定要谨慎使用，一不小心就可能会导致 Redis 卡顿。
Redis 单线程如何处理那么多的并发客户端连接？
Redis的IO多路复用：redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到 文件事件分派器，事件分派器将事件分发给事件处理器。 Nginx也是采用IO多路复用原理解决C10K问题。
计数器
INCR article:readcount:{文章id}
GET article:readcount:{文章id}
Web集群session共享
spring session + redis实现session共享
分布式系统全局序列号
INCRBY orderId 1000 //redis批量生成序列号提升性能
Hash常用操作
HSET key field value //存储一个哈希表key的键值
HSETNX key field value //存储一个不存在的哈希表key的键值
HMSET key field value [field value ...] //在一个哈希表key中存储多个键值对
HGET key field //获取哈希表key对应的field键值
HMGET key field [field ...] //批量获取哈希表key中多个field键值
HDEL key field [field ...] //删除哈希表key中的field键值
HLEN key //返回哈希表key中field的数量
HGETALL key //返回哈希表key中所有的键值
HINCRBY key field increment //为哈希表key中field键的值加上增量increment
代码示例：
127.0.0.1:6379> hset hashTest id dog
(integer) 1
127.0.0.1:6379> hget hashTest id
"dog"
127.0.0.1:6379> hmset hashTest name dog_1 food bond_1
OK
127.0.0.1:6379> hgetall hashTest
1) "id"
2) "dog"
3) "name"
4) "dog_1"
5) "food"
6) "bond_1"
127.0.0.1:6379> hsetnx hashTest id cat
(integer) 0
127.0.0.1:6379> hkeys hashTest
1) "id"
2) "name"
3) "food"
127.0.0.1:6379> hvals hashTest
1) "dog"
2) "dog_1"
3) "bond_1"
127.0.0.1:6379> hlen hashTest
(integer) 3
127.0.0.1:6379> hdel hashTest id
(integer) 1
127.0.0.1:6379> hlen hashTest
(integer) 2
127.0.0.1:6379> hexists hashTest id
(integer) 0
Hash对象缓存
HMSET user {userId}:name zhuge {userId}:balance 1888
HMSET user 1:name zhuge 1:balance 1888
HMGET user 1:name 1:balance
Hash应用场景
电商购物车
1）以用户id为key
2）商品id为field
3）商品数量为value
购物车操作
添加商品 - - >hset cart:1001 10088 1
增加数量 - - >hincrby cart:1001 10088 1
商品总数 - - >hlen cart:1001
删除商品 - - >hdel cart:1001 10088
获取购物车所有商品 - - >hgetall cart:1001
Hash结构优缺点
优点
1）同类数据归类整合储存，方便数据管理
2）相比string操作消耗内存与cpu更小
3）相比string储存更节省空间
缺点
1）过期功能不能使用在field上，只能用在key上
2）Redis集群架构下不适合大规模使用
