1.Redis发布订阅接收消息。打开两个窗口：session1和session2在session1中订阅消息：subscribexbqChannel客户端订阅消息，xbqChannel在session2中发布消息对应通道：publishxbqChanneltestMessge发布消息，订阅通道的客户端在同时可以收到消息2.Redis事务Redis和其他很多数据库一样，作为NoSQL数据库，也提供了事务机制。在Redis中，MULTI/EXEC/DISCARD/WATCH这四个命令是我们事务实现的基石。Redis事务具有以下重要特性：事务中的所有命令将按序列化顺序执行。在事务执行过程中，Redis将不再为其他客户端请求提供任何服务，从而保证事务命令中的所有事务都是原子执行的。与关系型数据库中的事务相比，Redis事务中如果某条命令执行失败，后续命令仍会执行。我们可以通过MULTI命令来启动一个事务，有关系数据库开发经验的人可以理解为“BEGINTRANSACTION”语句。这条语句之后执行的所有命令都将被视为事务内的操作，最后我们可以通过执行EXEC/DISCARD命令来提交/回滚事务内的所有操作。这两个Redis命令可以认为等同于关系数据库中的COMMIT/ROLLBACK语句。在事务开启之前，如果客户端与服务端通信失败，网络断开，则后续所有要执行的语句都不会被服务端执行。但是，如果网络中断事件发生在客户端执行EXEC命令之后，那么事务中的所有命令都会被服务端执行。当使用Append-Only模式时，Redis会在本次调用中通过调用系统函数write将事务中的所有写操作写入磁盘。但是，如果在写入过程中出现系统崩溃，比如断电导致宕机，那么此时可能只有一部分数据写入了磁盘，而另一部分数据已经丢失。Redis服务器在重启时会进行一系列必要的一致性检查，一旦发现类似问题，会立即退出并给出相应的错误信息。此时，我们就需要充分利用Redis工具包中提供的redis-check-aof工具，它可以帮助我们定位数据不一致错误，回滚部分写入的数据。修复后我们可以再次重启Redis服务器。一个事务从启动到执行会经历以下三个阶段：启动事务、入队命令、执行事务。三、安全1、查看redis的密码：configgetrequirepass2、如何设置redis的密码：在redis.conf中配置：requirepassxbqpass通过命令行设置：redis>configsetrequirepassxbqpass3、操作redis时，需要授权：redis>authxbqpass四、持久化1、RDB（Snapshottingsnapshotpersistence）snapshot是默认的持久化方式。该方法是将内存中的数据作为快照写入二进制文件，默认文件名为dump.rdb。您可以通过配置设置来配置自动持久化快照的方式。我们可以配置redis在n秒内修改超过m个key时自动快照。下面是默认的快照保存配置：save9001#如果900秒内修改超过1个key，则发起快照保存save30010#300秒如果修改超过10个key，发起快照保存save6010000#60秒（1分钟）后，如果至少有10000个key发生了变化，dumpmemorysnapshotclient也可以使用save或者bgsave命令通知redis做一次快照持久化。每次持久化快照，内存数据就被完整写入磁盘一次。它不是增量的，只同步脏数据。如果数据量大，写操作多，势必造成大量的磁盘io操作，可能会严重影响性能。另外，由于快照方式是每隔一定时间做一次，如果redis意外宕机，最后一次快照之后的所有修改都会丢失。2、AOF（Append-only）redis会通过write函数（默认是appendonly.aof）将每条接收到的写命令追加到文件中。当redis重启时，会通过重新执行保存在文件中的写命令，将整个数据库的内容重新构建到内存中。appendonlyyes#启用aof持久化方式#appendfsyncalways#每次收到写命令就强制写入磁盘，最慢，但要保证完全持久化，不建议使用appendfsynceverysec#强制每秒写入一次磁盘，在性能和持久性方面做了很好的折衷。推荐#appendfsyncno#完全依赖os，性能最好，不保证持久性。三、RDB机制的优缺点：1、RDB优点：一旦采用这种方式，那么整个Redis数据库将只包含一个文件，非常适合文件备份。例如，您可能计划每小时归档最近24小时的数据，并每天归档最近30天的数据。通过这样的备份策略，一旦系统发生灾难性故障，我们可以非常轻松地进行恢复。对于容灾，RDB是一个非常好的选择。因为我们可以很方便地压缩单个文件，然后将其传输到其他存储介质中。最大化性能。对于Redis服务进程来说，当它开始持久化时，只需要fork出子进程，然后由子进程完成持久化工作，可以极大的避免服务进程进行IO操作。相对于AOF机制，如果数据集很大，RDB的启动效率会更高。2、RDB的缺点：如果要保证数据的高可用，即最大程度避免数据丢失，那么RDB将不是一个好的选择。因为一旦系统在预定的持久化之前宕机，之前没有写入磁盘的数据就会丢失。由于RDB通过fork子进程辅助完成数据持久化，如果数据集很大，可能会导致整个服务器停止服务数百毫秒，甚至1秒。四、AOF机制的优缺点：1、AOF的优点：1）。这种机制可以带来更高的数据安全性，即数据持久化。Redis提供了3种同步策略，分别是每秒同步、每次修改同步和非同步。其实第二次同步也是异步完成的，它的效率也是很高的。不同的是，一旦系统宕机，这一秒内修改的数据就会丢失。而每一次同步修改，我们都可以把它看做是同步持久化，即每次发生的数据变化都会立即记录到磁盘中。可以预见，这种方法效率最低。2).由于该机制对日志文件的写入操作采用append方式，即使在写入过程中出现宕机，日志文件中已有的内容也不会被破坏。但是，如果我们这次操作只写了一半的数据导致系统崩溃，不用担心，在Redis下次启动之前，我们可以使用redis-check-aof工具来帮助我们解决数据一致性问题。3).如果日志过大，Redis可以自动启用重写机制。即Redis不断的以append的方式将修改的数据写入到旧的磁盘文件中，同时Redis也会创建一个新的文件来记录这期间执行了哪些修改命令。因此，在重写切换时可以更好地保证数据安全。4).AOF包含一个格式清晰且易于理解的日志文件，用于记录所有修改操作。其实我们也可以通过这个文件完成数据重构。2、AOF缺点：对于同样数量的数据集，AOF文件通常比RDB文件大。根据不同的同步策略，AOF在运行效率上往往比RDB慢。总之每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。3、如何修复损坏的AOF文件：1).为现有损坏的AOF文件制作额外的副本。2).执行“redis-check-aof--fix”命令修复损坏的AOF文件。3).使用修复后的AOF文件重新启动Redis服务器。感谢您耐心看完文章...
