自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(66)
  • 收藏
  • 关注

原创 RabbitMQ的相关题

采⽤Java语⾔开发, 由阿⾥巴巴开源, 后捐赠给了Apache. 在可⽤性, 可靠性以及稳定性等⽅⾯都⾮常出⾊, 吞吐量能达到⼗万级, 在Alibaba集团内部⼴泛使⽤, 但⽀持的客⼾端语⾔不多, 产品较新⽂档较少,且社区活跃度⼀般. 适合于⼤规模分布式系统, 可靠性要求⾼, 且并发⼤的场景, ⽐如互联⽹⾦融.延迟队列, 就是希望等待特定的时间之后, 消费者才能拿到这个消息. TTL刚好可以让消息延迟⼀段时间成为死信, 成为死信的消息会被投递到死信队列⾥, 这样消费者⼀直消费死信队列⾥的消息就可以了。

2024-10-01 14:51:17 1455

原创 RabbitMQ的应用问题

单个消费者的吞吐太低了, 当需要多个消费者以提⾼处理速度时, 可以使⽤分区消费. 把⼀个队列分割成多个分区, 每个分区由⼀个消费者处理, 以此来保持每个分区内消息的顺序性(⽐如⽤⼾修改资料后, 发送⼀条⽤⼾资料消息. 消费者在处理时, 需要保证消息发送的先后顺序,但这种场合并不需要保证全局顺序. 只需要保证同⼀个⽤⼾的消息顺序消费就可以. 这时候就可以采⽤把消费按照⼀定的规则, 分为多个区, 每个分区由⼀个消费者处理。

2024-09-30 13:12:15 1034 1

原创 RabbitMQ的高级特性-事务

RabbitMQ是基于AMQP协议实现的, 该协议实现了事务机制, 因此RabbitMQ也⽀持事务机制. SpringAMQP也提供了对事务相关的操作. RabbitMQ事务允许开发者确保消息的发送和接收是原⼦性的, 要么全部成功, 要么全部失败。2. 添加 @Transactional , 消息1和消息2全部发送失败。1. 不加 @Transactional , 会发现消息1发送成功。

2024-09-30 12:52:00 572

原创 RabbitMQ的高级特性-死信队列

中,这个交换器就是DLX( Dead Letter Exchange ), 绑定DLX的队列, 就称为死信队列(Dead Letter Queue,简称DLQ).1. 消息被拒绝( Basic.Reject/Basic.Nack ),并且设置 requeue 参数为 false.有死信, ⾃然就有死信队列. 当消息在⼀个队列中变成死信之后,它能被重新被发送到另⼀个交换器。简单理解就是因为种种原因, ⽆法被消费的信息, 就是死信.3. 队列达到最⼤⻓度.

2024-09-30 12:51:18 267

原创 RabbitMQ的题

b. 解决办法: 消息确认 RabbitMQ 提供了 消费者应答机制 来使 RabbitMQ 能够感知到消费者是否消费成功消息. 默认情况下消费者应答机制是⾃动应答的, 可以开启⼿动确认, 当消费者确认消费成功后才会删除消息, 从⽽避免消息丢失. 除此之外, 也可以配置重试机, 当消息消费异常时, 通过消息重试确保消息的可靠性。死信(Dead Letter)是消息队列中的⼀种特殊消息, 它指的是那些⽆法被正常消费或处理的消息.在消息队列系统中, 如RabbitMQ, 死信队列⽤于存储这些死信消息。

2024-09-29 17:38:05 772

原创 RabbitMQ的高级特性-限流

答:使用channel.basicQos(int prefetchCount) ⽅法, 来限制当前信道上的消费者所能保持的最⼤未确认消息的数量⽐如: 消费端调⽤了 channelbasicQos(5) , RabbitMQ会为该消费者计数, 发送⼀条消息计数+1, 消费⼀条消息计数-1, 当达到了设定的上限, RabbitMQ就不会再向它发送消息了,直到消费者确认了某条消息.类似TCP/IP中的"滑动窗⼝".通过设置prefetchCount参数, 同时也必须要设置消息应答⽅式为⼿动应答。

2024-09-29 17:35:39 775

原创 RabbitMQ的高级特性-延迟队列

10s过期的消息, 也是在20s后才进⼊到死信队列.消息过期之后, 不⼀定会被⻢上丢弃. 因为RabbitMQ只会检查队⾸消息是否过期, 如果过期则丢到死对列. 此时就会造成⼀个问题, 如果第⼀个消息的延时时间很⻓, 第⼆个消息的延时时间很短, 那第一个消息并不会优先得到执⾏.延迟队列, 就是希望等待特定的时间之后, 消费者才能拿到这个消息. TTL刚好可以让消息延迟⼀段时间成为死信, 成为死信的消息会被投递到死信队列⾥, 这样消费者⼀直消费死信队列⾥的消息就可以了。

2024-09-28 21:02:58 709

原创 RabbitMQ的高级特性-TTL

①设置队列的TTL,队列中所有的消息都有相同的过期时间 ②TTL(Time to Live, 过期时间), 即过期时间. RabbitMQ可以对消息和队列设置TTL.当消息到达存活时间之后, 还没有被消费, 就会被⾃动清除。, 即过期时间. RabbitMQ可以对消息和队列设置TTL.当消息到达存活时间之后, 还没有被消费, 就会被⾃动清除。

2024-09-28 13:01:09 576

原创 RabbitMQ高级特性-重试机制

⾃动确认模式下, RabbitMQ 会在消息被投递给消费者后⾃动确认消息. 如果消费者处理消息时抛出异常, RabbitMQ 根据配置的重试参数⾃动将消息重新⼊队, 从⽽实现重试. 重试次数和重试间隔等参数可以直接在RabbitMQ的配置中设定,并且RabbitMQ会负责执⾏这些重试策略.引入:在消息传递过程中, 可能会遇到各种问题, 如⽹络故障, 服务不可⽤, 资源不⾜等, 这些问题可能导致消息处理失败. 为了解决这些问题, RabbitMQ 提供了重试机制, 允许消息在处理失败后重新发送.

2024-09-28 12:42:17 732

原创 RabbitMQ高级特性-发送方确认

如果只重写RabbitTemplate中的ConfirmCallback ,会出现其他的生产者、消费者会受到影响,因此服务器中自己生成的RabbitTemplate也要重写。消息到达Exchange之后, 会根据路由规则匹配, 把消息放⼊Queue中. Exchange到Queue的过程, 如果⼀条消息⽆法被任何队列消费(即没有队列与消息的路由键匹配或队列不存在等), 可以选择把消息退回给发送者. 消息退回给发送者时, 我们可以设置⼀个返回回调⽅法, 对消息进⾏处理.

2024-09-27 17:36:14 981

原创 RabbitMQ高级特性-持久性

设置了队列和消息的持久化, 当 RabbitMQ 服务重启之后, 消息依旧存在. 如果只设置队列持久化,重启之后消息会丢失. 如果只设置消息的持久化, 重启之后队列消失, 继⽽消息也丢失. 所以单单设置消息持久化⽽不设置队列的持久化显得毫⽆意义。如果交换器不设置持久化, 那么在 RabbitMQ 服务重启之后, 相关的交换机元数据会丢失, 对⼀个⻓期使⽤的交换器来说,建议将其置为持久化的.RabbitMQ的持久化分为三个部分:交换器的持久化、队列的持久化和消息的持久化。消息持久化(消息不丢失)

2024-09-26 18:55:43 700

原创 RabbitMQ的高级特性-消息确认机制

requeue: 表⽰拒绝后, 这条消息如何处理. 如果requeue 参数设置为true, 则RabbitMQ会重新将这条消息存⼊队列,以便可以发送给下⼀个订阅的消费者. 如果requeue参数设置为false, 则RabbitMQ会把消息从队列中移除, ⽽不会把它发送给新的消费者.这种模式下, 消费者在消息处理成功时会⾃动确认消息, 但如果处理过程中抛出了异常, 则不会确认消息.(消费者正确处理:消息自动确认,消费者异常处理:消费会不停重试)

2024-09-26 17:18:20 902

原创 RabbitMQ应用

路由模式的升级版, 在routingKey的基础上,增加了通配符的功能, 使之更加灵活.Topics和Routing的基本原理相同,即:⽣产者将消息发给交换机,交换机根据RoutingKey将消息转发给与RoutingKey匹配的队列. 类似于正则表达式的⽅式来定义Routingkey的模式.⼀个⽣产者P, 多个消费者C1, C2, X代表交换机消息复制多份,每个消费者接收相同的消息⽣产者发送⼀条消息,经过交换机转发到多个不同的队列,多个不同的队列就有多个不同的消费者。

2024-09-26 16:17:16 904

原创 RabbitMQ的概述

2、流量削峰: 在访问量剧增的情况下, 应⽤仍然需要继续发挥作⽤, 但是这样的突发流量并不常⻅. 如果以能处理这类峰值为标准⽽投⼊资源,⽆疑是巨⼤的浪费. 使⽤MQ能够使关键组件⽀撑突发访问压⼒, 不会因为突发流量⽽崩溃. ⽐如秒杀或者促销活动, 可以使⽤MQ来控制流量, 将请求排队, 然后系统根据⾃⼰的处理能⼒逐步处理这些请求。3、消息分发: 当多个系统需要对同⼀数据做出响应时, 可以使⽤MQ进⾏消息分发. ⽐如⽀付成功后, ⽀付系统可以向MQ发送消息, 其他系统订阅该消息, ⽽⽆需轮询数据库.

2024-08-14 17:12:55 302

原创 RabbitMQ 核⼼概念

RocketMQ采⽤Java语⾔开发, 由阿⾥巴巴开源, 后捐赠给了Apache.它在设计时借鉴了Kafka,做出了⼀些⾃⼰的改进, ⻘出于蓝⽽胜于蓝, 经过多年双⼗⼀的洗礼, 在可⽤性、可靠性以及稳定性⽅⾯都有出⾊的表现. 适合对于可靠性⽐较⾼,且并发⽐较⼤的场景, ⽐如互联⽹⾦融. 但⽀持的客⼾端语⾔不多, 且社区活跃度⼀般。综合: 由于RabbitMQ的综合能⼒较强, 咱们这边的项⽬没有那么⼤的⾼并发, 且RabbitMQ社区⽐较成熟, 管理界⾯友好, 所以咱们接下来主要学习RabbitMQ的使⽤。

2024-08-14 17:11:58 1185

原创 CGroup资源控制

① 创建内存的 cgroup,很简单我们进入到 cgroup 的内存控制目录/sys/fs/cgroup/memory,我们创建目录 test_memory。2)cfs_quota_us:cfs_quota_us 表示 Cgroup 可以使用的 cpu 的带宽,单位为微秒。/sys/fs/cgroup/cpu,我们创建目录 test_cpu,可以看到系统会自动为我们创建 cgroup。-c, --cpu N:产生 N 个进程,每个进程都循环调用 sqrt 函数产生 CPU 压力。

2024-07-29 08:37:00 1006

原创 Docker NameSpace隔离

-fork:执行 unshare 的进程 fork 一个新的子进程,在子进程里执行 unshare 传入的参数。--fork :新建了一个 bash 进程,是因为如果不建新进程,新的 namespace 会用 unshare。mount-proc :是因为 Linux 下的每个进程都有一个对应的 /proc/PID 目录,该目录包含。的 PID 作为新的空间的父进程,而这个 unshare 进程并不在新的 namespace 中,所。特意提供了一个选项--mount-proc 来解决这个问题。

2024-07-26 16:01:30 713

原创 Spring Cloud Fegin

将Feign的Client抽取为⼀个独⽴的模块, 并把涉及到的实体类等都放在这个模块中, 打成⼀个Jar. 服务消费⽅只需要依赖该Jar包即可. 这种⽅式在企业中⽐较常⻅, Jar包通常由服务提供⽅来实现.①name/value:指定FeignClient的名称, 也就是微服务的名称, ⽤于服务发现, Feign底层会使⽤。我们可以定义好⼀个接⼝, 服务提供⽅实现这个接⼝, 服务消费⽅编写Feign 接⼝的时候, 直接继承这个接⼝。接⼝可以放在⼀个公共的Jar包⾥, 供服务提供⽅和服务消费⽅使⽤。

2024-07-24 09:43:07 699

原创 Spring Cloud Gateway

但是当前所有微服务的接⼝都是直接对外暴露的, 可以直接通过外部访问. 为了保证对外服务的安全性,服务端实现的微服务接⼝通常都带有⼀定的权限校验机制. 由于使⽤了微服务, 原本⼀个应⽤的的多个模块拆分成了多个应⽤, 我们不得不实现多次校验逻辑. 当这套逻辑需要修改时, 我们需要修改多个应⽤, 加重了开发⼈员的负担.引入:通过Eureka, Nacos解决了服务注册, 服务发现的问题, 使⽤Spring Cloud LoadBalance解决了负载均衡的问题, 使⽤OpenFeign解决了远程调⽤的问题.

2024-07-24 08:04:06 1593

原创 Spring Cloud Nacos

微服务启动前, 需要先获取nacos中配置, 并与application.yml配置合并. 在微服务运⾏之前, Nacos要求必须使⽤ bootstrap.properties 配置⽂件来配置Nacos Server 地址.注:Nacos会记录每个服务实例的IP和端⼝号, 当发现IP和端⼝都没有发⽣变化时, Nacos不允许⼀个服务实例类型发⽣变化, ⽐如从临时实例,变为⾮临时实例, 或者从⾮临时实例, 变成临时实例.② 多⼈开发时, 配置⽂件可能需要经常修改, 使⽤同⼀个配置⽂件容易冲突.

2024-07-21 09:44:31 903

原创 Spring Cloud LoadBalanced

在 RestTemplate 配置类上⽅, 使⽤ @LoadBalancerClient 或 @LoadBalancerClients 注解, 可以对不同的服务提供⽅配置不同的客⼾端负载均衡算法策略.⽐较有名的服务端负载均衡器是Nginx. 请求先到达Nginx负载均衡器, 然后通过负载均衡算法, 在多个服务器之间选择⼀个进⾏访问.当服务流量增⼤时, 通常会采⽤增加机器的⽅式进⾏扩容, 负载均衡就是⽤来在多个机器或者其他资源中, 按照⼀定的规则合理分配负载.注:负载均衡分为服务端负载均衡和客⼾端负载均衡.

2024-07-20 08:52:18 419

原创 Spring Cloud Eureka

比如(医院,学校等)机构的电话号码发生变化,就需要通知各个使⽤⽅, 但是这些机构的使⽤⽅群体是巨⼤的, 没办法做到⼀⼀通知, 怎么处理呢?CAP理论中的⼀致性, 指的是强⼀致性. 所有节点在同⼀时间具有相同的数据(多个数据库中,主数据库和从数据库的数据同步要完全一致)Eureka是Netflix开发的基于REST的服务发现框架, 主要⽤于服务注册, 管理,负载均衡和服务故障。实例 1 2 0 1 2 0 1 2 0。

2024-07-10 15:09:39 887

原创 Spring Cloud项目搭建

2、统一接口:对资源的操作,比如获取,创建,修改和删除,些窗口正好对应http协议提供的GET、POST、PUT和DELETE方法,换而言知,如果使用RESTful风格的接口,从接口上你可能只定位其资源,但是无法知晓它具体进行了什么操作,需要具体了解其发生了什么操作动作要从起http请求方法类型上进行判断 (比如:同一个url :GET/blog/{blogId}:查询博客 DELETE/blog/{blogId} 删除博客)资源:网络上的数据,比如图片,视频,文本等都是资源。

2024-07-10 13:48:55 922

原创 Spring Cloud 引入

3.从关系上:分布式和集群在实践中,很多时候是配合使用的,比如分布式的某一个节点,可能由一个集群来代替的。定义:当部署的服务越来越多,重复的代码会越来越多,服务的调用关系也会越来越复杂,我们可以把一些通用的,会被多个上层服务调用的共享业务,提取成独立的基础服务,组成一个个微小的服务,这就是微服务。2.功能上:集群每个节点端午功能是相同的,并且是可以替代的。集群:将一个系统完整的部署到多个服务器上,每个服务器都能提供系统所有的任务,每个服务器都能通过负载均衡调度完成任务,每个服务器都是集群的节点。

2024-07-09 21:53:03 376

原创 垃圾回收

内存泄露:服务器,追求的是7*24小时运行,不能随便重启 如果申请的内存,没有手动释放,后面继续申请的话,就会使剩下的内存越来越少,最终内存没了,后续申请就会失效=>进程就会出现严重Bug了,甚至崩溃。要想使用对象2,就得要访问到对象1,;在左侧区域中,有效对象复制到右侧区域,接下来就可以使右侧区域了用了一段时间之后,也会有很多对象,也是同理,把有效对象复制到左侧,把右侧区域统一释放。

2024-06-04 11:57:10 625

原创 JVM的相关知识

这里用符号引用替换直接引用的过程(符号5引用:此时.class文件中,不知道字符串真实的内存地址是哪里的,只能知道一个相对位置的偏移量,知道字符串的内容在.class文件的那个地方;有些特殊情况,服务器不方便重启,就可以“打补丁”,通过一些特殊手段,把书序替换的类给卸载掉,直接用加载好的心得类替换(新版代码)(Java这里用的倒不是很多,Java的服务器一般都是分布式系统,天然就可以方便重启的)有的服务器需要打“热补丁”代码有bug,正常操作应该是修改代码,重新编译,用新的版本代替就得版本,重启服务器。

2024-05-30 17:34:29 972

原创 性能测试

从用户视角来考虑,响应时间反映了完成某个操作所需要的时间,标准定义是,应用系统从发出请求开始,到客户端接收完所有的字节数据所消耗的时间。指模拟正式用户在实际操作时的停顿间隔时间,从业务的角度来讲,思考时间指的是用户在进行操作 时,每个请求之间的间隔时间。软件1(美团1.0版本)和软件2(美团2.0版本)是一样的功能,登录,退出,查看首页。双11的时候,有100万用户,同时操作淘宝系统,此时淘宝系统承载的压力非常大。它是衡量系统处理能力的重要指标。不同系统资源的使用情况,包含CPU,内存,硬盘,网络等。

2024-05-17 14:44:24 893

原创 软件测试的一些概念

软件的生命周期:软件的生命周期是指从软件产品的设想开始到软件不在使用而结束的时间,把软件看成是有生命的事物, 那么软件的生命周期可以分成六个阶段,即需求分析,计划,设计,编码,测试,运行维护。从软件功能需求出发,无遗漏的识别出测试需求是至关重要的,这将直接关系到用例的测试覆盖率 对于识别出的每个测试需求点,需要采用具体的设计测试用例的方法来进行测试用例的设计。计划:项目什么时候开始,什么时候结束,由谁开发,测试确定开始结束时间,测试人员。(给客户交付的软件)重于完备的文档(测试用例,需求文档,技术文档。

2024-05-15 16:47:40 843

原创 技术架构

运维复杂度高:业务不断发展,应用和服务都会不断变多,应用和服务的部署变得复杂,同一台服务器上部署多个服务还要解决运行环境冲突问题,此外,对于大促这类需要动态扩缩容的场景,需要水平扩展服务的性能,就需要在新增的服务上准备运行环境,部署服务等,运维将变得十分困难。缺点:带来了缓存一致性,缓存击穿,缓存失效,缓存雪崩等问题;出现原因:单机的写库会逐渐会达到性能瓶颈,需要拆分数据库,数据表的数据量太大,处理压力太大,需要进行分表,为降低运维压力,业界逐渐研发了分布式数据库,库表天然支持分布式。

2024-05-15 16:03:16 748

原创 软件测试用例

答:依据需求将输入(特殊情况下会考虑输出)划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例测试通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举测试的问题。兼容:软件在各个品台上能够运行,常考虑的设备有IOS,Android,PC(电脑,windows,Linux,Mac),如果是浏览器就要考虑浏览器的版本。性能:压缩一个非常小的文件,用的时间非常短;比如:男同胞找女朋友:女的,活的,可爱的,有钱的,长得白,身材好,温柔,善良。

2024-05-12 09:39:13 1028

原创 软件测试基础

需要注意 的是,测试人员不应该一味地要求对Bug进行修改,因为修改可能带来回归的风险,同时带来的是回归 测试的工作量,如果时间比较紧迫,修改后剩余的时间若不足以做一次有效的回归测试,可能不修改是 个明智的选择。如果测试人员发 现在写完一个缺陷后,好像还有很多关于Bug的信息没有表达出来,或者很难用书面语言表达出来时, 就应该在提交Bug后,马上找相关的程序员解释刚才录入的Bug,确保程序员明白Bug描述的意思,而 不要等待开发人员找自己了解更多的信息。如果是依据需 求提出的故障,能写明需求的来源是最好的。

2024-05-11 22:09:58 454

原创 对软件测试的一些了解

测试开发:根据需求写测试用例,执行测试,发现bug,开发自动化测试用例,开发测试平台(提供工作效率,保障软件质量)测试:写测试用例,执行测试,自动化测试,性能测试,开发测试平台。较强的学习能力:不同的公司用到的技术不一样,学习测试工具,学习不同公司的测试流程。测试:初级测试工程师-》中级测试工程师-》高级测试工程师-》架构师-》项目经理。测试:测试+开发(部分的白盒测试开发人员完成,剩余的一些测试测试人员完成)例如:买衣服的案例:保暖性,时尚,大小,穿上显瘦,价格。5)账号,密码输入非法字符,会有提示。

2024-05-06 17:16:20 427

原创 redis的持久化

因此,子进程里的内存数据是父进程fork之前的状态,fork之后,新来的请求,对内存造成的修改,是子进程不知道的。答:此处的性能开销,其实挺小的,fork在进行内存拷贝的时候,不是简单无脑的直接把所有的数据都拷贝一遍,而是“写时拷贝”的机制来完成的(如果紫禁城例的这个内存数据和父进程的内存数据完全一样了,此时就不会触发真正的拷贝动作(而是他俩用一份内存数据),但是,其实这俩进程的内存空间,应该是各自独立的,一旦某一方针对这个数据做了修改,就会立即触发真正物理上的数据拷贝)

2024-04-20 16:48:31 1082

原创 Redis的主从复制

从节点要从主节点这里进行全量复制,全量复制开销是很大的,有些时候,从节点本来就持有主节点的部分数据,这个时候,就不填需要进行全量复制了(比如出现网络抖动,主节点这边最近修改的数据可能就无法及时同步过来,更严重的,从节点已经感知不到主节点了(进一步的从节点可能就会升级成主节点);此时可以通过关闭主节点的AOF,只在从节点上开启AOF(但是,这种设定,有一个严重的缺陷,主节点一旦挂了,不能让他自动重启(如果自动重启,此时没有AOF文件,就会丢失数据,进一步的主从同步,会把从节点的数据也给删了))

2024-04-20 16:27:27 1107

原创 redis的缓存

答:⽐如我需要去⾼铁站坐⾼铁.我们知道坐⾼铁是需要反复刷⾝份证的(进⼊⾼铁站,检票,上⻋, 乘⻋过程中,出站....). 正常来说,我的⾝份证是放在⽪箱⾥的(⽪箱的存储空间⼤,⾜够能装).但是每次刷⾝份证都需 要开⼀次⽪箱找⾝份证,就⾮常不⽅便. 因此我就可以把⾝份证先放到⾐服⼝袋⾥.⼝袋虽然空间⼩,但是访问速度⽐⽪箱快很多. 这样的话每次刷⾝份证我只需要从⼝袋⾥掏⾝份证就⾏了,就不必开⽪箱了. 此时"⼝袋"就是"⽪箱"的缓存.使⽤缓存能够⼤⼤提⾼访问效率.按照月级别统计,就每个月更新一次)

2024-04-20 16:20:56 867

原创 Redis的分布式锁

这里使用事务,能解决上述问题(Redis事务虽然弱,但是能够避免插队),但是有更好的方案lua脚本(lua语言特别轻量(实现一个lua解释器,消耗的体积是非常小的),可以使用lua编写一些逻辑,把这个脚本上传到Redis服务器上,然后就可以让客户端来控制Redis执行上述脚本了,Redis执行lua脚本的过程也是原子的,相当于执行一条命令一样(实际上lua中可以写多个命令))线程安全(多个线程并发执行的时候,执行的先后顺序,是不确定的=>随机性=>需要保证在任意执行下顺序下,执行逻辑都是OK的)=>锁。

2024-04-20 16:17:31 847

原创 Redis的集群

④. A判定B为PFAIL之后,会通过redis内置的Gossip协议,和其他节点进⾏沟通,向其他节点确认B 的状态.(每个节点都会维护⼀个⾃⼰的"下线列表",由于视⻆不同,每个节点的下线列表也不⼀定相 同). ⑤. 此时A发现其他很多节点,也认为B为PFAIL,并且数⽬超过总集群个数的⼀半,那么A就会把B标 记成FAIL(相当于客观下线),并且把这个消息同步给其他节点(其他节点收到之后,也会把B标记成 FAIL).如果每个分片包含的槽位比较多,如果槽位个数想当,就可以认为是包含的key数量想当;

2024-04-17 15:59:05 796

原创 Redis的哨兵机制

Redis服务器需要按照可读可写的方式打开这个AOF文件,而这个文件对于root之外的用户只有读权限,因此serveice redis-server start启动的Redis服务器无法打开这个文件就启动失败(通过service redis-server start 启动的Redis服务器(主要是怕通过root启动Redis,权限太高,一旦Redis被黑客攻破,后果就比较严重)是通过一个Redis这样的用户来启动的)此时,就需要程序员/运维手工的恢复主节点(redis哨兵:自动的对挂了的主节点进行替换)

2024-04-13 18:27:37 1270

原创 Redis的事务

redis中实现事务,是引入了队列(每个客户端都有一个),开启事务的时候,此时客户端输入的命令,就会发送给服务器并且进入这个队列中(而不是立即就执行),当遇到“执行事务”命令的时候,此时就会把队列中的这些任务都按照顺序依次执行(redis的主线程中完成的,主线程会把事务中的操作都执行完,再处理别的客户端)答:MySQL的事务,再背后付出了很大的代价,空间是哪个,要花费更多的空间来存储更多的数据,时间上,也要有更答的执行开销,正是因为MySQL上述问题,才有redis上场的机会。

2024-04-03 15:35:48 338

原创 Redis 的图形化客户端(Java)

光服务器的外网IP还不够,因为6379端口是被云服务器的防火墙给保护起来的(不能被外面访问)(别人不能来访问,自己也不能访问)(虽然Tomcat的端口也开放了,但是Tomcat的8080这里的这个门的锁,不好撬,但是6379这个门的锁就特别好撬)(像是一个QQ的自定义客户端/王者荣耀的客户端/XXXX 不能自定义客户端,因为他们没有公开自己使用的自定义协议(如果非要定义的话也可以通过抓包/逆向手段,猜测QQ的应用层协议是什么样子的(全凭运气)))Simple String只能用来文本传输。

2024-03-30 11:30:43 431

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除