如有问题,欢迎大家留言指正
1、redis启动三种方式?
- redis.conf配置文件
- 启动的时候在启动命令后加入
- 客户端命令,在启动完成后
2、redis支持哪几种常见数据类型?
- String字符串:(统计点赞)
- Hash(哈希)
- List(列表)(点赞列表)
- Set(集合)
- zset(sorted set:有序集合)(排行榜)
2、redis哈希槽的概念:
redis集群没有一致性hash,而是引入hash槽的概念,redis集群有16384个哈希槽,每个key通过CRC16效验后对16384取模来决定防止那个槽,集群的内个节点负责一部分槽。
3、redis事务的理解?
- redis事务的概念:redis 事务的本质是一组命令的集合。事务支持一次执行多个命令,一个事务中所有命令都会被序列化。在事务
执行过程,会按照顺序串行化执行队列中的命令,其他客户端提交的命令请求不会插入到事务执行命令序列中。 总结说:redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。 - redis事务没有隔离级别的概念:redis没有事务隔离界别
- redis不保证原子性:redis中,单条命令是原子性执行的,但事务不保证原子性,且没有回滚。事务中任意命令执行失败,其余的命令仍会被执行。
- redis事务的三个阶段:
4.1 开始事务 4.2 命令入队 4.3 执行事务 - redis事务相关命令:
5.1 watch key1 key2 … : 监视一或多个key,如果在事务执行之前,被监视的key被其他命令改动,则事务被打断 (类似乐观锁 ) 5.2 multi : 标记一个事务块的开始( queued ) 5.3 exec : 执行所有事务块的命令 ( 一旦执行exec后,之前加的监控锁都会被取消掉 ) 5.4 discard : 取消事务,放弃事务块中的所有命令 5.5 unwatch : 取消watch对所有key的监控 - redis事务使用案例:
(1)正常执行 (2)放弃事务 (3)若在事务队列中存在命令性错误,则执行EXEC命令时,所有命令都不会执行 (4)若在事务队列中存在语法性错误,则执行EXEC命令时,其他正确命令会被执行,错误命令抛出异常。 (5)使用watch - 案例:
7.1 案例一:使用watch检测balance,事务期间balance数据未变动,事务执行成功 7.2 案例二:使用watch检测balance,在开启事务后(标注1处),在新窗口执行标注2中的操作,更改balance的值,模拟其他客户端在事务执行期间更改watch监控的数据,然后再执行标注1后命令,执行EXEC后,事务未成功执行。一但执行 EXEC 开启事务的执行后,无论事务使用执行成功,WARCH 对变量的监控都将被取消。故当事务执行失败后,需重新执行WATCH命令对变量进行监控,并开启新的事务进行操作。 - 总结:
watch指令类似于乐观锁,在事务提交时,如果watch监控的多个KEY中任何KEY的值已经被其他客户端更改,则使用EXEC执行事务时,事务队列将不会被执行,同时返回Nullmulti-bulk应答以通知调用者事务执行失败。
4、Redis事务保证原子性吗,支持回滚吗?
Redis中,单条命令是原子性执行的,但事务不保证原子性,且没有回滚。事务中任意命令执行失败,其余的命令可以仍会被执行。
5、Redis事务支持隔离性吗?
解释1:Redis 是单进程程序,并且它保证在执行事务时,不会对事务进行中断,事务可以运行直到执行完所有事务队列中的命令为止。因此,Redis 的事务是总是带有隔离性的。 解释2:事务是单独的隔离操作,事务中的所有命令都会序列化、按顺序执行,事务在执行时,不会被其他客户端的请求打断,事务的原子性,事务要么全部执行,要不全部不执行。
6、Redis的线程模型是什么样的?
- Redis基于Reactor模式开发了网络事件处理器,这个处理器被称为文件事件处理器(file event handler)。它的组成结构为4部分:多个套接字、IO多路复用程序、文件事件分派器、事件处理器。
- 因为文件事件分派器队列的消费是单线程的,所以Redis才叫单线程模型。
文件事件处理器使用 I/O 多路复用(multiplexing)程序来同时监听多个套接字, 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。 - 当被监听的套接字准备好执行连接应答(accept)、读取(read)、写入(write)、关闭(close)等操作时, 与操作相对应的文件事件就会产生, 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。
- 虽然文件事件处理器以单线程方式运行, 但通过使用 I/O 多路复用程序来监听多个套接字, 文件事件处理器既实现了高性能的网络通信模型, 又可以很好地与 redis 服务器中其他同样以单线程方式运行的模块进行对接, 这保持了Redis 内部单线程设计的简单性。
如果不太理解:点击下边链接
7、Redis的重要数据怎么保护?
设置密码
8、Redis持久化?
- 持久化流程:
1.1.客户端向服务器发送写操作(数据在客户端内存中) 1.2.数据库服务接收到服务器的写操作(数据在服务器内存中) 1.3.服务器调用write这个调用将数据网磁盘离去写(数据在系统内存的缓存区) 1.4.操作系统将缓存区的数据转移到磁盘控制器上(数据在磁盘缓存里) 1.5.磁盘控制器将数据写到磁盘的物理介质中(数据真正的写到磁盘上) - redis内存划分:
4.1 数据:作为数据库,数据是最主要的部分,这部分占用的内存会统计在used_memory。 4.2 进程本身运行需要的内存:代码和常量池,这部分大约有几兆,可以忽略不计,这部分不是由jemalloc分配,所以不会统计在used_memory中,AOF和RDB创建的子进程不属于redis进程,不统计在used_memory和used_memory_rss中。 4.3 缓存内存:包括客户端缓冲区、复制积压缓冲区、AOF缓冲区,有jemalloc分配,统计在used_memory中。 4.4 内存碎片:是redis内存分配,回收物理内存过程产生的,频繁改变数据可能导致物理内存没有释放,这部分内存不统计在used_memory中。 - RDB持久化:
2.1 介绍:是把当前内存的数据集快照以二进制写入磁盘,也就是snapshot快照,默认dump.rdb,用这个文件代替上次的文件达到数据持久化的目的 2.2 三种机制:1.save:会阻塞reids,执行save期间redis不执行其他操作,只有当RDB过程执行完成为止 ,执行完成后把旧的文件替换掉。2.bgsave:执行命令时,redis会在后台进行异步快照操作,快照同时还可以响应客户端请求(步骤:redis执行fork创建子程序,redis持久化过程有子过程完成,阻塞只发生在fork阶段)。3.自动化:在redis.conf中配置 2.3 优点:1.文件紧凑,全量备份,非常适合备份和灾难恢复。2.生成RDB文件的时候,主进程会fork一个子进程来处理所有的保存工作,主进程不需要进行任何的磁盘IO操作。3.RDB恢复大数据比AOF快 2.4 缺点:RDB快照是一个全量备份,存储的是内存二进制序列化形式,存储上非常紧凑,当快照持久化时,会开启一个子进程专门来负责快照持久化,子进程会拥有父进程的数据,当父进程被修改内存子进程反应不过来时,快照持久化期间被修改的数据不会被保存,可能丢失数据。 - AOF持久化:
3.1 介绍:redis收到一个命令都通过write函数追加到文件aof中,俗称日志记录. 3.2 三种机制:1.每修改同步always:每次持久化都会立即同步到磁盘,性能较差,但数据保存完好,2.每秒同步everysec:异步操作,如果一秒内有宕机,有数据会丢失。3.no:从不同步 3.3 优点:1.可以更好的保护数据的不丢失,一般AOF会每隔一秒通过后台线程执行一次fsync操作,最多丢失一秒数据。2.AOF没有任何磁盘寻址的开销,写入性能非常高,文件不容易破碎。3.AOF即使过大的时候,出现重写操作,也不会影响客户端的读写4.AOF日志文件的命令,通过非常可读的方式进行记录,这个特性非常适合做灾难误删除的紧急恢复。比如不小心flushall命令清楚了所有数据,只要后台rewrite还没发生,那么久拷贝AOF文件,将最后一条flushall命令给删除,然后再将该AOF文件放回去,就可以通过恢复机制,自动恢复所有数据。 3.4 缺点:1.对于同一个文件来说AOF通常不RDB数据快照文件大。 3.5 重写原理:AOF持久化带来的问题是文件越来越大,为了压缩AOF文件,redis提供了bgrewriteaof命令,将内存中的数据已命令的形式保存临时文件中,同时会fork一个子进程来重写文件。重写aof文件,并没有读取就得aof文件,而是将整个内存中的数据库内容用命令的形式重新aof文件。
9.redis主从复制?
- redis支持主从模式,master会同步数据到slave,而slave不会同步master,slave启动时会连接master,同步数据,这是一个典型的读写分离没事,利用master来插入数据,slave提供检索服务,这样可以有效减少单个计算机的并发数量。
- 复制是redis高可用的基础,哨兵和集群都是在复制的基础上实现的高可用,复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单的故障恢复,缺陷在于:恢复故障无法自动化,写操作无法负载均衡,存储能力受到单机限制
- 哨兵:
3.1 背景:Redis服务器毫无征兆的罢工是个麻烦事,如何保证备份的机器是原始服务器的完整备份呢? 3.2 应用:这时候就需要哨兵和复制。Sentinel可以管理多个Redis服务器,它提供了监控,提醒以及自动的故障转移的功能,Replication则是负责让一个Redis服务器可以配备多个备份的服务器。 在复制的基础上,哨兵实现了自动化的故障恢复.
10. redis读写分离模式?
- 通过增加slave db数量,读的性能会成线性增加,为了避免Masterdb的单点故障,集群一般采用两台Master db做双机热备,是整个集群的读写性都非常高。
- 缺点:主机从机都要不存完整的数据,如果在数据量很大的情况下,集群的扩展还是受制于单个节点的存储能力,对于write-intersive类型的应用,读写分离并不适用。
11.redis集群?
Redis Sentinal着眼于高可用,在Master宕机时会自动将Slave提升为Master,继续提供服务。Redis Cluster着眼于扩展,在单个redis不够时,使用Cluster进行分片存储。
12.redis分片模型?
为了解决读写分离的缺陷,可以将数据分片模型应用进来可以将每个节点看成独立的master,然后通过业务进行分片,可以设计成一个master和多个slave的模式。
|