Redis（全称：Remote Dictionary Server 远程字典服务）是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。从2013年5月开始，Redis的开发由Pivotal赞助。
Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。它通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets)和有序集合(sorted sets)等类型。Redis的前世今生
在2008年北京开奥运会的时候，意大利一个叫做塞尔瓦托的技术大佬, 做了一个基于MySQL的的网站实时统计系统。
但不久，这个大佬, 对MySQL的性能感到失望,于是Redis慢慢就诞生了......Redis特点
性能极高 – Redis读的速度是11W次/s,写的速度是81K次/s
支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
丰富的数据类型，Redis不仅仅支持简单的key-value类型的数据，同时还提供Strings, Lists, Hashes, Sets 及 Ordered Sets 等数据结构的存储。
支持数据的备份，即master-slave模式的数据备份。
Redis优缺点
优点：
- 对数据高并发读写
- 对海量数据的高效率存储和访问
- 对数据具有的可扩展性和高可用性
缺点：
- redis(ACID)处理非常简单
- 无法做到太复杂的关系数据库模型
Redis典型应用场景
- 缓存系统，在项目架构中，实现缓存层功能。
- 计数器，例如微博的转发数和评论数
- 消息队列，简单的消息队列可以用Redis来实现。
- 列表/有序集合：排行榜，有序集合可以实现各种排行榜，如音乐、视频排行榜等。
- 集合：社交网络，粉丝数、关注数、最新粉丝、共同关注、时间轴等。
- 实现检查用户名是否已注册。
- 实时系统，垃圾邮件处理。
部署Redis
yum -y install gcc automake autoconf libtool make
cd /usr/local
wget
tar xzf redis-6.2.14.tar.gz
mv redis-6.2.14 redis
cd redis/
make MALLOC=libc
cd src
./redis-server
相关操作
ps -ef|grep redis
./redis-cli ping
#前台启动
./redis-server
#后台启动
#修改/usr/local/redis/redis.conf文件
#前台启动，改后台启动
daemonize yes
./src/redis-server ./redis.conf
#设置远程访问
#修改/usr/local/redis/redis.conf文件
#bind 127.0.0.1 #注释掉允许本地连接
protected-mode no #允许远程访问
#作者这里偷懒，新建了一个6379.conf,指定这个文件启动
./src/redis-server ./6379.conf
windows的安装
Redis 数据持久化
持久化
1.1、什么是持久化
持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。
1.2、持久化方式
Redis支持RDB和AOF两种持久化机制：
RDB（快照方式）： RDB方式是一种快照式的持久化方法，将某一时刻的数据持久化到磁盘中。这种方式就是将内存中数据以快照的方式写入到二进制文件中 ，默认的文件名为dump.rdb。
AOF（日志追加）： AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令执行一遍。这种方式 redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认appendonly.aof)。
RDB优缺点
优点：
RDB是一个紧凑的单一文件,方便传送，适用于灾难恢复。
与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些。
缺点：
Redis意外宕机,可能会丢失几分钟的数据（取决于配置的save时间点）。RDB方式需要保存珍整个数据集，是一个比较繁重的工作，通常需要设置5分钟或者更久做一次完整的保存。
针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。
AOF优缺点
优点：
AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
缺点：
AOF方式生成的日志文件太大，即使通过AOF重写，文件体积仍然很大。
恢复数据的速度比RDB慢。RDB持久化触发机制
save命令
在客户端中执行 save 命令，就会触发 Redis 的持久化，但同时也是使 Redis 处于阻塞状态，直到 RDB 持久化完成，才会响应其他客户端发来的命令，所以在生产环境一定要慎用。
bgsave命令
bgsave（background save）既后台保存的意思， 它和 save 命令最大的区别就是 bgsave 会 fork() 一个子进程来执行持久化，整个过程中只有在 fork() 子进程时有短暂的阻塞，当子进程被创建之后，Redis 的主进程就可以响应其他客户端的请求了，相对于整个流程都阻塞的 save 命令来说，显然 bgsave 命令更适合我们使用。
自动触发
自动触发持久化，本质是 Redis 通过判断，如果满足设置的触发条件，自动执行一次 bgsave 命令。
RDB 自动持久化主要来源于以下几种情况:
save m n
表示的是在 m 秒内，如果有 n 个键发生改变，则自动触发持久化。
如：
配置文件（/usr/local/redis/redis.conf）中的默认配置
save 900 1
save 300 10
save 60 1000
#当 900s 内如果有 1次 Redis 键值发生改变，就会触发持久化；
#当 300s 内如果有 10次 Redis 键值发生改变，就会触发持久化；
#当 60s 内如果有 10000次 Redis 键值发生改变，就会触发持久化；
#注意，这些都是或的条件，任意一个满足就会保存。flushall
清空 Redis 数据库，在生产环境下一定慎用，当 Redis 执行了 flushall 命令之后，则会触发自动持久化，把 RDB 文件清空。
RDB持久化配置
我的是新建的6379.conf
#RDB持久化自动触发条件
save 900 1
save 300 10
save 60 10000
#bgsave持久化失败，是否停止持久化数据到磁盘，yes 表示停止持久化，no 表示忽略错误继续写文件
stop-writes-on-bgsave-error yes
#rdb文件是否压缩
rdbcompression yes
#写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。
rdbchecksum yes
#rdb持久化后存放的文件名
dbfilename dump.rdb
#rdb持久化后文件的存放路径
dir ./
#注意：
#文件压缩要是开启的话：Redis 会采用 LZF 算法进行压缩。如果不想消耗 CPU 性能来进行文件压缩的话，可以设置为关闭此功能，这样的缺点#是需要更多的磁盘空间来保存文件。
配置查询/设置
config get xxx
config get dir
config get dbfilename
config get stop-writes-on-bgsave-error
config set xxx
mkdir data
config set dir "/usr/local/redis/data"
config get dir
注意：
使用命令修改的方式，马上生效，在 Redis 重启之后就会丢失。手动修改 Redis 配置文件，想要立即生效需要重启 Redis 服务器，会一直有效。禁用持久化
config set save ""RDB文件恢复
当 Redis 服务器启动时，Redis 就会自动加载 RDB 文件恢复持久化数据。
验证加载
AOF持久化
AOF方式在使用Redis存储非临时数据时，一般都需要打开AOF持久化来降低进程终止导致的数据丢失，AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程显然会降低Redis的性能，但是大部分情况下这个影响是可以接受的，另外，使用较快的硬盘能提高AOF的性能。
AOF工作流
命令写入 （append）、文件同步（sync）、文件重写（rewrite）、重启加载 （load）
AOF特点
默认文件名是 appendonly.aof。保存的位置由配置中 dir 来配置目录。
AOF 每次都会保存写命令，数据实时性更高。
AOF 需要使用“重写机制”来优化，每次记录写命令，文件会很大的问题。
AOF 根据不同的“缓冲区同步策略”将我们缓冲区中写入的命令，同步到磁盘。
缓冲区同步策略
设置appendfsync 控制，一共3种：
always：客户端的每一个写操作都保存到aof文件当，这种策略很安全，但是每个写都会有IO操作，所以也很慢。
everysec：每秒写入一次aof文件，因此，最多可能会丢失1s的数据。 推荐使用这种方式。
no: 交由操作系统来处理什么时候写入aof文件。更快，但也是最不安全的选择，不推荐使用。
开启AOF持久化
修改配置
#表示开启AOF持久化，默认是no表示关闭
appendonly yes
#AOF持久化文件名
appendfilename "appendonly.aof"
#缓冲同步策略，默认值
appendfsync everysec
#是否重写，默认不重写
no-appendfsync-on-rewrite no 测试
set x 123
set y 456
set z 789
AOF重写
##### 为什么要重写
随着aof文件越来越大，需要定期对aof文件进行重写，达到压缩的目的。
##### 重写aof改变
进程内已经超时的数据不再写入文件。
旧的aof有无效命令（如：set k1 hello ex 10000），新的aof文件只保留最终数据的写入命令。
多条写命令可以合并为一个（如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c）。但也不能将整个lpush生成的元素全部写在一起，所以对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。来防止客户端缓冲区溢出。
AOF重写降低了文件占用空间，更小的aof 文件启动redis时，加载更快。
##### 重写方式
AOF重写过程可以手动触发和自动触发：
**手动触发：**直接调用bgrewriteaof命令。
**自动触发：**根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机手动
自动
#AOF文件增长率(当前AOF文件大小超过上一次重写的AOF文件大小的百分之多少才会重写)
auto-aof-rewrite-percentage 100
#表示运行AOF重写时文件最小体积，默认为64MB。
auto-aof-rewrite-min-size 64mb aof文件恢复
在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。
备份现在aof文件，以防万一。
使用redis-check-aof命令修复aof文件，该命令格式如下：
# 修复aof日志文件
redis-check-aof -fix file.aof
