redis的increment如何使用 redis increment原理

五种数据结构

String、Hash、List、Set、ZSet

String

常用操作:

单值存储：					SET  key  value
单值获取：					GET  key
批量存储：					MSET  key  value [key value ,...] 
批量获取：					MGET  key  [key ...]
单值删除：					DEL  key  [key ...]
存入一个不存在的字符串键值对：	SETNX  key  value	
将key中储存的数字值加1：		INCR  key
将key中储存的数字值减1：		DECR  key
对key所储存的值做加法：		INCRBY  key  increment
对key所储存的值做减法：		DECRBY  key  decrement 
设置键的过期时间(秒)：			EXPIRE  key  seconds

String应用场景：

1、实现分布式锁：

SETNX  product:10001  true 			//返回1代表获取锁成功，返回0代表获取锁失败
DEL  product:10001					//执行完业务释放锁
SET product:10001 true  ex  10  nx	//防止程序意外终止导致死锁

2、计数器：

INCR  key 对某个操作，或者某篇文章阅读量进行自增

3、生成分布式id：

比如reids中id初始值为0，INCRBY id 1000之后得到id为1000
然后在把这个id再-1000，在内存对id从0开始进行++，当++到==这个id时，再去redis那最新的id，继续生成。
但是这种方法如果服务器宕机了，会丢失部分id导致id不连续。

Hash

常用操作：

存储一个哈希表key的键值：					HSET  key  field  value
存储一个不存在的哈希表key的键值：			HSETNX  key  field  value
在一个哈希表key中存储多个键值对：			HMSET  key  field  value [field value ...]
获取哈希表key对应的field键值：				HGET  key  field
批量获取哈希表key中多个field键值：			HMGET  key  field  [field ...]
删除哈希表key中的field键值：				HDEL  key  field  [field ...]
返回哈希表key中field的数量：				HLEN  key
返回哈希表key中所有的键值：					HGETALL  key
为哈希表key中field键的值加上增量increment：	HINCRBY  key  field  increment

Hash应用场景：

1、对象缓存 ：

HMSET  user  {userId}:name  张三 {userId}:age  18

2、电商购物车：

以用户id为key、商品id为field、商品数量为value
1001：{用户id}，{商品id}：10088，{商品数量}：1
添加商品：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储存更节省空间

Hash缺点：

1、过期功能不能使用在field上，只能用在key上
2、Redis集群架构下不适合大规模使用，

List

常用操作：

将一个或多个值value插入到key列表的表头(最左边)：	LPUSH  key  value [value ...] 
将一个或多个值value插入到key列表的表尾(最右边)：	RPUSH  key  value [value ...]
移除并返回key列表的头元素：						LPOP  key
移除并返回key列表的尾元素：						RPOP  key
返回列表key中指定区间内的元素，区间以索引start和stop指定：LRANGE  key  start  stop
从key列表表头弹出一个元素，若列表中没有元素，阻塞等待，如果timeout=0,一直阻塞等待：BLPOP  key  [key ...]  timeout（秒）
从key列表表尾弹出一个元素，若列表中没有元素，阻塞等待，如果timeout=0,一直阻塞等待：BRPOP  key  [key ...]  timeout（秒）

List可以实现多种数据结构：

Stack(栈) = LPUSH + LPOP
Queue(队列）= LPUSH + RPOP
Blocking MQ(阻塞队列）= LPUSH + BRPOP

List应用场景：

1、微博和微信公号消息流

比如用户关注了多个公众号
1、公众号1发布消息，消息ID为1：LPUSH  msg:{用户ID}  1
2、公众号2发布消息，消息ID为2：LPUSH  msg:{用户ID}  2
3、查看最新公众号消息拿到索引0-1的数据：LRANGE  msg:{用户ID}  0 1

Set

常用操作：

往集合key中存入元素
key不存在则新建，元素存在则忽略：				SADD  key  member  [member ...]
从集合key中删除元素：							SREM  key  member  [member ...]
获取集合key中所有元素：						SMEMBERS  key
获取集合key的元素个数：						SCARD  key
判断member元素是否存在于集合key中：				SISMEMBER  key  member
从集合key中选出count个元素，元素不从key中删除：	SRANDMEMBER  key  [count]
从集合key中选出count个元素，元素从key中删除：		SPOP  key  [count]

交集运算：									SINTER  key  [key ...]
将交集结果存入新集合destination中：				SINTERSTORE  destination  key  [key ..]
并集运算：									SUNION  key  [key ..]
将并集结果存入新集合destination中：				SUNIONSTORE  destination  key  [key ...]
差集运算：									SDIFF  key  [key ...]
将差集结果存入新集合destination中：				SDIFFSTORE  destination  key  [key ...]

Set应用场景：

1、微信抽奖小程序：

点击参与抽奖加入集合：SADD key {userlD}
查看参与抽奖所有用户：SMEMBERS key	  
抽取count名中奖者：
SRANDMEMBER key [count]：元素不从key中删除，适用于集合只进行一次抽奖场景
SPOP key [count]：元素从key中删除，适用于集合可多次抽奖，把中奖的人移出集合，保证不会再次中奖

2、微信微博点赞、收藏：

点赞：SADD like:{消息ID}  {用户ID}
取消点赞：SREM like:{消息ID}  {用户ID}
检查用户是否点过赞：SISMEMBER like:{消息ID}  {用户ID}
获取点赞的用户列表：SMEMBERS like:{消息ID}
获取点赞用户数：SCARD like:{消息ID}

3、集合操作实现微博微信关注模型：

张三关注的人：SADD  focu:zhangsan lisi wangwu
李四关注的人：SADD  focu:lisi focu:zhangsan wangwu zhaoliu zhangfei
王五关注的人：SADD  focu:wangwu  focu:zhangsan lisi zhaoliu zhangfei zhaoyun
张三和李四的共同关注(王五)：SINTER focu:zhangsan focu:lisi
张三关注的人也关注他(王五)：SISMEMBER focu:lisi wangwu(如果返回1表示李四也关注了王五)
在王五主页中张三可能认识的人：SDIFF focu:wangwu focu:zhangsan

ZSet

常用操作：

往有序集合key中加入带分值元素：					ZADD key score member [[score member]…]
从有序集合key中删除元素：						ZREM key member [member …]
返回有序集合key中元素member的分值：				ZSCORE key member 
为有序集合key中元素member的分值加上increment ：	ZINCRBY key increment member
返回有序集合key中元素个数：						ZCARD key
从小到大获取key中从start到stop下标元素及分值：	ZRANGE key start stop WITHSCORES
从大到小获取key中从start到stop下标元素及分值：	ZREVRANGE key start stop WITHSCORES

并集计算：ZUNIONSTORE destkey numkeys key [key ...]
交集计算：ZINTERSTORE destkey numkeys key [key …]

Zset应用场景：

1、Zset集合操作实现排行榜：

点击新闻：
ZINCRBY hotNews:20220803 1 zhangsan  //对zhangsan这条新闻分值+1
ZINCRBY hotNews:20220803 1 lisi		 //对lisi这条新闻分值+1

展示当日排行前十：ZREVRANGE  hotNews:20220803  0  9  WITHSCORES

七日搜索榜单计算：计算7天的key的并集，并添加到hotNews:seven这个key中：
ZUNIONSTORE  hotNews:seven 7 hotNews:20220803  hotNews:20220804 ......

展示七日排行前十：ZREVRANGE hotNews:seven 0 9 WITHSCORES

Redis的单线程和高性能

Redis是单线程吗？

Redis 的单线程主要是指网络IO和键值对读写的这些主要流程是单线程来完成的，但Redis的其他功能，比如持久化、异步删除、集群数据同步等，是由额外的线程执行的。

Redis单线程高性能原因

因为它所有的数据都在内存中，所有的运算都是内存级别的运算，而且单线程避免了多线程的切换性能损耗问题。并且Redis使用NIO多路复用并发处理客户端连接，redis利用epoll来实现IO多路复用，将连接信息和事件放到队列中，依次放到文件事件分派器，事件分派器将事件分发给事件处理器。

其他高级命令：

keys：
全量遍历键，用来列出所有满足特定正则（通配符）字符串规则的key，但redis数据量比较大时，性能比较差，要避免使用。
scan：
渐进式遍历键，SCAN cursor [MATCH pattern] [COUNT count]
scan 参数提供了三个参数：
第一个是 cursor 整数值(hash桶的索引值，也叫游标)
第二个是 key 的正则模式
第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，第一次遍历时cursor 值为 0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束。
如果在scan的过程中如果有键的变化（增加、 删除、 修改） ，那么遍历效果可能会碰到如下问题： 新增的键可能没有遍历到， 遍历出了重复的键等情况， 也就是说scan并不能保证完整的遍历出来所有的键。
Info：
查看redis服务运行信息，分为 9 大块，这 9 个块分别是:

Server 			# 服务器运行的环境参数 
Clients 		# 客户端相关信息 
Memory 			# 服务器运行内存统计数据 
Persistence 	# 持久化信息 
Stats 			# 通用统计数据 
Replication 	# 主从复制相关信息 
CPU CPU 		# 使用情况 
Cluster 		# 集群信息 
KeySpace 		# 键值对统计数量信息

核心参数：

connected_clients:2              # 正在连接的客户端数量
instantaneous_ops_per_sec:789    # 每秒执行多少次指令
used_memory:929864               # Redis分配的内存总量(byte)，包含redis进程内部的开销和数据占用的内存
used_memory_human:908.07K        # Redis分配的内存总量(Kb)
used_memory_rss_human:2.28M      # 向操作系统申请的内存大小，一般大于used_memory，Redis的内存分配策略会产生内存碎片
used_memory_peak:929864          # redis的内存消耗峰值(byte)
used_memory_peak_human:908.07K   # redis的内存消耗峰值(KB)
maxmemory:0                      # 配置中设置的最大可使用内存值(byte),默认0,不限制，一般配置为机器物理内存的百分之七八十
maxmemory_human:0B               # 配置中设置的最大可使用内存值
maxmemory_policy:noeviction      # 当达到maxmemory时的淘汰策略

Redis 事物

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。Redis事务没有隔离级别的概念，批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。
Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

事物操作命令：

MULTI ：开启事务，redis会将后续的命令逐个放入队列中，然后使用EXEC命令来原子化执行这个命令系列。
EXEC：执行事务中的所有操作命令。
DISCARD：取消事务，放弃执行事务块中的所有命令。
WATCH：监视一个或多个key,如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。我们程序需要做的，就是不断重试这个操作， 直到没有发生碰撞为止，watch指令类似于乐观锁，同样也实现了CAS行为。
UNWATCH：取消WATCH对所有key的监视，

如果在事务队列中存在命令性错误（类似于java编译性错误），则执行EXEC命令时，所有命令都不会执行。如果在事务队列中存在语法性错误（比如incr了一个String类型的value，类似于java的运行时异常），则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。并且一但执行 EXEC 开启事务的执行后，无论事务使用执行成功， WARCH 对变量的监控都将被取消。所以当事务执行失败后，需要重新执行WATCH命令对变量进行监控，并开启新的事务进行操作。

为什么 Redis 事物不支持回滚？

1、Redis 命令只会因为错误的语法而失败，或是命令用在了错误类型的键上面：这也就是说，失败的命令是由编程错误造成的，所以这些错误原本就是不存在的，所以不需要回滚。
2、因为不需要对回滚进行支持，所以 Redis 在执行效率上可以保持简单且快速。