redis介绍（一）

#  redis数据格式

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

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

（1）字符串（字符串）

它是redis的最基本的数据类型，一个键对应一个值，需要注意是一个键值最大存储512MB。

（2）hash（哈希）

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

（3）表（列表）

是redis的的的的的简单的字符串列表，它按插入顺序排序

（4）组（集合）

是字符串类型的无序集合，也不可重复

（5）zset（sorted set有序集合）

是string类型的有序集合，也不可重复

有序集合中的每个元素都需要指定一个分数，根据分数对元素进行升序排序，如果多个元素有相同的分数，则以字典序进行升序排序，sorted set因此非常适合实现排名

# redis的应用场景有哪些

1，会话缓存（最常用）

2，消息队列，

比如支付3，活动排行榜或计数

4，发布，订阅消息（消息通知）

5，商品列表，评论列表等

# redis操作

1.批量操作batch

ConnectionMultiplexer redis = ConnectionMultiplexer.Connect("192.168.23.151:6379"); var db = redis.GetDatabase();\\

  db.SetAdd(customerID, orderTotalPrice);

管道操作pipleline

Pipeline pipe=redis.pipelined();

pipe.get(key)

pipe.sync();

# REDS 架构

Redis单线程架构

1 单线程模型

Redis客户端对服务端的每次调用都经历了发送命令，执行命令，返回结果三个过程。其中执行命令阶段，由于Redis是单线程来处理命令的，所有每一条到达服务端的命令不会立刻执行，所有的命令都会进入一个队列中，然后逐个被执行。并且多个客户端发送的命令的执行顺序是不确定的。但是可以确定的是不会有两条命令被同时执行，不会产生并发问题，这就是Redis的单线程基本模型。

2 单线程模型每秒万级别处理能力的原因

（1）纯内存访问。数据存放在内存中，内存的响应时间大约是100纳秒，这是Redis每秒万亿级别访问的重要基础。

（2）非阻塞I/O，Redis采用epoll做为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接，读写，关闭都转换为了时间，不在I/O上浪费过多的时间。

（3）单线程避免了线程切换和竞态产生的消耗。

（4）Redis采用单线程模型，每条命令执行如果占用大量时间，会造成其他线程阻塞，对于Redis这种高性能服务是致命的，所以Redis是面向高速执行的数据库。

性能高：支持读 11万/秒  ，  写 8万/秒

存储： 内存 ;  RDB文件(二进制安全的真实数据) ;  AOF文件（客户端的命令集合）

事务： 支持事务（每个客户端串行执行命令，其他客户端处于阻塞状态）

# 和其他内存数据库的对比

我们都知道, Memcached内部是多线程的，而Redis是单线程的。多线程好理解，但Redis为什么要搞成单线程呢？ 

个人认为，有以下几个原因： 

（1）redis有各种复杂的数据结构list, has, set。也就是说，对于一个(key, value)，value的类型可以是list, hash, set。在实际应用场景中，很容易出现多个客户端对同一个key的这个复杂的value数据结构进行并发操作，如果是多线程，势必要引入锁，而锁却是性能杀手。 

相比较而言，memcached只有简单的get/set/add操作，没有复杂数据结构，在互斥这个问题上，没有redis那么严重。

（2）对于纯内存操作来说，cpu并不是瓶颈，瓶颈在网络IO上。所以即使单线程，也很快。另外，如果要利用多核的优势，可以在一个机器上开多个redis实例。

# Redis一致性保证

Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作：第一个原因是因为集群是用了异步复制. 写操作过程:

客户端向主节点B写入一条命令.

主节点B向客户端回复命令状态.

主节点将写操作复制给他得从节点 B1, B2 和 B3

主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。 注意：Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区， 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。

举个例子 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点， 其中 A 、B 、C 为主节点， A1 、B1 、C1 为A，B，C的从节点， 还有一个客户端 Z1 假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ，小部分的一方则包含节点 B 和客户端 Z1 .

Z1仍然能够向主节点B中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master，那么Z1写入B中得数据便丢失了.

注意， 在网络分裂出现期间， 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选项

# redis的的的的的服务相关的命令

slect＃选择数据库（数据库编号0-15）

退出＃退出连接

信息＃获得服务的信息与统计

monitor＃实时监控

config get＃获得服务配置

flushdb＃删除当前选择的数据库中的key

flushall＃删除所有数据库中的键

# redis的发布与订阅

redis的发布与订阅（发布/订阅）是它的一种消息通信模式，一方发送信息，一方接收信息。

下图是三个客户端同时订阅同一个频道

下图是有新信息发送给频道1时，就会将消息发送给订阅它的三个客户端

# redis的持久化

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

快照（快照）

1，将存储在内存的数据以快照的方式写入二进制文件中，如默认dump.rdb中

2，保存900 1

＃900秒内如果超过1个Key被修改，则启动快照保存

3，保存300 10

＃300秒内如果超过10个Key被修改，则启动快照保存

4，保存60 10000

＃60秒内如果超过10000个重点被修改，则启动快照保存

仅附加文件（AOF）

1，使用AOF持久时，服务会将每个收到的写命令通过写函数追加到文件中（appendonly.aof）

2，AOF持久化存储方式参数说明

appendonly yes

＃开启AOF持久化存储方式

appendfsync always

＃收到写命令后就立即写入磁盘，效率最差，效果最好

appendfsync everysec

＃每秒写入磁盘一次，效率与效果居中

appendfsync no

         ＃完全依赖操作系统，效率最佳，效果没法保证

## RDB优缺点

触发RDB快照

1 在指定的时间间隔内，执行指定次数的写操作

2 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令

3 执行flushall 命令，清空数据库所有数据，意义不大。

4 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义...也不大。

通过RDB文件恢复数据

将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。可以从下面的操作演示中可以体会到。

## RDB 的优缺点

优点：

1 适合大规模的数据恢复。

2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

缺点：

1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。

2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。

所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

## RDB 和AOF比较

Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。

RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。

Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。

AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。

Redis 针对 AOF文件大的问题，提供重写的瘦身机制。

若只打算用Redis 做缓存，可以关闭持久化。

若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。

一、RDB

1、RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。RDB是Redis默认的持久化方式，会在对应的目录下生产一个dump.rdb文件，重启会通过加载dump.rdb文件恢复数据。

2、优点

1）只有一个文件dump.rdb，方便持久化；

2） 容灾性好，一个文件可以保存到安全的磁盘；

3） 性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化（使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能) ；

4）如果数据集偏大，RDB的启动效率会比AOF更高。

3、缺点

1）数据安全性低。（RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不是特别严格的时候）

2）由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

二、AOF

1、AOF持久化是以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，文件中可以看到详细的操作记录。她的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2、优点

1）数据安全性更高，AOF持久化可以配置appendfsync属性，其中always，每进行一次命令操作就记录到AOF文件中一次。

2）通过append模式写文件，即使中途服务器宕机，可以通过redis-check-aof工具解决数据一致性问题。

3）AOF机制的rewrite模式。(AOF文件没被rewrite之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的flushall）)

3、缺点

1）AOF文件比RDB文件大，且恢复速度慢；数据集大的时候，比rdb启动效率低。

2）根据同步策略的不同，AOF在运行效率上往往会慢于RDB。

8，redis的的的的性能测试

自带相关测试工具

实际测试同时执行100万的请求

1 单线程模型

Redis客户端对服务端的每次调用都经历了发送命令，执行命令，返回结果三个过程。其中执行命令阶段，由于Redis是单线程来处理命令的，所有每一条到达服务端的命令不会立刻执行，所有的命令都会进入一个队列中，然后逐个被执行。并且多个客户端发送的命令的执行顺序是不确定的。但是可以确定的是不会有两条命令被同时执行，不会产生并发问题，这就是Redis的单线程基本模型。

2 单线程模型每秒万级别处理能力的原因

（1）纯内存访问。数据存放在内存中，内存的响应时间大约是100纳秒，这是Redis每秒万亿级别访问的重要基础。

（2）非阻塞I/O，Redis采用epoll做为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接，读写，关闭都转换为了时间，不在I/O上浪费过多的时间。

（3）单线程避免了线程切换和竞态产生的消耗。

（4）Redis采用单线程模型，每条命令执行如果占用大量时间，会造成其他线程阻塞，对于Redis这种高性能服务是致命的，所以Redis是面向高速执行的数据库。

# redis内存设置

最大内存设置一般是70%，需要保留部分用做内存复制和内存清理。

常见的内存清理有valotile-lfu/lru/random/ttl, allkeys-lfu/lru/random/ttl;

# redis锁

一般使用ttl 和nx来设置锁，也就是在；key不存在或TTL到期的时候可以获取锁，否则就异步订阅key的ttl状态信息，与当前线程绑定，并且设置一个UUID和枷锁的次数来反馈当前枷锁的情况。也就是锁枷锁的key的为当前枷锁对象，值是由UUID和枷锁次数组成。

# redis api

Jredission

一个常用的redis java api

# Redis高可用

主从模式和集群模式

主从模式中包含哨兵，由哨兵来负责主状态监控，主节点状态通知。 

# 参考文件

http://doc.redisfans.com/

http://doc.redisfans.com/topic/persistence.html

https://www.jianshu.com/p/7d5fbf90bcd7

https://www.cnblogs.com/cjsblog/p/9048545.html