5种数据类型
1. String
添加 :set mystr "hello world!"
获取:get mystr
自加:incr
自减:decr
加: incrby
减: decrby
2. List
lpush mylist "1" :创建列表 并插入头部数据 1
rpush mylist "2"
lpop mylist "2"
rpop mylist "2"
lrange mylist 0 -1 列出mylist中从编号0到倒数第一个元素
3. Set
sadd myset "one"
smembers myset
sunion myset yourset
smembers key1 返回所有数据
4. hash
hset/hget/hmset/hmget/hgetall/hdel
HVALS key 获取哈希表中所有值。
HSCAN key cursor [MATCH pattern] [COUNT count] 迭代哈希表中的键值对。
hlen
hexists key 在key里面的某个值的key
hkeys/hvals
hincrby/hincrbyfloat
hsetnx
5. sort set(zet)
之前set是k1 v1 v2 v3, 现在zset是k1 score1 v1 score2 v2
持久化之
RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到 一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。 整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
优点
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高的情况。
劣势
- 在一定间隔时间做一次备份,所以如果redis意外down掉的话,就 会丢失最后一次快照后的所有修改
- Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑。
AOF(Append Only File)
AOF采用文件追加方式,文件会越来越大。为避免出现此种情况,新增了重写机制, 当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩, 只保留可以恢复数据的最小指令集。可以使用命令bgrewriteao
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename), 遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件, 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
缓存穿透、缓存击穿、缓存雪崩
缓存穿透
比如数据中不存在id=-1的订单数据,如果请求查询这条数据,则缓存中查不到,会将请求打到下层的数据库上,这就是缓存穿透;
查询缓存中不存在的数据会导致缓存穿透。需要注意的是,低频的缓存穿透是不可避免的,但是需要避免高频的缓存穿透。
如果有人恶意并发访问数据库中不存在数据,就可能会导致数据库因扛不住大的并发而引起系统瘫痪!
- 解决方案一:缓存空对象
- 解决方案二:布隆过滤器
Bloom Filter是一个占用空间很小、效率很高的随机数据结构,它由一个bit数组和一组Hash算法构成。可用于判断一个元素是否在一个集合中,查询效率很高,内节省内存空间。
缓存击穿
缓存击穿是缓存穿透的特殊表现之一。一般的公司没有这样的业务,没有这样一条非常热的数据能够导致数据库崩溃,所以不需要解决。
当某个数据被高并发访问时,如果这个数据redis的key的突然失效,会导致这些请求同一时间打到数据库,数据库扛不住就会导致系统瘫痪。
解决方案一:热点数据不过期
解决方案二:分布式锁
缓存雪崩
缓存雪崩也是缓存穿透的特殊表现之一。
上面说的缓存击穿是一个热点key的失效,而缓存雪崩是多个热点key同时失效。
一般出现缓存雪崩的原因是:
缓存过期的时间比较一致,某一时刻key大面积失效。解决办法:将缓存时间设置成一个随机数。
redis挂了,或因为网络抖动访问不了redis了。解决办法:使用redis集群。
参考 https://blog.csdn.net/wuxiaolongah/article/details/106968601