Redis面试

1.为什么使用NoSQL?

反面
1.传统数据库存在性能瓶颈,无法应对每秒上万次的读写请求
2.关系型数据库很多主要特性无用武之地:比如关联查询因为性能低下,
设计者从一开始就想方法避免,往往更多设计单表查询,sql功能被弱化;
事务一致性需求下降,关系数据库每插入一条数据,立刻查询就查到,
但现代web应用并不需要,过10来秒再完成同步,完全可以接受

正面
1.海量数据下,读写性能优异
2.数据间无关系,易于扩展

2.redis和mysql的关系

web应用中一般采用MySQL+Redis的方式,web应用每次先访问Redis,如果没有
找到数据,才去访问MySQL。

Redis是内存数据库,数据保存在内存中,访问速度快。MySQL是关系型数据库,
功能强大,持久化存储,存储在磁盘中,数据访问速度慢。像memcached,MongoDB,
Redis等,都属于No sql系列

3.分布式数据库的CAP原理

一个分布式系统最多只能同时满足 一致性(Consistency),可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项

 CA 传统Oracle数据库
 AP 大多数网站架构的选择
 CP Redis、Mongodb

一致性(Consistency)
一致性(Consistency),说的是每一个更新成功后,分布式系统中的所有节点,都能读到最新的信息。即所有节点相当于访问同一份内容,这样的系统就被认为是强一致性的。

可用性(Availability)
可用性(Availability),是每一个请求,都能得到响应。请求只需要在一定时间内返回即可,结果可以是成功或者失败,也不需要确保返回的是最新版本的信息。

分区容错性(Partition tolerance)
分区容错性(Partition tolerance),是说在网络中断,消息丢失的情况下,系统照样能够工作。这里的网络分区是指由于某种原因,网络被分成若干个孤立的区域,而区域之间互不相通。

这里可以初亏出,如果要满足P,就很难同时满足C和A。

4.BASE原理

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

    基本可用(Basically Available)
    软状态(Soft state)
    最终一致(Eventually consistent)

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。
为什么这么说呢,缘由就在于大型系统往往由于地域分布和极高性能的要求,不可能采用分布式
事务来完成这些指标,要想获得这些指标,我们必须采用另外一种方式来完成,这里BASE就是解
决这个问题的办法

5.Redis配置文件介绍

参数说明
redis.conf 配置项说明如下:
1. Redis默认不是以守护进程的方式运行,可以通过该配置项修改,使用yes启用守护进程
  daemonize no
2. 当Redis以守护进程方式运行时,Redis默认会把pid写入/var/run/redis.pid文件,可以通过pidfile指定
  pidfile /var/run/redis.pid
3. 指定Redis监听端口,默认端口为6379,作者在自己的一篇博文中解释了为什么选用6379作为默认端口,因为6379在手机按键上MERZ对应的号码,而MERZ取自意大利歌女Alessia Merz的名字
  port 6379
4. 绑定的主机地址
  bind 127.0.0.1
5.当 客户端闲置多长时间后关闭连接,如果指定为0,表示关闭该功能
  timeout 300
6. 指定日志记录级别,Redis总共支持四个级别:debug、verbose、notice、warning,默认为verbose
  loglevel verbose
7. 日志记录方式,默认为标准输出,如果配置Redis为守护进程方式运行,而这里又配置为日志记录方式为标准输出,则日志将会发送给/dev/null
  logfile stdout
8. 设置数据库的数量,默认数据库为0,可以使用SELECT <dbid>命令在连接上指定数据库id
  databases 16
9. 指定在多长时间内,有多少次更新操作,就将数据同步到数据文件,可以多个条件配合
  save <seconds> <changes>
  Redis默认配置文件中提供了三个条件:
  save 900 1
  save 300 10
  save 60 10000
  分别表示900秒(15分钟)内有1个更改,300秒(5分钟)内有10个更改以及60秒内有10000个更改。
 
10. 指定存储至本地数据库时是否压缩数据,默认为yes,Redis采用LZF压缩,如果为了节省CPU时间,可以关闭该选项,但会导致数据库文件变的巨大
  rdbcompression yes
11. 指定本地数据库文件名,默认值为dump.rdb
  dbfilename dump.rdb
12. 指定本地数据库存放目录
  dir ./
13. 设置当本机为slav服务时,设置master服务的IP地址及端口,在Redis启动时,它会自动从master进行数据同步
  slaveof <masterip> <masterport>
14. 当master服务设置了密码保护时,slav服务连接master的密码
  masterauth <master-password>
15. 设置Redis连接密码,如果配置了连接密码,客户端在连接Redis时需要通过AUTH <password>命令提供密码,默认关闭
  requirepass foobared
16. 设置同一时间最大客户端连接数,默认无限制,Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数,如果设置 maxclients 0,表示不作限制。当客户端连接数到达限制时,Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
  maxclients 128
17. 指定Redis最大内存限制,Redis在启动时会把数据加载到内存中,达到最大内存后,Redis会先尝试清除已到期或即将到期的Key,当此方法处理 后,仍然到达最大内存设置,将无法再进行写入操作,但仍然可以进行读取操作。Redis新的vm机制,会把Key存放内存,Value会存放在swap区
  maxmemory <bytes>
18. 指定是否在每次更新操作后进行日志记录,Redis在默认情况下是异步的把数据写入磁盘,如果不开启,可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认为no
  appendonly no
19. 指定更新日志文件名,默认为appendonly.aof
   appendfilename appendonly.aof
20. 指定更新日志条件,共有3个可选值: 
  no:表示等操作系统进行数据缓存同步到磁盘(快) 
  always:表示每次更新操作后手动调用fsync()将数据写到磁盘(慢,安全) 
  everysec:表示每秒同步一次(折衷,默认值)
  appendfsync everysec
 
21. 指定是否启用虚拟内存机制,默认值为no,简单的介绍一下,VM机制将数据分页存放,由Redis将访问量较少的页即冷数据swap到磁盘上,访问多的页面由磁盘自动换出到内存中(在后面的文章我会仔细分析Redis的VM机制)
   vm-enabled no
22. 虚拟内存文件路径,默认值为/tmp/redis.swap,不可多个Redis实例共享
   vm-swap-file /tmp/redis.swap
23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
   vm-max-memory 0
24. Redis swap文件分成了很多的page,一个对象可以保存在多个page上面,但一个page上不能被多个对象共享,vm-page-size是要根据存储的 数据大小来设定的,作者建议如果存储很多小对象,page大小最好设置为32或者64bytes;如果存储很大大对象,则可以使用更大的page,如果不 确定,就使用默认值
   vm-page-size 32
25. 设置swap文件中的page数量,由于页表(一种表示页面空闲或使用的bitmap)是在放在内存中的,,在磁盘上每8个pages将消耗1byte的内存。
   vm-pages 134217728
26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的,可能会造成比较长时间的延迟。默认值为4
   vm-max-threads 4
27. 设置在向客户端应答时,是否把较小的包合并为一个包发送,默认为开启
  glueoutputbuf yes
28. 指定在超过一定的数量或者最大的元素超过某一临界值时,采用一种特殊的哈希算法
  hash-max-zipmap-entries 64
  hash-max-zipmap-value 512
29. 指定是否激活重置哈希,默认为开启(后面在介绍Redis的哈希算法时具体介绍)
  activerehashing yes
30. 指定包含其它的配置文件,可以在同一主机上多个Redis实例之间使用同一份配置文件,而同时各个实例又拥有自己的特定配置文件
  include /path/to/local.conf

6.Redis的RDB持久化

rdb:

简介:
在指定的时间间隔内将内存中的数据集快照写入磁盘,
也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里

过程:
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到
一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。
整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能
如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方
式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

rdb备份策略:默认如下会生成dump快照
1分钟改一万次
5分钟改10次
15分钟改1次

优势:
大规模对完整性要求低的数据恢复

劣势:
最后一次保存可能丢失

7.Redis的AOF持久化

aof:

简介:
redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

过程:
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),
遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,
而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似

AOF备份策略:
always   同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好
everysec    异步操作,每秒记录   如果一秒内宕机,有数据丢失

优点:
数据完整性比较好

缺点:
相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同

8.Redis如何平衡两种持久化策略呢

缓存+持久化:同时开启两种持久化方式
只做缓存:如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

原因:
RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢?
作者建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),
快速重启,而且不会有AOF可能潜在的bug,留着作为一个万一的手段。

用法:
因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,
只保留save 900 1这条规则。
如果Enalbe AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己
的AOF文件就可以了。代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的
新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率,
AOF重写的基础大小默认值64M太小了,可以设到5G以上。默认超过原大小100%大小时重写可以改到
适当的数值。
如果不Enable AOF ,仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO
也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的
数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。新浪微博就选用了
这种架构

9.Redis的事务

Redis 事务

过程:
Redis 事务可以一次执行多个命令, 并且带有以下两个重要的保证:
批量操作在发送 EXEC 命令前被放入队列缓存。
收到 EXEC 命令后进入事务执行,事务中任意命令执行失败,其余的命令依然被执行。
在事务执行过程,其他客户端提交的命令请求不会插入到事务执行命令序列中。
一个事务从开始到执行会经历以下三个阶段:

关键字
开始事务。
命令入队。
执行事务。

特点
redis部分支持事务,可以批量执行,但不是原子性的,一条指令不成功,不会回滚!!

10.Redis的主从复制

行话:主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,
Master以写为主,Slave以读为主

功能:
1.读写分离
2.容灾恢复

原理:
1.slave启动成功连接到master后会发送一个sync命令
2.Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,
在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步
3.全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
4.增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步
5.但是只要是重新连接master,一次完全同步(全量复制)将被自动执行

特点:
1.无论从机什么时间点跟随大哥,大哥前面做的事情都能获得
2.主机和从机都想插入同一个key,这时候主机操作成功,从机会报错,因为read only slave
3.主机宕机了,从机无法咸鱼翻身,只会原地待命,然后主机回来了,从机继续跟随主机,忠心呀!!
4.从机宕机了,如果没有在配置文件写死跟随者,那从机就解放了!!
5.薪火相传的时候,中间的传递者虽然也有奴隶,但是总体自己还是奴隶

 

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
提供的源码资源涵盖了Java应用等多个领域,每个领域都包含了丰富的实例和项目。这些源码都是基于各自平台的最新技术和标准编写,确保了在对应环境下能够无缝运行。同时,源码中配备了详细的注释和文档,帮助用户快速理解代码结构和实现逻辑。 适用人群: 适合毕业设计、课程设计作业。这些源码资源特别适合大学生群体。无论你是计算机相关专业的学生,还是对其他领域编程感兴趣的学生,这些资源都能为你提供宝贵的学习和实践机会。通过学习和运行这些源码,你可以掌握各平台开发的基础知识,提升编程能力和项目实战经验。 使用场景及目标: 在学习阶段,你可以利用这些源码资源进行课程实践、课外项目或毕业设计。通过分析和运行源码,你将深入了解各平台开发的技术细节和最佳实践,逐步培养起自己的项目开发和问题解决能力。此外,在求职或创业过程中,具备跨平台开发能力的大学生将更具竞争力。 其他说明: 为了确保源码资源的可运行性和易用性,特别注意了以下几点:首先,每份源码都提供了详细的运行环境和依赖说明,确保用户能够轻松搭建起开发环境;其次,源码中的注释和文档都非常完善,方便用户快速上手和理解代码;最后,我会定期更新这些源码资源,以适应各平台技术的最新发展和市场需求。 所有源码均经过严格测试,可以直接运行,可以放心下载使用。有任何使用问题欢迎随时与博主沟通,第一时间进行解答!

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值