redis-cli -h IP -p PORT -a PASSWORD
# 查看redis信息
info server
# 设置值
set KEY VALUE
mset KEY1 VALUE1 KEY2 VALUE2 KEY3 VALUE3
getset KEY VALUE # 先get值 再set新值
# 设置KEY值SEXONDS秒后过期
setex KEY SEXONDS VALUE
# 如果key不存在,则创建;若存在,则创建失败
setnx KEY VALUE
# 删除值
del KEY1 KEY3 KEY3
# 移动值
move KEY VALUE BD
# 获取值
get KEY1
mget KEY1 KEY3 KEY3
# 判断值是否存在
exists KEY
# 追加值 若key不存在则新增key
append KEY VALUE
# 值加一
incr KEY
# 值减一
decr KEY
# 值加/减x
incrby KEY X
decrby KEY X
# 取值的x-y值
getrange KEY X Y
# 将key位置x开始的值替换为NEWVALUE
setrange KEY X NEWVALUE
用例
set user:mapyking:follow 0
设置计算粉丝数,关注即+1
# 添加VALUE到列表头部/尾部
lpush/rpush LISTKEY VALUE1 VALUE2 VALUE3
# 在VALUE1值前/后加入VALUE2
Linsert LISTKEY before/after VALUE1 VALUE2
# 替换INDEX位置值为value
lset LISTKEY INDEX VALUE
# 获取列表值
lrange LISTKEY START STOP
lindex LISTKEY INDEX
# 从头部/尾部删除值
lpop/rpop LISTKEY
# 移除count个数的指定value值
Lrem LISTKEY count value
# 移动列表1最后一个元素到列表2
rpoplpush LISTKEY LISTKEY2
# 返回列表长度
Llen LISTKEY
# 往set中添加member1
sadd KEY member1 [member2]
# 删除
srem KEY member1 # 随机删除一个 spop KEY
# 查看set所有值
smembers KEY
# 查看元素个数
scard KEY
# 将member1移动到另外一个set中
smove set1 set2 memberx
# 判断member是否存在set中
sismember KEY member1
# 随机从key中抽取x个元素
SRANDMEMBER KEY x
有序集合
# 添加值
zadd key score member score2 member2 [score3 member3]
# 查看值
zrange key 0 -1
# 排序查看
ZRANGEBYSCORE key min max withscores # 从小到大
ZREVRANGE key star stop withscores # 从大到小
#删除元素
zrem key member [member2 ...]
# 获取指定区间的元素
zcount key source1 source2
key-value -> key-map -> key-(key-value)
# 设置值
hset key field value [field2 value2 ...]
# 查看值
hget key field
# 查看所有key/value
hkeys/hvals key
#
hmset key field1 value1 field2 value2 [field3 value3 ...]
#
hmget key field1 field2
hgetall key
# 删除值,field对应value也一起删除
hdel key field
优点:HyperLogLog 的优点在于它所需的内存并不会因为集合的大小而改变,无论集合包含的元素有多少个,HyperLogLog 进行计算所需的内存总是固定的,并且是非常少的。 每个 HyperLogLog 最多只需要花费12KB 内存,在标准误差 0.81% 的前提下,就可以计算2 的64 次方个元素的基数。
# 创建一组元素
PFadd key value1 [value2 value3...]
# 统计key元素个数
PFcount key
# 求并集
PFmerge newkey3 key1 key2
操作二进制位来记录
例如:员工打卡、活跃度
# 设置值
setbit key offset value
# 查看值
getbit key offset
例如员工打卡 1-30天 0为未打卡 1为已打卡
setbit daka 0 1
setbit daka 1 1
setbit daka 2 1
setbit daka 3 0
setbit daka 4 1
…
# 统计员工打卡天数
bitcount daka
redis中单条命令保证原子性,但是事务(一组命令的集合)不保证原子性
① 开启事务
multi
② 进入队列
输入redis命令
set keyA 111
set keyB 111
set keyC 222
get keyA
set keyD 12345
③ 执行
exec
① 放弃事务
# 放弃事务
discard
② 命令语法错误
事务中,命令语法有报错,则整个事务不会被执行
③ 运行时错误
命令语法没问题,但是运行时出现问题,事务可被执行,有问题的语句跳过
悲观锁和乐观锁是并发控制中常用的两种策略。
悲观锁假设在数据访问过程中会发生冲突,因此在访问数据之前就会对其进行加锁,以防止其他事务对其进行修改。悲观锁通常使用数据库锁机制来实现,例如在读取数据时使用共享锁(Shared Lock),在修改数据时使用排他锁(Exclusive Lock)。悲观锁的特点是在整个事务过程中保持数据的独占性,但可能会导致并发性能下降。
乐观锁则假设在数据访问过程中不会发生冲突,因此不会立即对数据进行加锁。相反,它在更新数据时会检查是否有其他事务对其进行了修改。乐观锁通常使用版本号或时间戳等机制来实现。当检测到冲突时,乐观锁会中止当前操作,让应用程序重新尝试。乐观锁的特点是在大部分时间内不需要加锁,因此并发性能较高,但需要处理冲突的情况。
选择使用悲观锁还是乐观锁取决于具体的应用场景和需求。如果冲突的概率较高或对数据的独占性要求较高,可以选择悲观锁。如果冲突的概率较低且并发性能较为重要,可以选择乐观锁。
① watch监视
② 执行事务
set money 100
set cost 0
watch money # 设置监控,事务执行成功后 监控会取消
MULTI
decrby money 30
incrby cost 30
exec
单线程运行没有问题,但是多线程则不会执行
例如:
机器二 已经在watch中
机器一修改key
机器二 exec执行刚刚watch中的事务,则不会执行成功
解决办法:先解锁 再加锁
unwatch
watch