一、redis是什么

redis是一种支持Key-Value等多种数据结构的存储系统。可用于缓存，事件发布或订阅，高速队列等场景。该数据库使用ANSI C语言编写，支持网络，提供字符串，哈希，列表，队列，集合结构直接存取，基于内存，可持久化。

redis是一个非关系型的数据库(not-only-sql即nosql),以键值对的方式存储数据,将数据存放在内存中,存取速度快,但是对持久化的支持不够好,所以redis一般配合关系型数据库使用，redis可以做分布式缓存,用在数据量大,高并发的情况下.redis通过很多命令进行操作,而且redis不适合保存内容大的数据.

二、redis的应用场景有哪些

会话缓存（最常用）；
消息队列；
活动排行榜或计数；
发布，订阅消息（消息通知）；
商品列表，评论列表等

三、redis数据类型

Redis一共支持五种数据类：string（字符串），hash（哈希），list（列表），set（集合）和zset（sorted set有序集合）。

字符串（字符串）

它是redis的最基本的数据类型，一个键对应一个值，需要注意是一个键值最大存储512MB
使用场景：常规key-value缓存应用，一般用于常规计数: 微博数, 粉丝数

hash（哈希）

hash是一个键值对的集合，是一个string类型的field和value的映射表，适合用于存储对象

是redis的简单的字符串列表，它按插入顺序排序
使用场景：可以轻松地实现最新消息排行等功能，另一个应用就是消息队列

4.集合

是字符串类型的无序集合，也不可重复
利用Redis提供的Set数据结构，可以存储一些集合性的数据。在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中

sorted set有序集合

和Set相比，Sorted Set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列并且是插入有序的，即自动排序。
使用场景：集合value可以是同学的学号，而score就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序，或者用Sorted Set来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务，这样就做到了让重要的任务优先执行的效果

四、redis的服务相关的命令

slect＃选择数据库（数据库编号0-15）
退出＃退出连接
信息＃获得服务的信息与统计
monitor＃实时监控
config get＃获得服务配置
flushdb＃删除当前选择的数据库中的key
flushall＃删除所有数据库中的键

五、redis的发布与订阅

redis的发布与订阅（发布/订阅）是它的一种消息通信模式，一方发送信息，一方接收信息。
下图是三个客户端同时订阅同一个频道

六、redis的发布与订阅

redis的发布与订阅（发布/订阅）是它的一种消息通信模式，一方发送信息，一方接收信息。
下图是三个客户端同时订阅同一个频道

七、redis的持久化

redis持久有两种方式：快照（快照）、仅附加文件（AOF）

快照（RDB）

快照形式，定期把内存中当前时刻的数据保存到磁盘。Redis默认支持的持久化方案。速度快但是服务器断电的时候会丢失部分数据

将存储在内存的数据以快照的方式写入二进制文件中，如默认dump.rdb中
900秒内如果超过1个Key被修改，则启动快照保存
300秒内如果超过10个Key被修改，则启动快照保存
60秒内如果超过10000个重点被修改，则启动快照保存

仅附加文件（AOF）

append only
file。把所有对redis数据库操作的命令，增删改操作的命令。保存到文件中。数据库恢复时把所有的命令执行一遍即可。两种持久化方案同时开启使用AOF文件来恢复数据库.能保证数据的完整性,但是速度慢

使用AOF持久时，服务会将每个收到的写命令通过写函数追加到文件中（appendonly.aof）
AOF持久化存储方式参数说明

appendonly yes ＃开启AOF持久化存储方式 
appendfsync always ＃收到写命令后就立即写入磁盘，效率最差，效果最好
appendfsync everysec  ＃每秒写入磁盘一次，效率与效果居中
appendfsync no ＃完全依赖操作系统，效率最佳，效果没法保证

redis的单线程为什么那么快

redis分客户端和服务端，一次完整的redis请求事件有多个阶段（客户端到服务器的网络连接–>redis读写事件发生–>redis服务端的数据处理（单线程）–>数据返回）。平时所说的redis单线程模型，本质上指的是服务端的数据处理客户端和服务器是socket通信方式，socket服务端监听可同时接受多个客户端请求也就是说，redis服务同时面对多个redis客户端连接请求，而redis服务本身是单线程运行。

redis 核心就是如果我的数据全都在内存里，我单线程的去操作就是效率最高的，为什么呢，因为多线程的本质就是 CPU 模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。redis 用单个CPU 绑定一块内存的数据，然后针对这块内存的数据进行多次读写的时候，都是在一个CPU上完成的，所以它是单线程处理这个事。在内存的情况下，这个方案就是最佳方案使用单线程的方式是无法发挥多核CPU 性能, 为了充分利用多核CPU，常常在一台server上会启动多个实例(即多个redis进程)。而为了减少切换的开销，有必要为每个实例(redis进程)指定其所运行的CPU而且因为redis是单线程的,所以不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。

总结:CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了

解决redis主从结构宕机
如果在主从复制架构中出现宕机的情况，需要分情况看：

从Redis宕机

a)这个相对而言比较简单，在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据；

b) 问题？如果从库在断开期间，主库的变化不大，从库再次启动后，主库依然会将所有的数据做RDB操作吗？还是增量更新？（从库有做持久化的前提下）

不会的，因为在Redis2.8版本后就实现了，主从断线后恢复的情况下实现增量复制。

主Redis宕机

方法一：手动恢复

在从数据库中执行SLAVEOFNO ONE命令，断开主从关系并且将从库提升为主库继续服务
将主库重新启动后，执行SLAVEOF命令，将其设置为其他库的从库，这时数据就能更新回来

方法二：哨兵功能自动恢复
基本原理是：心跳机制+投票裁决

通过sentinel模式启动redis后，自动监控master/slave的运行状态, 已经被集成在redis2.4+的版本中
如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave

Redis 知识点总结