Redis数据结构存储系统:第三章:Redis在项目中如何使用?

简单介绍一个redis?

redis是一个key-value类型的非关系型数据库,基于内存也可持久化的数据库,相对于关系型数据库(数据主要存在硬盘中),性能高,因此我们一般用redis来做缓存使用;并且redis支持丰富的数据类型,比较容易解决各种问题
Redis的Value支持5种数据类型,string、hash、list、set、zset(sorted set);

  String类型是最简单的类型,一个key对应一个value,项目中主要利用单点登录中的token用string类型来存储;

 Hash类型中的key是string类型,value又是一个map(key-value),针对这种数据特性,比较适合存储对象,在项目中由于购物车是用redis来存储的,因为选择redis的散列(hash)来存储;

 List类型是按照插入顺序的字符串链表(双向链表),主要命令是LPUSH和RPUSH,能够支持反向查找和遍历,如果使用的话主要存储商品评论列表,key是该商品的ID,value是商品评论信息列表;

 Set类型是用哈希表类型的字符串序列,没有顺序,集合成员是唯一的,没有重复数据,底层主要是由一个value永远为null的hashmap来实现的。

我们的电商项目中没有用到这个数据类型。这个应用场景一般存储一个列表数据,但列表里面又不希望出现重复数据,比如微博应用中,可以将一个用户所有关注的对象放在一个集合中,将其所有粉丝存在一个集合,这样我们就可以实现两个人的共同好友、共同关注等需求;

zset(sorted set)类型和set类型基本是一致的,不同的是zset这种类型会给每个元素关联一个double类型的分数(score),这样就可以为成员排序,并且插入是有序的。这种数据类型如果使用的话主要用来统计商品的销售排行榜,比如:items:sellsort 10 1001 20 1002 这个代表编号是1001的商品销售数量为10,编号为1002的商品销售数量为20。

(3)我们项目中主要用redis的java客户端Jedis来操作redis数据库,用来缓存各种操作频繁,不经常修改的数据,这样就减轻了数据库的访问压力,提高了查询效率

你还用过其他的缓存吗?这些缓存有什么区别?都在什么场景下去用?

 对于缓存了解过redis和memcache,redis我们在项目中用的比较多,memcache没用过,但是了解过一点;

 Memcache和redis的区别:

    数据支持的类型:

    存储方式:redis不仅仅支持简单的k/v类型的数据,同时还支持list、set、zset、hash等数据结构的存储;memcache只支持简单的k/v类型的数据,key和value都是string类型

    可靠性:memcache不支持数据持久化,断电或重启后数据消失,但其稳定性是有保证的;redis支持数据持久化和数据恢复,允许单点故障,但是同时也会付出性能的代价

    性能上:对于存储大数据,memcache的性能要高于redis

应用场景:

Memcache:适合多读少写,大数据量的情况(一些官网的文章信息等)

Redis:适用于对读写效率要求高、数据处理业务复杂、安全性要求较高的系统

Redis在你们项目中是怎么用的?

门户系统中的首页内容信息的展示。(商品类目、广告、热门商品等信息)门户系统的首页是用户访问量最大的,而且这些数据一般不会经常修改,因此为了提高用户的体验,我们选择将这些内容放在缓存中;
单点登录系统中也用到了redis。因为我们是分布式系统,存在session之间的共享问题,因此在做单点登录的时候,我们利用redis来模拟了session的共享,来存储用户的信息,实现不同系统的session共享;
我们项目中同时也将购物车的信息设计存储在redis中,购物车在数据库中没有对应的表,用户登录之后将商品添加到购物车后存储到redis中,key是用户id,value是购物车对象;
因为针对评论这块,我们需要一个商品对应多个用户评论,并且按照时间顺序显示评论,为了提高查询效率,因此我们选择了redis的list类型将商品评论放在缓存中;
在统计模块中,我们有个功能是做商品销售的排行榜,因此选择redis的zset结构来实现;

还有一些其他的应用场景,主要就是用来作为缓存使用。

对redis的持久化了解不?

   Redis是内存型数据库,同时它也可以持久化到硬盘中,redis的持久化方式有两种:

RDB(半持久化方式):

按照配置不定期的通过异步的方式、快照的形式直接把内存中的数据持久化到磁盘的一个dump.rdb文件(二进制文件)中;

这种方式是redis默认的持久化方式,它在配置文件(redis.conf)中的格式是:save N M,表示的是在N秒之内发生M次修改,则redis抓快照到磁盘中;

原理:当redis需要持久化的时候,redis会fork一个子进程,这个子进程会将数据写到一个临时文件中;当子进程完成写临时文件后,会将原来的.rdb文件替换掉,这样的好处是写时拷贝技术(copy-on-write),可以参考下面的流程图;
在这里插入图片描述












优点:只包含一个文件,对于文件备份、灾难恢复而言,比较实用。因为我们可以轻松的将一个单独的文件转移到其他存储媒介上;性能最大化,因为对于这种半持久化方式,使用的是写时拷贝技术,可以极大的避免服务进程执行IO操作;相对于AOF来说,如果数据集很大,RDB的启动效率就会很高 缺点:如果想保证数据的高可用(最大限度的包装数据丢失),那么RDB这种半持久化方式不是一个很好的选择,因为系统一旦在持久化策略之前出现宕机现象,此前没有来得及持久化的数据将会产生丢失;rdb是通过fork进程来协助完成持久化的,因此当数据集较大的时候,我们就需要等待服务器停止几百毫秒甚至一秒;

AOF(全持久化的方式)

把每一次数据变化都通过write()函数将你所执行的命令追加到一个appendonly.aof文件里面;

事实上,不会立即将命令写入硬盘文件中,而是写入硬盘缓存,可以配置策略,配置多久从硬盘缓存写入到硬盘文件中。

Appendfsync always

Appendfsync everysec 默认的

Appendfsync no 不主动,默认30秒一次

Redis默认是不支持这种全持久化方式的,需要将no改成yes

在这里插入图片描述

















实现文件刷新的三种方式:

在这里插入图片描述










no:不会自动同步到磁盘上,需要依靠OS(操作系统)进行刷新,效率快,但是安全性就比较差;

always:每提交一个命令都调用fsync刷新到aof文件,非常慢,但是安全;

everysec:每秒钟都调用fsync刷新到aof文件中,很快,但是可能丢失一秒内的数据,推荐使用,兼顾了速度和安全;

原理:redis需要持久化的时候,fork出一个子进程,子进程根据内存中的数据库快照,往临时文件中写入重建数据库状态的命令;父进程会继续处理客户端的请求,除了把写命令写到原来的aof中,同时把收到的写命令缓存起来,这样包装如果子进程重写失败的话不会出问题;当子进程把快照内容以命令方式写入临时文件中后,子进程会发送信号给父进程,父进程会把缓存的写命令写入到临时文件中;接下来父进程可以使用临时的aof文件替换原来的aof文件,并重命名,后面收到的写命令也开始往新的aof文件中追加。下面的图为最简单的方式,其实也是利用写时复制原则。
在这里插入图片描述








优点:

数据安全性高

该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机问题,也不会破坏日志文件中已经存在的内容;

缺点:

对于数量相同的数据集来说,aof文件通常要比rdb文件大,因此rdb在恢复大数据集时的速度大于AOF;

根据同步策略的不同,AOF在运行效率上往往慢于RDB,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效;

针对以上两种不同的持久化方式,如果缓存数据安全性要求比较高的话,用aof这种持久化方式(比如项目中的购物车);如果对于大数据集要求效率高的话,就可以使用默认的。而且这两种持久化方式可以同时使用。  

做过redis的集群吗?你们做集群的时候搭建了几台,都是怎么搭建的?

针对这类问题,我们首先考虑的是为什么要搭建集群?(这个需要针对我们的项目来说)

Redis的数据是存放在内存中的,这就意味着redis不适合存储大数据,大数据存储一般公司常用hadoop中的Hbase或者MogoDB。因此redis主要用来处理高并发的,用我们的项目来说,电商项目如果并发大的话,一台单独的redis是不能足够支持我们的并发,这就需要我们扩展多台设备协同合作,即用到集群。

Redis搭建集群的方式有多种,例如:客户端分片、Twemproxy、Codis等,但是redis3.0之后就支持redis-cluster集群,这种方式采用的是无中心结构,每个节点保存数据和整个集群的状态,每个节点都和其他所有节点连接。如果使用的话就用redis-cluster集群。

集群这块直接说是公司运维搭建的,小公司的话也有可能由我们自己搭建,开发环境我们也可以直接用单机版的。但是可以了解一下redis的集群版。搭建redis集群的时候,对于用到多少台服务器,每家公司都不一样,大家针对自己项目的大小去衡量。举个简单的例子:

我们项目中redis集群主要搭建了6台,3主(为了保证redis的投票机制)3从(高可用),每个主服务器都有一个从服务器,作为备份机。

架构图如下:
在这里插入图片描述













所有的节点都通过PING-PONG机制彼此互相连接;
每个节点的fail是通过集群中超过半数的节点检测失效时才生效;
客户端与redis集群连接,只需要连接集群中的任何一个节点即可;
Redis-cluster把所有的物理节点映射到【0-16383】slot上,负责维护

2、容错机制(投票机制)

(1)选举过程是集群中的所有master都参与,如果半数以上master节点与故障节点连接超过时间,则认为该节点故障,自动会触发故障转移操作;

(2)集群不可用?

 a:如果集群任意master挂掉,并且当前的master没有slave,集群就会fail;

 b:如果集群超过半数以上master挂掉,无论是否有slave,整个集群都会fail;

6、redis有事务吗?

Redis是有事务的,redis中的事务是一组命令的集合,这组命令要么都执行,要不都不执行,redis事务的实现,需要用到MULTI(事务的开始)和EXEC(事务的结束)命令 ;
在这里插入图片描述











当输入MULTI命令后,服务器返回OK表示事务开始成功,然后依次输入需要在本次事务中执行的所有命令,每次输入一个命令服务器并不会马上执行,而是返回”QUEUED”,这表示命令已经被服务器接受并且暂时保存起来,最后输入EXEC命令后,本次事务中的所有命令才会被依次执行,可以看到最后服务器一次性返回了两个OK,这里返回的结果与发送的命令是按顺序一一对应的,这说明这次事务中的命令全都执行成功了。

Redis的事务除了保证所有命令要不全部执行,要不全部不执行外,还能保证一个事务中的命令依次执行而不被其他命令插入。同时,redis的事务是不支持回滚操作的。

【扩展】

Redis的事务中存在一个问题,如果一个事务中的B命令依赖上一个命令A怎么办?

这会涉及到redis中的WATCH命令:可以监控一个或多个键,一旦其中有一个键被修改(或删除),之后的事务就不会执行,监控一直持续到EXEC命令(事务中的命令是在EXEC之后才执行的,EXEC命令执行完之后被监控的键会自动被UNWATCH)。

应用场景:待定
【扩展】

redis的安全机制(你们公司redis的安全这方面怎么考虑的?)

漏洞介绍:redis默认情况下,会绑定在bind 0.0.0.0:6379,这样就会将redis的服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在访问目标服务器的情况下未授权访问redis以及读取redis的数据,攻击者就可以在未授权访问redis的情况下可以利用redis的相关方法,成功在redis服务器上写入公钥,进而可以直接使用私钥进行直接登录目标主机;

比如:可以使用FLUSHALL方法,整个redis数据库将被清空

解决方案:

禁止一些高危命令。修改redis.conf文件,用来禁止远程修改DB文件地址,比如 rename-command FLUSHALL "" 、rename-command CONFIG"" 、rename-command EVAL “”等;
以低权限运行redis服务。为redis服务创建单独的用户和根目录,并且配置禁止登录;
为redis添加密码验证。修改redis.conf文件,添加

requirepass mypassword;

禁止外网访问redis。修改redis.conf文件,添加或修改 bind 127.0.0.1,使得redis服务只在当前主机使用;
做log监控,及时发现攻击;

redis的哨兵机制(redis2.6以后出现的)

哨兵机制:

监控:监控主数据库和从数据库是否正常运行;

    提醒:当被监控的某个redis出现问题的时候,哨兵可以通过API向管理员或者其他应用程序发送通知;

    自动故障迁移:主数据库出现故障时,可以自动将从数据库转化为主数据库,实现自动切换;

具体的配置步骤面试中可以说参考的网上的文档。要注意的是,如果master主服务器设置了密码,记得在哨兵的配置文件(sentinel.conf)里面配置访问密码

3、缓存穿透

缓存查询一般都是通过key去查找value,如果不存在对应的value,就要去数据库中查找。如果这个key对应的value在数据库中也不存在,并且对该key并发请求很大,就会对数据库产生很大的压力,这就叫缓存穿透

解决方案:

    对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合则丢弃。还有最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。
    也可以采用一个更为简单粗暴的方法,如果一个查询返回的数据为空(不管是数 据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。

4、缓存雪崩

当缓存服务器重启或者大量缓存集中在一段时间内失效,发生大量的缓存穿透,这样在失效的瞬间对数据库的访问压力就比较大,所有的查询都落在数据库上,造成了缓存雪崩。

这个没有完美解决办法,但可以分析用户行为,尽量让失效时间点均匀分布。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程(进程)写,从而避免失效时大量的并发请求落到底层存储系统上。

解决方案:

    在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。
    可以通过缓存reload机制,预先去更新缓存,再即将发生大并发访问前手动触发加载缓存
    不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀
    做二级缓存,或者双缓存策略。A1为原始缓存,A2为拷贝缓存,A1失效时,可以访问A2,A1缓存失效时间设置为短期,A2设置为长期。

redis中对于生存时间的应用

Redis中可以使用expire命令设置一个键的生存时间,到时间后redis会自动删除;

应用场景:

设置限制的优惠活动的信息;
一些及时需要更新的数据,积分排行榜;
手机验证码的时间;
限制网站访客访问频率;