您的位置:首页 > 文旅 > 旅游 > 怎样做网站的优化排名_图形设计网站_市场调研报告1000字_百度搜索引擎推广怎么弄

怎样做网站的优化排名_图形设计网站_市场调研报告1000字_百度搜索引擎推广怎么弄

2024/12/23 5:03:29 来源:https://blog.csdn.net/m0_50460160/article/details/142723976  浏览:    关键词:怎样做网站的优化排名_图形设计网站_市场调研报告1000字_百度搜索引擎推广怎么弄
怎样做网站的优化排名_图形设计网站_市场调研报告1000字_百度搜索引擎推广怎么弄

一、Redis事务

1.介绍:

Redis事务是可以一次执行多个命令,本质是一组命令的集合;一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其他命令插入,不许加塞

在一个队列中一次性、顺序性、排他性的执行一系列命令

2.和关系型数据库事务的对比:

(1).单独的隔离操作:Redis的事务仅仅是保证事务里的操作会被连续独占的执行,redis命令执行是单线程架构,在执行完事务内所有指令前是不可能再去同时执行其他客户端的请求的

(2).没有隔离级别的概念:因为事务提交前任何指令都不会被实际执行,也就不存在"事务内的査询要看到事务里的更新,在事务外査询不能看到"这种问题了

(3).不保证原子性:Redis的事务不保证原子性,也就是不保证所有指令同时成功或同时失败,只有决定是否开始执行全部指令的能力,没有执行到一半进行回滚的能力

(4).排它性:Redis会保证一个事务内的命令依次执行,而不会被其它命令插入

3.常用命令:

(1).DISCARD:取消事务,放弃执行事务块内的所有命令

(2).EXEC:执行所有事务块内的命令。

(3).MULTI:标记一个事务块的开始

(4).UNWATCH:取消WATCH命令对所有key的监视。

(5).WATCH key [key ...]:监视一个(或多个)key ,如果在事务执行之前这个(或这些)key被其他命令所改动,那么事务将被打断。

案例一:正常执行(MULTI EXEC)

案例二:放弃事务(MULTI DISCARD)

案例三:全体连坐(一组命令中的一条命令出现问题后整组命令无法执行)

案例四:冤头债主(一组命令中的一条命令出现问题后整组命令中其他命令依旧可以执行,redis不支持事务回滚,开发者必须在事务执行出错后自觉恢复到发生错误之前的状态)

案例五:watch监控,redis使用watch来提供乐观锁定,类似于check and set;一旦执行了exec之前加的监控锁都会被取消,当客户端连接丢失的时候所有东西都会被取消监视

开启事务:以MULTI开始一个事务

入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列中

执行:由EXEC命令触发事务

二、Redis管道

1.如何优化频繁命令往返造成的性能瓶颈(管道介绍):

管道可以一次性发送多条命令给服务端,服务端一次处理完毕后通过一条响应一次性将结果返回,通过减少客户端与Redis的通信次数来实现降低往返延时时间;管道实现原理是队列,先进先出的特性保证了数据的顺序性

管道是为了解决RTT往返回时,仅仅是将命令打包一次性发送,对整个Redis执行不造成其他任何影响;管道时批处理命令的变种优化措施,类似Redis原生批命令(mget和mset)

2.管道与原生批命令的对比:

a.原生批命令是原子性,管道非原子性

b.原生批命令一次执行执行一种命令,管道支持批量执行不同命令

c.原生批命令是服务端实现,而管道需要服务端和客户端共同完成

3.管道与事务对比:

a.事务具有原子性,管道不具有原子性

b.管道一次性将多条命令发送到服务器,事务是一条一条命令发送,只有在接收到EXEC命令后才会执行

c.执行事务时会阻塞其他命令的执行,而执行管道中的命令时不会

4.使用管道时的注意事项:

a.管道缓冲的指令只是会依次执行,不能保证其原子性,如果执行中指令发送异常,将会继续执行后续的指令

b.使用管道组装的命令个数不能太多,不然数据量过大客户端阻塞的时间可能过长,同时服务端被迫回复一个队列答复,占用很多内存

三、Redis发布订阅pub/sub

1.介绍:

发布订阅是一种消息通信模式,发送者发送消息,订阅者接收消息,可以实现进程间的消息传递;Redis可以实现消息中间件MQ的功能,通过发布订阅实现消息的引导和分流;

发布订阅其实是一个轻量级的队列,只不过数据不会被持久化,一般用来处理实时性较高的异步消息

2.常用命令:

(1).PSUBSCRIBE pattern [pattern ...]:订阅一个或多个符合给定模式的频道,推荐先执行订阅后再发布,订阅成功之前发布的消息是收不到的;订阅的客户端每次可以收到一个3个参数的消息,分别是消息的种类、始发频道的名称和实际的消息内容

(2).PUBSUB subcommand [argument [argument ..]] :查看订阅与发布系统状态。

PUBSUB CHANNELS:由活跃频道组成的列表

PUBSUB NUMSUB [channel [channel ...]]:某个频道有几个订阅者

PUBSUB NUMPAT:只统计使用PSUBSCRIBE命令执行的,返回客户端订阅的唯一模式的数量

(3).PUBLISH channel message:将信息发送到指定的频道

(4).PUNSUBSCRIBE [pattern [pattern ...]]:退订所有给定模式的频道

(5).SUBSCRlBE channel [channel ...]:订阅给定的一个或多个频道的信息

(6).UNSUBSCRIBE [channel [channel ...]]:指退订给定的频道

3.优缺点:

(1).发布的消息在Redis系统中不能持久化,因此,必须先执行订阅,再等待消息发布。如果先发布了消息,那么该消息由于没有订阅者将会被直接丢弃

(2).消息只管发送对于发布者而言消息是即发即失的,不管接收,也没有ACK机制,无法保证消息的消费成功

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com