巴拉巴

 找回密码
 立即注册

站内搜索

搜索
热搜: 活动 交友 discuz
查看: 45|回复: 0

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

[复制链接]

3

主题

3

帖子

9

积分

新手上路

Rank: 1

积分
9
发表于 2023-2-2 16:13:20 | 显示全部楼层 |阅读模式
简单介绍一个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模式,因此在写入过程中即使出现宕机问题,也不会破坏日志文件中已经存在的内容;
来源:http://www.yidianzixun.com/article/0m0Vp2pB
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

  • 返回顶部