这篇文章主要讲解了“复述中发布订阅及事务的知识点整理”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“复述中发布订阅及事务的知识点整理”吧!
<强>一、复述,发布订阅
复述,发布订阅(pub/sub)是一种消息通信模式:发送者(酒吧)发送消息,订阅者(子)接收消息。
打开两个窗口:session1中和session2
在session1中订阅消息:
订阅xbqChannel客户端订阅消息,xbqChannel为相应的频道
中在session2中发布消息:
发布xbqChannel testMessge发布消息,同时订阅该频道的客户端能收到该消息
<强>二,复述,事务
和众多其它数据库一样,复述,作为NoSQL数据库也同样提供了事务机制。在复述中,多/执行/丢弃/看这四个命令是我们实现事务的基石。
复述,事务带有以下重要的特征:
在事务中的所有命令都将会被串行化的顺序执行,事务执行期间,复述,不会再为其它客户端的请求提供任何服务,从而保证了事物中的所有命令被原子的执行。
<李>和关系型数据库中的事务相比,在复述,事务中如果有某一条命令执行失败,其后的命令仍然会被继续执行。
<李>我们可以通过多命令开启一个事务,有关系型数据库开发经验的人可以将其理解为“开始,TRANSACTION"语句。在该语句之后执行的命令都将被视为事务之内的操作,最后我们可以通过执行执行/丢弃命令来提交/回滚该事务内的所有操作。这两个复述,命令可被视为等同于关系型数据库中的提交/回滚语句。
<李>在事务开启之前,如果客户端与服务器之间出现通讯故障并导致网络断开,其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后,那么该事务中的所有命令都会被服务器执行。
<李>当使用扩展模式时,复述,会通过调用系统函数写将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃,如电源故障导致的宕机,那么此时也许只有部分数据被写入到磁盘,而另外一部分数据却已经丢失.Redis服务器会在重新启动时执行一系列必要的一致性检测,一旦发现类似问题,就会立即退出并给出相应的错误提示。此时,我们就要充分利用复述,工具包中提供的redis-check-aof工具,该工具可以帮助我们定位到数据不一致的错误,并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动复述,服务器了。
一个事务从开始到执行会经历以下三个阶段:开始事务,命令入队,执行事务。
<强>三、安全
1。查看复述的密码:配置requirepass
2。为复述,设置密码的方法:
在复述。设计中进行配置:requirepass xbqpass
<李>通过命令行进行设置:redis>配置设置requirepass xbqpass
3。当对复述,进行操作时,需要授权:redis>auth xbqpass
<强>四,持久化
<强> 1,RDB(快照快照持久化)
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为转储。rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置复述,在n秒内如果超过m个键被修改就自动做快照,下面是默认的快照保存配置:
鸿蒙官方战略合作共建——HarmonyOS技术社区
<李>节省900 1 # 900秒内如果超过1个键被修改,则发起快照保存
<李>节省300 10 # 300秒内容如超过10个关键被修改,则发起快照保存
<李>保存60 10000 #在60秒(1分钟)之后,如果至少有10000个键发生变化,则转储内存快照
客户端,也可以使用保存或者bgsave命令通知复述,做一次快照持久化,每次快照持久化都是将内存数据完整写入到磁盘一次,并不是增量的只同步脏数据。如果数据量大的话,而且写操作比较多,必然会引起大量的磁盘io操作,可能会严重影响性能。另外由于快照方式是在一定间隔时间做一次的,所以如果复述,意外下掉的话,就会丢失最后一次快照后的所有修改。
<强> 2,AOF(扩展)
复述,会将每一个收到的写命令都通过写函数追加到文件中(默认是appendonly.aof)。当复述,重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
