Redis相关

Redis五种常见的数据类型

1. String
   1. set 存
   2. get 取
   3. incr 自增1
   4. decr 自减
   5. mget 一次性获取多个key值
2. List
   1. lpush：从列表List的左边插入一个元素
   2. lpop：从列表List的左边移出一个元素
   3. rpush：从列表List的右边插入一个元素
   4. rpop：从列表List的右边移出一个元素
   5. llen：打印当前列表List中的元素个数
3. Set
   1. sadd 添加数据
   2. srem 删除
   3. scard 查看set存在个数
   4. sismember 查看是否存在某个数据
4. Hash
   1. hget：通过key值，从hash里取对应的value
   2. hset：往hash里，添加key-value
   3. hmget：一次性获取多个key的value
5. Zset （有序集合）
   1. zadd 
   2. zrem 
   3. zcard 查询
   4. zrange 数据排序，从小到大
   5. zrevrange 数据排序，从大到小

数据类型应用场景

1. string 普通的 key-value键值对都可以用 string来保存
   1. 访问量的统计
   2. 缓存，验证码，手机号盗刷
   3. session共享：布式web服务将用户的Session信息(比如：登录信息)记录到各自服务器中，在负载均衡的情况下，服务器会将用户的访问均衡到不同的服务器上，用户刷新一次访问可能就会发现需要重新登录。问题解决：我们用redis将用户session集中管理，每次获取用户更新或查询登录信息都直接从redis中集中获取
2. list 

   1. 消息队列：list类型的lpop和rpush（或者反过来，lpush和rpop）能实现队列的功能，故而可以用Redis的list类型实现简单的消息队列

   2. 排行榜：list类型的lrange命令可以分页查看队列中的数据. 但是只有定时计算的排行榜才适合使用list类型存储

   3. 最新列表：list类型的lpush命令和lrange命令能实现最新列表的功能，每次通过lpush命令往列表里插入新的元素，然后通过lrange命令读取最新的元素列表，如朋友圈的点赞列表、评论列表。

3. hash

   1. 购物车

   2. 对象缓存：实例化的对象都是被对象名所引用这，并且对象中的各个属性和值是一一对应的   hmset 对象名称 属性1 值1 属性2 值2...

4. set

   1. 好友/关注/粉丝/感兴趣的人集合

   2. 统计网站内所有独立ip

5. zset

   1. 排行榜，因为zset 本来就是有序的，并且有排序功能

Redis去重

        Redis的set：它可以去除重复元素，也可以快速判断某一个元素是否存在于集合中。缺点如果元素很多（比如上亿的计数），占用内存很大。

        Redis的bit：它可以用来实现比set内存高度压缩的计数，它通过一个bit设置为1或者0，表示存储某个元素是否存在信息。例如网站唯一访客计数，可以把user_id作为 bit 的偏移量 offset，如设置为1表示有访问，使用1 MB的空间就可以存放800多万用户的一天访问计数情况。

        HyperLogLog的优点在于，输入元素的数量或者体积非常大时，基数计算的存储空间是固定的。在Redis中，每个HyperLogLog键只需要花费12KB内存，就可以计算接近2^64个不同的基数。比较节省空间，但是不精确

Redis之HyperLogLog_-星雨-的博客-CSDN博客_redis的hyperloglog

        布隆过滤器：布隆过滤器是一种占用空间很小的数据结构，它由一个很长的二进制向量和一组Hash映射函数组成，它用于检索一个元素是否在一个集合中。优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。布隆过滤器的使用_#Hideonbush的博客-CSDN博客_布隆过滤器使用

 Redis持久化

        RDB和AOF两种，RDB为默认

        RDB是在指定的的时间间隔内将内存中的数据集快照写入磁盘，也就是snapshot快照，它恢复时是将快照文件直接读到内存中。

        执行过程：单独创建 （ fork )一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，主进程是不进行任何I0操作的，这就确保了极高的性能

        优点：RDB文件是一个紧凑的二进制压缩文件，是Redis在某个时间点的全部数据快照。所以使用RDB恢复数据的速度远远比AOF的快，非常适合备份、全量复制、灾难恢复等场景。

        缺点：1.如果redis意外宕机了，这个最后一次修改数据就没有的了。2.fork进程的时候，会占用一定的内容空间

        

        AOF持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集

        执行过程：客户端的请求写命令被追加到AOF的缓冲区中，然后缓冲区会根据AOF持久化的策略将操作同步到AOF文件中，如果AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集（AOF重写机制），当redis重启时，会重新加载AOF文件中的写操作达到恢复数据的目的

        优点：数据完整性比较全，AOF持久化的方法使用的是每秒同步一次，最多就只是丢失1秒的数据。如果不小心清空了redis的所有的数据（执行了FLUSHALL），但是AOF文件还没有被重写，我就可以先暂停redis编辑AOF文件，将命令删除（将最后一行的FLUSHALL命令删除），然后重启redis，就可以恢复到执行FLUSHALL命令之前的状态了。（但是当AOF文件已经被重写了，就无法恢复数据了）

        缺点：在相同的数据下，AOF的文件比RDB的文件体积大，而且AOF方式恢复数据的速度比RDB慢

Redis常见问题

        缓存穿透

        描述：是指查询一个根本不存在的数据，缓存层和持久层都不会命中，然后请求都会压到数据库，当并发量大的时候可能会压垮数据库。

        解决：

                1.缓存空对象，并且设置较短的过期时间，防止缓存库过大

                2.使用布隆过滤器进行判断拦截

        缓存击穿

        描述：一个热点的Key，有大并发集中对其进行访问，突然间这个Key失效了，导致大并发全部打在数据库上，导致数据库压力剧增

        解决：

                1.使用互斥锁。如果缓存失效的情况，只有拿到锁才可以查询数据库，降低了在同一时刻打在数据库上的请求，防止数据库打死。当然这样会导致系统的性能变差。

                2.热点的key可以设置永不过期的key

        缓存雪崩

        描述：在同一时间大规模的key失效，导致大量的请求直接打在数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机

        解决：

                1.设置随机的过期时间，均摊分配Redis的key的失效时间

                2.可以做二级缓存，设置较长的过期时间

                3.使用消息中间件解决？

                4.分布式互斥锁：只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可（缺点：在高并发的情况下，也可能会存在死锁和线程池阻塞的风险）

Redis事务

        事务特性：

        原子性（Atomicity）: 事务的原子性是指事物是最小的执行单位，不允许分割，事务内的一系列操作，要不都执行，要不都不执行。

        一致性（Consistency）: 事物的提交只会导致数据库的状态从一个一致性状态到另外一个一致性状态，换句话来说就是事务一系列操作的中间操作导致的中间不一致状态不会让别的事务看到。一致性状态指的是多个事务访问到的数据库的数据和数据结构是一致的。

        隔离性(Isolation): 事务的隔离性是指并发事务在执行过程中不能相互影响，其对数据库的影响和它们串行执行时一样。

        持久性(Durability): 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不会导致提交改变结果的丢失。

        redis原子性分析：redis不支持事务的回滚操作，事务中任意命令执行失败，其余的命令仍会被执行，所以不保证原子性

        redis隔离性分析：redis是用单线程来处理请求，天然就具有隔离性，因为它本来就是串行的执行命令，具有最高的隔离级别。其它客户端的命令无法在Redis事务执行的过程中插入进去，自然也无法影响其事务执行。

        redis持久性分析：redis支持RDB(快照)和AOF两种持久化机制，而AOF是每当有写命令执行时，都将写命令写入磁盘的appendonly.aof文件中，以便机器重启时通过写命令再将数据更新到内存中，AOF方式持久化的实时性更好，以此看来Redis事务其实是具有持久性的

        redis一致性分析：Redis单线程处理请求以及Redis事务在执行时不允许别的命令插入的特点就决定了事务中间操作导致的中间一致性状态不会被其它事务所看到，且Redis可在机器宕机后通过持久化的文件恢复到一致性状态，从这些角度看，Redis事务貌似具有一致性。但Redis不支持事务回滚，意味着它很可能导致现实意义中的不一致性，第一条命令出错，而第二条命令不会受到影响，导致了不一致性

Redis事务(Redis事务与普通关系型数据库事务的区别）_生而知之者为妖的博客-CSDN博客

       

事务错误

        1.执行命令出现错误（命令错误），事务还是会执行，直到事务队列中所有命令执行完成

        2.编译错误，事务不会执行

Redis事务详解_wh柒八九的博客-CSDN博客_redis事务

事务回滚：Redis不支持事务回滚

       不支持事务回滚原因？

       1.Redis 事务的执行时，错误通常都是编程错误造成的，这种错误通常只会出现在开发环境中，而很少会在实际的生产环境中出现，所以他认为没有必要为 Redis 开发事务回滚功能，回滚不能解决编译错误；

       2.不支持事务回滚是因为这种复杂的功能和 Redis 追求的简单高效的设计主旨不符合，而且。