Redis 进阶

Redis 发布、订阅

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息并且
可以订阅任意数量的频道。
发布订阅（Pub/Sub）：目前广泛使用的通信模型，它采用事件作为基本的通信机制，提供大规模
系统所要求的松散耦合的交互模式：订阅者(如客户端)以事件订阅的方式表达出它有兴趣接收的一个事
件或一类事件；发布者(如服务器)可将订阅者感兴趣的事件随时通知相关订阅者------是不是与设计模式
里面的观察者模式一个妈妈生的？
最经典的应用场景就是微博和公众号，任何粉丝只要关注（订阅）了某一个人的微博或者公众号，
该微博或者公众号就有有状态更新，都会将消息推送（发布）到粉丝…

Redis发布订阅和rabbitmq的区别

可靠性 redis ：没有相应的机制保证消息的可靠消费，如果发布者发布一条消息，而没有对应的订阅者的话，这条 消息将丢失，不会存在内存中； rabbitmq：具有消息消费确认机制，如果发布一条消息，还没有消费者消费该队列，那么这条消息将一直存 放在队列中，直到有消费者消费了该条消息，以此可以保证消息的可靠消费；

实时性 redis:实时性高，redis作为高效的缓存服务器，所有数据都存在在服务器中，所以它具有更高的实时性

消费者负载均衡 rabbitmq队列可以被多个消费者同时监控消费，但是每一条消息只能被消费一次，由于rabbitmq的消费确 认机制，因此它能够根据消费者的消费能力而调整它的负载； redis发布订阅模式，一个队列可以被多个消费者同时订阅，当有消息到达时，会将该消息依次发送给每个订 阅者；

持久性 redis：redis的持久化是针对于整个redis缓存的内容，它有RDB和AOF两种持久化方式（redis持久化方 式，后续更新），可以将整个redis实例持久化到磁盘，以此来做数据备份，防止异常情况下导致数据丢失。 rabbitmq：队列，消息都可以选择性持久化，持久化粒度更小，更灵活；

队列监控 rabbitmq实现了后台监控平台，可以在该平台上看到所有创建的队列的详细情况，良好的后台管理平台可以 方便我们更好的使用； redis没有所谓的监控平台。

总结redis： 轻量级，低延迟，高并发，低可靠性； rabbitmq：重量级，高可靠，异步，不保证实时； rabbitmq是一个专门的AMQP协议队列，他的优势就在于提供可靠的队列服务，并且可做到异步，而redis主 要是用于缓存的，redis的发布订阅模块，可用于实现及时性，且可靠性低的功能。

Pipeline

概要理论
Redis 的 pipeline(管道)功能在命令行中没有，但 redis 是支持 pipeline 的，而且在各个语言版的
client 中都有相应的实现。 由于网络开销延迟，就算 redis server 端有很强的处理能力，也会由于收到
的 client 消息少，而造成吞吐量小。当 client 使用 pipelining 发送命令时，redis server 必须将部分请
求放到队列中（使用内存），执行完毕后一次性发送结果！
Pipeline 在某些场景下非常有用，比如有多个 command 需要被“及时的”提交，而不需要“及时的”
响应，那么 pipeline 就可以充当这种“批处理”的工具；而且在一定程度上，可以较大的提升性能，性能
提升的原因主要是 TCP 连接中减少了“交互往返”的时间

普通模式与 PipeLine 模式

Jedis 下的普通模式和pieline模式比较

@Test 
public void testGeneralAndPipeline(){
	 JedisPool jedisPool = (JedisPool) context.getBean("jedisPool");
	 Jedis jedis = jedisPool.getResource(); 
	 Logger logger = Logger.getLogger(ClusterTest.class);
	 long start = System.currentTimeMillis();
	 for (int i = 0; i < 10000; i++) {
	  jedis.set(String.valueOf(i), String.valueOf(i)); 
	  }
	 long end = System.currentTimeMillis();
	 logger.info("the general total time is:" + (end - start)); 
	 Pipeline pipe = jedis.pipelined(); 
	 // 先创建一个 pipeline 的链接对象
	 long start_pipe = System.currentTimeMillis(); 
	 for (int i = 0; i < 10000; i++) {
	 pipe.set(String.valueOf(i), String.valueOf(i));
	  }
	 pipe.sync(); 
	 // 获取所有的 response
	 long end_pipe = System.currentTimeMillis(); 
	 logger.info("the pipe total time is:" + (end_pipe - start_pipe));
	 }

pipeline 局限性

Pipelining只能用于执行连续且无相关性的命令，当某个命令的生成需要依赖于前一个命令的返回
时，就无法使用Pipelining了。
通过 LUA Scripting功能，可以规避这一局限性

Redis 持久化

因为Redis是内存数据库，它将自己的数据存储在内存里面，一旦Redis服务器进程退出或者运行
Redis服务器的计算机停机，Redis服务器中的数据就会丢失。
为了避免数据丢失，所以Redis提供了持久化机制，将存储在内存中的数据保存到磁盘中，用于在
Redis服务器进程退出或者运行Redis服务器的计算机停机导致数据丢失时，快速的恢复之前Redis存储
在内存中的数据。

Redis持久化—RDB

RDB持久化是将某个时间点上Redis中的数据保存到一个RDB文件中，也叫快照持久化；
该文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时Redis中的数据 ；

创建RDB文件

Redis提供了2个命令来创建RDB文件，一个是SAVE，另一个是BGSAVE。

SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务
器不能处理任何命令请求

BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继
续处理命令请求

RDB文件创建方式

自动保存

触发机制有如下：
1、save m n
自动触发最常见的情况是在配置文件中通过配置save m n，指定当m秒内发生n次变化时，会
触发bgsave。

手动保存

save和bgsave命令，推荐使用bgsave，不过说了等于没说，基本上都不会直接手动保存，~ ~

总结

• 优点：
  RDB文件小，非常适合定时备份，用于灾难恢复。
  因为RDB文件中直接存储的是内存数据，而AOF文件中存储的是一条条命令，需要应用命令。Redis
  加载RDB文件的速度比AOF快很多。
• 缺点：
  RDB持久化方式不能做到实时/秒级持久化。实时持久化要全量刷内存到磁盘，成本太高。每秒fork子
  进程也会阻塞主进程，影响性能。RDB文件是二进制文件，随着Redis不断迭代有多个rdb文件的版本，
  不支持跨版本兼容。老的Redis无法识别新的RDB文件格式。。RDB的缺点是最后一次持久化后的数据可能丢失。

Redis持久化—AOF

AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库数据的 ，图示

开启AOF

AOF持久化默认情况下是关闭的，使用前需要先开启，编辑redis.conf文件，修改如下

文件同步方式

文件重写（压缩）

动机： 随着运行时间的增长，执行的命令越来越多，会导致AOF文件越来越大，当AOF文件过大时，
redis会执行重写机制来压缩AOF文件
AOF文件重写并不需要对现有的AOF文件进行任何读取、分析或者写入操作，而是通过读取服务器当前
的数据库数据来实现的 ，主要是将文件中无效命令剔除，如：
同一个key的值，只保留最后一次写入
已删除或者已过期数据相关命令会被去除

AOF优缺点

优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢，因为不管怎么压缩，它的命令基数总是在不断增长的。

励志语

学习让人忘记目前所遭受的痛楚！