redis总结

redis总结

1. NoSQL： KV+Cache+Persistence(持久化)

2. 3V + 3高

大数据时代的3V： 海量Volume、多样Variety、实时Velocity
互联网需求的3高：高并发、高可括、高性能

3.分布式系统中的CAP原理

传统的ACID：原子性、一致性、隔离性、持久性

CAP：
	强一致性(Consistency)：
	可用性(Availability)：
	分区容错性(Partition tolerance)：
	
    由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。
所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

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

4.redis(remote dictionary server)是什么？

> 一个高性能的(key/value)分布式内存数据库，基于内存运行 并支持持久化的NoSQL数据库.
> 默认端口：6379.
> 索引从0开始.
> Redis 是单进程单线程的，redis 利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销。
> Redis集群最大节点个数是多少：16384个。
> 怎么测试Redis的连通性；ping
> Redis回收使用的算法:LRU算法

5.redis作用和适用场景？

> 内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务
> 取最新N个数据的操作(热点数据)，如：可以将最新的10条评论的ID放在Redis的List集合里面
> 模拟类似于HttpSession这种需要设定过期时间的功能
> 发布、订阅消息系统
> 定时器、计数器

6.redis优缺点

优点：
		> 读写性能优异，Redis能读的速度是110000次/秒，写的速度是81000次/秒。
		> 支持数据持久化，支持AOF和RDB两种持久化方式
		> 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
		> 数据结构丰富，除了支持String类型的value外还支持hash，set,zset,list等数据结构
		> 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离

缺点：
	> 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
	> Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或手动切换前端IP才能恢复
	> 数据不一致问题：主机宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低系统的可用性。

6+1、Redis 相比 Memcached 有哪些优势？

（1）Memcached 所有的值均是简单的字符串，redis 作为其替代者，支持更为丰富的数据类
（2）Redis 的速度比 Memcached 快很
（3）Redis 可以持久化其数据

6+2、Memcache 与 Redis 的区别都有哪些？

（1）存储方式 Memecache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。Redis 有部份存在硬盘上，这样能保证数据的持久性。
（2）数据支持类型 Memcache 对数据类型支持相对简单。 Redis 有复杂的数据类型。

7.redis为什么快？

> 完全基于内存，绝大部分请求是纯碎的内存操作
> 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
> 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗CPU
> 使用多路I/O复用模型，非阻塞I/O

8.redis中的五种数据类型

> string
	string是redis最基本的类型，一个key对应一个value。
	string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。
	string类型是Redis最基本的数据类型，一个redis中字符串value最多可以是512M
> hash
	Redis hash 是一个键值对集合。
	Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
> list
	Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素导列表的头部（左边）或者尾部（右边）。
	它的底层实际是个链表
> set
	Redis的Set是string类型的无序集合。它是通过HashTable实现实现的
> Zset
	Redis zset 和 set 一样也是string类型元素的集合，且不允许重复的成员。
	不同的是每个元素都会关联一个double类型的分数。
	redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的，但分数(score)却可以重复。

9.配置文件相关

9+1:Redis的过期键的删除策略

定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好，但是会占用大量CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

惰性过期：当访问一个key时，会判断key是否过期，过期则清理。策略可以最大化的节省CPU资源，却对内存非常不友好，极端情况下可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存

定期过期：每隔一定的时间，会扫描一定数量的数据库expires字典中一定数量的key，并清除其中已过期的key。策略是前两者中的一个折衷方案，通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果

9+2:Redis的三个同步条件(结合RDB)

	save 900 1   ：900 秒（15 分钟）内有 1 个更改
	save 300 10  ：300 秒（5 分钟）内有 10 个更改
	save 60 10000：60 秒内有 10000 个更改

10.redis的持久化: 持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

Redis提供两种持久化机制RDB（默认）和AOF机制:

RDB：RDB是Redis默认的持久化方式，按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb，
	通过配置文件中的sava参数来定义快照的周期。

	过程：Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个
		  临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
	优点
		> 只有一个文件dump.rdb，方便持久化。
		> 容灾性好，一个文件可以保存到安全的磁盘。
		> 性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是I/O最大化，使用单独子进程来进行持久化，主进程
		   不会进行任何I/O操作，保证了redis的高性能
		> 相对于数据集大，比AOF的启动效率更高
	缺点
		数据安全性低。RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失，所以这种方式更适合数据
		要求不严谨的时候.

AOF:是指所有的命令行记录以redis命令请求协议的格式完全持久化（存储）保存为aof文件。

	过程：以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动
		 之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
	
	优点：
		> 每修改同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘性能较差但数据完整性比较好
		> 每秒同步：appendfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
		> 不同步：appendfsync no 从不同步
	缺点：
		> 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
		> Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

redis的持久化方式AOF和RDB总结？
	AOF文件比RDB更新频率高，优先使用AOF还原数据
	AOF比RDB更安全也更大
	RDB性能比AOF好
	如果两个都配了优先加载AOF。

10+1、rewrite

是什么：
	AOF采用文件追加方式，文件会越来越大。为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就
	会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof
重写原理
	AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有
	一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件， 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件。
触发机制
	Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

11.内存相关

11+1：MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据？
	redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。
	
11+2：Redis的内存淘汰策略有哪些？
	noeviction: 新写入操作会报错。
	allkeys-lru：在键空间(全部数据)中，移除最近最少使用的 key（这个是最常用的）。
	allkeys-random：在键空间(全部数据)中，随机移除某个 key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的 key 给干掉啊。
	volatile-lru：在设置了过期时间的键空间中，移除最近最少使用的 key（这个一般不太合适）。
	volatile-random：在设置了过期时间的键空间中，随机移除某个 key。
	volatile-ttl：在设置了过期时间的键空间中，有更早过期时间的 key 优先移除。

	说明：volatile 和 allkeys 规定了是对已设置过期时间的数据集淘汰数据还是从全部数据集淘汰数据，lru、ttl 以及 random 
		 是三种不同的淘汰策略，no-enviction 永不回收的策略。
11+3：Redis主要消耗什么物理资源？ 内存

11+4：Redis 如何做内存优化？
	尽可能使用散列表，散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。
	比如你的 web 系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的 key,而是应该把这个用户的所有信息存储到一张散列表里面。
11+5：Redis 的内存用完了会发生什么？
	如果达到设置的上限，Redis 的写命令会返回错误信息(但是读命令还可以正常返回)或者可以将Redis当缓存来使用配置淘汰机制，
	当Redis达到内存上限时会冲刷掉旧的内容。

12.缓存异常

12+1.缓存穿透
	说明：缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，如果从存储层查不到数据则不写入缓存，这将导致这个不
		 存在的数据每次请求都要到存储层去查询。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
	解决方案：
		> 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
		> 从缓存取不到的数据，在数据库中也没有取到，这时可以将key-value对写为key-null，缓存有效时间可以设置短点。这样就可以防止攻击用户反复用同一id暴力攻击
		> 采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力

12+2.缓存击穿
	说明:对于设置了过期时间的 key，缓存在某个时间点过期的时候，恰好这时间点对这个 Key 有大量的并发请求过来，
		 这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。
	解决方案：
		> 设置热点数据永不过期
		> 加互斥锁
12+3.缓存雪崩
	说明:设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到 DB，DB 瞬时压力过重雪崩。
		 与缓存击穿的区别：雪崩是很多key，击穿是某一个key缓存。
	解决方案：
		> 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生
		> 一般并发量不是特别多的使用，使用最多的解决方案是加锁排队
		> 给每一个缓存数据增加相应的缓存表记，记录缓存是否失效，如果缓存表记失效，则更新缓存

13.事务

13+1.什么是事务？（ACID）
	事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
	事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

13+2.Redis事务的概念
		Redis事务的本质是通过MULTI，EXEC,WATCH等一组命令的集合。事务支持一次执行多个命令。一个事务中所有命令都会被序列化。
	在事务执行过程中，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。
	
	总结说：redis事务就是一次性，顺序性，排他性的执行一个队列中的一系列命令

13+3.Redis事务的三个阶段
	事务开始MULTI
	命令入队
	事务执行EXEC
	
13+4.常用命令
	DISCARD	取消事务，放弃执行事务块内的所有命令。
	EXEC	执行所有事务块内的命令。
	MULTI	标记一个事务块的开始。
	UNWATCH	取消 WATCH 命令对所有 key 的监视。
	WATCH key [key …]	监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
13+5.其他
	Redis事务支持隔离性吗？
			Redis是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。
		因此，Redis的总是带有隔离性的。
	Redis事务保证原子性吗，支持回滚吗？
		Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。
		redis不支持回滚，redis在事务失败时不进行回滚，而是继续执行余下命令，所以Redis的内部可以保持简单且快速。

14.集群

14+1.主从复制
		当从数据库启动时，会向主数据库发送sync命令，主数据库接收到sync后开始在后台保存快照rdb，在保存快照期间收到的命令缓存
	起来，当快照完成时，主数据库会将快照和缓存的命令一块发送给从机(异步处理、全量复制)。<复制初始化结束>。
	    之后主机每收到1个命令就同步发送给从机(增量复制)。当出现断开重连后，2.8之后的版本会将断线期间的命令传给从数据库。
	
	14+1+1.读写分离
		主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。
		
	14+1+2.常用方法
		一主二仆：一个Master两个Slave 
		薪火相传：上一个Slave可以是下一个slave的Master，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力。
				命令：slaveof 新主库IP 新主库端口
		反客为主：使当前数据库停止与其他数据库的同步，转成主数据库。命令：SLAVEOF no one
	             info replication：查看日志命令
14+2.哨兵模式(sentinel)：反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
	14+2+1.哨兵设置与启动
		> 新建sentinel.conf文件，名字绝不能错
		> 配置哨兵,填写内容
			sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1(主机IP) 6379(端口) 1
			最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机
		> 启动哨兵
			redis-sentinel /sentinel.conf

	14+2+2.哨兵的核心知识
		1、哨兵至少需要 3 个实例，来保证自己的健壮性。
		2、哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
		3、对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。
		4、配置哨兵监控一个系统时，只需要配置其监控主数据库即可，哨兵会自动发现所有复制该主数据库的从数据库。

15.分区

15+1.为什么要做Redis分区？
		分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区
	使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。
	
15+2.Redis是单线程的，如何提高多核CPU的利用率？
	可以在同一个服务器部署多个Redis实例，并把它们当作不同的服务器来使用。
	
15+3.Redis分区实现方案？
	客户端分区:在客户端就已经决定数据会被存储到哪个Redis节点或者从哪个redis节点读取.大多数客户端已经实现了客户端分区。
	代理分区:客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据。代理根据分区规则决定请求哪些Redsi实例，
			 然后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy。
	查询路由:客户端随机的请求任意一个redis实例，然后由redis将请求转发给正确的redis节点。
	
15+4.分区的缺点
	> 涉及多个key的操作通常不会被支持，例如你不能对两个集合求交集，因为它们可能被存储到不同的redis实例（实际上这种情况也有办法，但是不能直接使用交集指令）
	> 同时操作多个key,则不能使用Redis事务
	> 分区使用的粒度是key，不能使用一个非常长的排序key存储一个数据集
	> 当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的redis实例和主机同时收集RDB/AOF文件
	> 分区时动态扩容或缩容可能非常复杂，Redis集群在运行时增加或者删除Redsi节点，能做到最大程度对用户透明的数据再平衡，但其他一些客户端分区或代理分区方法则不支持这种特性

16.Redis如何做大量数据插入？

Redis2.6开始redis-cli支持一种新的被称之为pipe mode的新模式用于执行大量数据插入工作。