Redis（二）-- 发布订阅、事务、安全、持久化

1、Redis发布订阅

Redis 发布订阅(pub/sub)是一种消息通讯模式：发送者(pub)发送消息，订阅者(sub)接收消息。

打开两个窗口：session1 和 session2

在session1中订阅消息：

​ subscribe xbqChannel 客户端订阅消息，xbqChannel 为相应的频道

在session2中发布消息：

​ publish xbqChannel testMessge 发布消息，同时订阅该频道的客户端能收到该消息

2、Redis事务

和众多其它数据库同样，Redis做为NoSQL数据库也一样提供了事务机制。在Redis中，MULTI/EXEC/DISCARD/WATCH这四个命令是咱们实现事务的基石。  

Redis 事务带有如下重要的特征：

• 在事务中的全部命令都将会被串行化的顺序执行，事务执行期间，Redis不会再为其它客户端的请求提供任何服务，从而保证了事物中的全部命令被原子的执行。
• 和关系型数据库中的事务相比，在Redis事务中若是有某一条命令执行失败，其后的命令仍然会被继续执行。
• 咱们能够经过MULTI命令开启一个事务，有关系型数据库开发经验的人能够将其理解为"BEGIN TRANSACTION"语句。在该语句以后执行的命令都将被视为事务以内的操做，最后咱们能够经过执行EXEC/DISCARD命令来提交/回滚该事务内的全部操做。这两个Redis命令可被视为等同于关系型数据库中的COMMIT/ROLLBACK语句。
• 在事务开启以前，若是客户端与服务器之间出现通信故障并致使网络断开，其后全部待执行的语句都将不会被服务器执行。然而若是网络中断事件是发生在客户端执行EXEC命令以后，那么该事务中的全部命令都会被服务器执行。
• 当使用Append-Only模式时，Redis会经过调用系统函数write将该事务内的全部写操做在本次调用中所有写入磁盘。然而若是在写入的过程当中出现系统崩溃，如电源故障致使的宕机，那么此时也许只有部分数据被写入到磁盘，而另一部分数据却已经丢失。Redis服务器会在从新启动时执行一系列必要的一致性检测，一旦发现相似问题，就会当即退出并给出相应的错误提示。此时，咱们就要充分利用Redis工具包中提供的redis-check-aof工具，该工具能够帮助咱们定位到数据不一致的错误，并将已经写入的部分数据进行回滚。修复以后咱们就能够再次从新启动Redis服务器了。

一个事务从开始到执行会经历如下三个阶段：开始事务、命令入队、执行事务。

3、安全

1.查看redis的密码：config get requirepass

2.为redis设置密码的方法：

• 在redis.conf中进行配置：requirepass xbqpass
• 经过命令行进行设置：redis> config set requirepass xbqpass

3.当对redis进行操做时，须要受权： redis> auth xbqpass

4、持久化

1.RDB（Snapshotting快照持久化）

快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。能够经过配置设置自动作快照持久化的方式。咱们能够配置redis在n秒内若是超过m个key被修改就自动作快照，下面是默认的快照保存配置：

1. save 900 1 #900秒内若是超过1个key被修改，则发起快照保存
2. save 300 10 #300秒内容如超过10个key被修改，则发起快照保存
3. save 60 10000 #在60秒(1分钟)以后，若是至少有10000个key发生变化，则dump内存快照

client 也可使用save或者bgsave命令通知redis作一次快照持久化，每次快照持久化都是将内存数据完整写入到磁盘一次，并非增量的只同步脏数据。若是数据量大的话，并且写操做比较多，必然会引发大量的磁盘io操做，可能会严重影响性能。另外因为快照方式是在必定间隔时间作一次的，因此若是redis意外down掉的话，就会丢失最后一次快照后的全部修改。

2.AOF（Append-only）

redis会将每个收到的写命令都经过write函数追加到文件中(默认是appendonly.aof)。当redis重启时会经过从新执行文件中保存的写命令来在内存中重建整个数据库的内容。

1. appendonly yes #启用aof持久化方式
2. # appendfsync always #每次收到写命令就当即强制写入磁盘，最慢的，可是保证彻底的持久化，不推荐使用
3. appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面作了很好的折中，推荐
4. # appendfsync no #彻底依赖os，性能最好,持久化没保证

3.RDB机制的优点和劣势

1.RDB优点:

• 一旦采用该方式，那么整个Redis数据库将只包含一个文件，这对于文件备份而言是很是完美的。好比，你可能打算每一个小时归档一次最近24小时的数据，同时还要天天归档一次最近30天的数据。经过这样的备份策略，一旦系统出现灾难性故障，咱们能够很是容易的进行恢复。
• 对于灾难恢复而言，RDB是很是不错的选择。由于咱们能够很是轻松的将一个单独的文件压缩后再转移到其它存储介质上。
• 性能最大化。对于Redis的服务进程而言，在开始持久化时，它惟一须要作的只是fork出子进程，以后再由子进程完成这些持久化的工做，这样就能够极大的避免服务进程执行IO操做了。
• 相比于AOF机制，若是数据集很大，RDB的启动效率会更高。

2.RDB劣势：

• 若是你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。由于系统一旦在定时持久化以前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
• 因为RDB是经过fork子进程来协助完成数据持久化工做的，所以，若是当数据集较大时，可能会致使整个服务器中止服务几百毫秒，甚至是1秒钟。

4.AOF机制的优点和劣势

1.AOF优点：

1). 该机制能够带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不一样步。事实上，每秒同步也是异步完成的，其效率也是很是高的，所差的是一旦系统出现宕机现象，那么这一秒钟以内修改的数据将会丢失。而每修改同步，咱们能够将其视为同步持久化，即每次发生的数据变化都会被当即记录到磁盘中。能够预见，这种方式在效率上是最低的。

2). 因为该机制对日志文件的写入操做采用的是append模式，所以在写入过程当中即便出现宕机现象，也不会破坏日志文件中已经存在的内容。然而若是咱们本次操做只是写入了一半数据就出现了系统崩溃问题，不用担忧，在Redis下一次启动以前，咱们能够经过redis-check-aof工具来帮助咱们解决数据一致性的问题。

3). 若是日志过大，Redis能够自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会建立一个新的文件用于记录此期间有哪些修改命令被执行。所以在进行rewrite切换时能够更好的保证数据安全性。

4). AOF包含一个格式清晰、易于理解的日志文件用于记录全部的修改操做。事实上，咱们也能够经过该文件完成数据的重建。

2.AOF劣势：

• 对于相同数量的数据集而言，AOF文件一般要大于RDB文件。 根据同步策略的不一样，AOF在运行效率上每每会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB同样高效。

3.如何修复坏损的AOF文件：

1). 将现有已经坏损的AOF文件额外拷贝出来一份。 2). 执行"redis-check-aof --fix "命令来修复坏损的AOF文件。 3). 用修复后的AOF文件从新启动Redis服务器。

欢迎关注个人公众号，第一时间接收最新文章~ 搜索公众号： 码咖 或者 扫描下方二维码：