Redis使用笔记

redis是一个非关系型数据库，速度极快，基于key-value存储，redis是单线程的。

 

redis为什么这么快(官方说可以达到100000的QPS(每秒查询次数))：

1.Redis 将数据储存在内存里面，读写数据的时候都不会受到硬盘 I/O 速度的限制，所以速度极快；

2.数据结构简单，对数据操作也简单；

3.采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU；

4.使用多路I/O复用模型，非阻塞IO；

 

 

redis的常用使用场景：

1.缓存，通过缓存可以减轻服务器的压力，在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库。

 

缓存的实现模型：

不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现会导致数据一致性的问题：

(1).如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。

(2).如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。

解决办法(1)：延时双删+设置过期时间

伪代码：

public void write( String key, Object data ) {

           redis.delKey( key );//第一次删除

           db.updateData( data );

           Thread.sleep( 500 );

           redis.delKey( key );//第二次删除

}

从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。所有的写操作以数据库为准，只要到达缓存过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。

解决办法(2):引入分布式事务解决(复杂程度高)

 

2.排行榜，利用Redis的SortSet数据结构能够非常方便搞定；

 

3.计算器/限速器，利用Redis中原子性的自增操作，我们可以统计类似用户点赞数、用户访问数等，这类操作如果用MySQL，频繁的读写会带来相当大的压力；限速器比较典型的使用场景是限制某个用户访问某个API的频率，常用的有抢购时，防止用户疯狂点击带来不必要的压力；

 

4.简单消息队列，除了Redis自身的发布/订阅模式，我们也可以利用List来实现一个队列机制，比如：到货通知、邮件发送之类的需求，不需要高可靠，但是会带来非常大的DB压力，完全可以用List来完成异步解耦；

 

5.Session共享，以PHP为例，默认Session是保存在服务器的文件中，如果是集群服务，同一个用户过来可能落在不同机器上，这就会导致用户频繁登陆；采用Redis保存Session后，无论用户落在那台机器上都能够获取到对应的Session信息。

 

redis常用的五种数据结构(共有8种，指value的值，key都是string)

(1)String:格式: set key value

(2)Hash(哈希): 格式: hmset name key1 value1 key2 value2

hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

(3)List(列表)： 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边） 格式: lpush name value

(4)Set(集合)：格式: sadd name value   Redis的Set是string类型的无序集合。 集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

(5)ZSet(有效集合)：格式: zadd name score value     Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。 不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

redis的持久化：

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。 Redis 提供了两种持久化方式:RDB（默认） 和AOF RDB：

它的功能核心函数rdbSave(生成RDB文件)和rdbLoad（从文件加载内存）。

 

redis的架构模式：

单机版：

特点：简单 问题： 1、内存容量有限 2、处理能力有限 3、无法高可用。

主从复制：

特点：1.master/slave 角色 2.master/slave 数据相同  3.降低 master 读压力在转交从库

问题：1.无法保证高可用   2.没有解决 master 写的压力

 

哨兵：

Redis sentinel 是一个分布式系统中监控 redis 主从服务器，并在主服务器下线时自动进行故障转移。其中三个特性：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。

特点：1.保证高可用    2.监控各个节点   3.自动故障迁移

缺点：1.主从模式，切换需要时间丢数据   2.没有解决 master 写的压力

 

集群（直连型）：

从redis 3.0之后版本支持redis-cluster集群，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。

特点：1.无中心架构（不存在哪个节点影响性能瓶颈），少了 proxy 层。

2.数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。

3.可扩展性，可线性扩展到 1000 个节点，节点可动态添加或删除。

4.高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本

5.实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave到 Master的角色提升。

缺点：1.资源隔离性较差，容易出现相互影响的情况。   2.数据通过异步复制,不保证数据的强一致性

 

 

redis缓存穿透：

一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。一些恶意的请求会故意查询不存在的key,请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。

如何避免？ 1：对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。 2：对一定不存在的key进行过滤。

 

 

redis缓存雪崩：

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给后端系统带来很大压力。导致系统崩溃。