自定义博客皮肤VIP专享

*博客头图:

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

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

博客底图:

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

栏目图:

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

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

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

原创 【Git】-- 分支管理

本文介绍了Git分支管理的基本操作,包括查看、创建、切换、合并和删除分支。主要内容为:1)使用git branch查看当前分支;2)通过git branch 分支名创建新分支;3)使用git checkout切换分支;4)用git merge合并分支内容;5)通过git branch -d删除分支。重点演示了分支合并冲突的处理方法:当两个分支对同一文件修改后合并时会产生冲突,需要手动编辑冲突文件后提交。最后建议合并后删除多余分支,并介绍了git log --graph查看分支合并图示的方法。

2026-01-18 20:45:32 192

原创 【Git】-- 解决git branch -a打印已被删除的远程分支

查看远程分支的情况,我们可以发现,部分分支已经是stale状态。stale状态的分支就是已经被我们删除了的分支,但是我们查看分支时依旧能看到这些分支。此时,就可以看到这些stale状态的分支已经"被修剪"了。但是本地的分支依旧存在,使用。

2026-01-16 11:15:00 156

原创 【Git】-- 标签管理

本文介绍了Git标签管理的基本操作,包括创建标签、查看标签、给历史提交打标签、添加标签描述、删除标签以及推送标签到远程仓库。标签(tag)是对commit的标识,相比commit id更易记忆,便于版本回溯。通过示例命令展示了如何为最新提交打标签(v1.0)、查看.git目录中的标签存储结构、给特定历史提交打标签(v0.9)、添加带描述的标签(v0.8)等操作。最后说明了如何将单个标签(v1.0)或所有标签(--tags)推送到远程仓库。标签管理是Git版本控制中重要的里程碑标记方式。

2026-01-16 08:45:00 941

原创 【Git】-- 多人协作

本文介绍了Git多人协作的基本操作流程。主要内容包括:1.查看分支的命令(git branch -r/-a/-vv);2.演示同一分支下多人协作场景,展示开发者1和开发者2在dev分支上修改同一文件时如何处理冲突。详细步骤包括:创建本地分支并关联远程分支、修改文件、提交代码、解决冲突等关键操作,最后通过git pull和git push完成协作开发。文章强调了分支管理的重要性以及解决代码冲突的标准流程。

2026-01-15 11:16:29 783

原创 【RabbitMQ】-- 应用问题

本文探讨了RabbitMQ在实际应用中的三个核心问题:幂等性、顺序性和消息积压。幂等性方面,RabbitMQ支持"最多一次"和"最少一次"传输,需通过业务逻辑避免重复消费;顺序性保障建议采用单队列单消费者或分区消费策略,全局顺序性需结合业务实现;消息积压的解决方案包括提升消费者效率(如多实例、优化逻辑)、限制生产者速率(流量控制、限流)及优化服务器配置。RabbitMQ作为分布式系统,需权衡吞吐量与严格顺序性,实际应用中需根据场景选择策略。

2026-01-15 08:15:00 1670

原创 【RabbitMQ】-- 七种工作模式

RabbitMQ提供七种工作模式:1)简单模式(点对点);2)工作队列(多消费者共享消息);3)发布/订阅(广播消息);4)路由模式(按规则分发);5)通配符模式(灵活路由匹配);6)RPC模式(远程调用);7)发布确认模式(消息可靠性保证)。每种模式适用于不同场景,从简单消息传递到复杂RPC通信,满足各类消息处理需求。

2026-01-14 09:45:00 929

原创 【RabbitMQ】-- 高级特性

如果将所有的消息都设置为持久化,会严重的影响到Rabbit MQ的性能。写入磁盘的速度比写入内存的速度慢的很多。所以出于对性能的考虑,对于可靠性不是那么高的消息可以不采取持久化处理来提高整体的吞吐量。在选择是否要将消息持久化的时候,需要在可靠性和吞吐量之间做一个权衡。将交换机、队列、消息都设置成持久化之后就能百分百保证数据不丢失吗?并不是。1. 从消费者来说,如果在订阅消费队列时将autoAck参数设置为true,那么消费者接收到相关消息之后,还没来得及处理该消息就宕机了,这样也算是数据丢失。

2026-01-14 07:30:00 1453

原创 【git】-- 远程操作

我们会有并不想将某些文件提交到远程仓库中的需求。只需要在git工作区的根目录下创建一个。将本地仓库中的某一个分支下的内容,推送到远程仓库中的对应分支下。假设现在有其他的小伙伴进行了修改,我们需要拉取远程仓库中的内容。文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件了。如果本地分支名和远程分支名一致的话,可以省略。加了global表示是全局都生效。简化完之后,原来完整的命名依旧生效。origin:是远程仓库的默认名。,同样,如果一样,可以省略。

2026-01-13 09:30:00 1801

原创 【RabbitMQ】-- 核心概念

Channel是在Connection之上的抽象层,在Rabbit MQ中,一个TCP连接中,即一个Connection中可以有多个Channel,每个Channel都是独立的虚拟连接,消息的发送和接收都是基于Channel的。**Producer: ** 消息的生产者,是RabbitMQ Server的客户端,向RabbitMQ发送消息。**Conumer: ** 消息的消费者,是RabbitMQ Server的客户端,从RabbitMQ中接收消息。是RabbitMQ的内部对象,用于存储消息。

2026-01-13 08:30:00 1497

原创 【Git】-- Git基本操作

每add一次,在工作区中修改的内容会写入对象库中一个新的git对象中(Git会为每个被修改/新添加的文件创建一个blob对象,如果文件内容没有变化,就会重用已有的blob对象),同时暂存区中目录树的文件索引会被更新。该git目录是追踪管理git仓库的,如果对该目录进行修改的话,会直接将该git仓库破坏掉。暂存区/索引 和 版本库 中存放的不是具体的内容,而是一个个git对象的索引。:回退版本库中的内容,工作区和暂存区中的内容不进行回退。:回退版本库和暂存区中的内容,工作区中的内容不进行回退。

2026-01-12 09:41:41 1013

原创 【Git】-- Git安装 & 卸载(ubuntu)

【代码】【Git】-- Git安装 & 卸载--ubuntu。

2026-01-12 09:37:55 185

原创 【Redis】-- key的过期策略

Redis采用定期删除和惰性删除相结合的key过期策略。定期删除通过每次抽取部分key检查过期时间,避免阻塞主线程;惰性删除则在访问过期key时触发删除操作。这两种策略虽能减少内存占用,但仍存在过期key清理不及时的问题,因此Redis还提供了内存淘汰机制作为补充。整体设计在性能与资源消耗之间取得了平衡,确保了Redis的高效运行。

2026-01-08 22:15:48 436

原创 【Redis】-- 单线程模型

redis 只使用一个线程来处理所有的命令请求,微观上来讲,redis服务器是串行/顺序执行多个命令的。并不是说一个redis服务器内部真的只有一个线程,redis服务器内部的多个线程是在处理网络IO。redis并不会出现多线程中 两个线程尝试同时对一个变量进行自增操作,表面上是进行了两次自增,结果却是自增一次的结果 的问题。redis之所以使用单线程模型可以很好的工作,主要原因是在于redis的核心业务逻辑都是扁平快的,不太消耗cpu资源,自然就不太吃多核了。但是如果redis中的某个操作占用时间长,就会

2026-01-08 09:49:33 371

原创 【多线程】-- JUC的常见类

通过信号量可以限制系统中并发执行的线程个数,对于计算机而言管理的是有效的资源数,如果在资源有限的场景下,都可以使用信号量去处理。但是方法没有返回值;:表示这是一个函数式接口,接口中有且只有一个未实现的方法,也就意味着可以使用lambda表达式简化创建写法。在创建ReentrantLock类时设置该锁是否是一个公平锁,默认是非公平锁,传入true为公平锁。实现公平锁时,会有一个队列来组织排队的进程,获取锁的顺序就按照线程先来后到的顺序。信号量是用来表示“可用资源的个数的”,本质上是一个计数器。

2026-01-06 10:40:26 996

原创 【多线程】-- 死锁

线程在获取锁资源的时候,由于获取不到导致线程卡死,多个线程同时被阻塞,它们中的一个或者全部都在等待某个资源被释放。哲学家吃面的时候会拿起左右两边的筷子(一边一根),要求先那左边的,再拿右边的;如果桌子上的哲学家同时拿起自己左手边的筷子,这样大家就都拿不到右手边的筷子了,只能都阻塞等待,形成了死锁。只有在线程主动释放锁的时候,其他线程才有可能会获取到锁,别的线程不能直接抢。线程1等待线程2释放锁,线程2等待线程3释放锁,线程3等待线程1释放锁…就这样,锁A在等待锁B,锁B在等待锁A,循环等待造成死锁。

2026-01-05 19:04:07 511

原创 【多线程】-- synchronized原理

自旋锁:如果持有锁的线程能在很短时间内释放锁资源,那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态,它们只需要等一等(自旋,一直让CPU空转,比较浪费CPU资源,因此自旋并不会一直持续进行,而是达到一定的时间/重试次数就不再自旋了,就是所谓的“自适应”),等持有锁的线程释放锁后即可立即获取锁,这样就避免用户线程和内核的切换的消耗。一旦涉及到其他的线程竞争锁(根据锁对象的对象头中记录的信息,很容易姐可以识别当前线程是不是之前记录的线程),再取消偏向锁状态,进入轻量级锁状态。

2026-01-05 17:31:07 386

原创 多线程 -- CAS

CAS在执行时,预期值发生了两次变化,一次变成了另外一个值,一次又变了回来(A 被改成了 B,B又被改成了A)。

2026-01-04 12:38:11 506

原创 多线程 -- 常见的锁策略

轻量级锁:加锁的过程比较简单,用到的资源比较少,典型的就是用户态的一些操作(Java层面就可以加锁)。优缺点:内核态的操作,会生成对应的加锁指令,要等待被唤醒,在等待的过程中会释放CPU资源。写锁:写操作的时候加写锁(排它锁),只允许一个写锁执行任务,和其他锁是冲突的。重量级锁:加锁的过程比较复杂,用到的资源比较多,典型的就是内核态的一些操作。悲观锁是无论任何时候都加锁,消耗的资源多,所以可以说悲观锁是一种重量级锁。乐观锁是能不加锁就不加锁,消耗的资源少,所以说乐观锁是一种轻量级锁。

2026-01-03 19:35:37 413

原创 【JavaEE初阶】-- 网络原理(网络层)

街道的这个路由器最终是连接到了运营商的网络服务,运营商会提供一个公网IP,给到连接它的路由器,此时街道级别的路由器就可以通过公网IP访问网络上的任何主机了。是分⽚相对于原始IP报⽂开始处的偏移. 其实就是在表⽰当前分⽚在原报⽂中处在哪个位置. 实际偏移的字节数是这个值 * 8 得到的. 因此, 除了最后⼀个报⽂之外, 其他报⽂的⻓度必须是8的整数倍(否则报⽂就不连续了).不同的网络管理的网络范围是不同的,广域网是全世界,局域网只是一部分,一个网络内的IP地址不能重复,不管是公网还是局域网;

2025-12-01 20:52:51 576

原创 【JavaEE初阶】-- 网络原理(传输层)

定义一个分隔符来界定消息之间的边界如果是换行符:\r\n你好啊,一会儿去吃火锅\r\n行不行呀\r\n是不是在忙\r\nadflsjflsfj;lk;ds\r\n系统会回收进程的资源,包括文件描述符表,回收时相当于调用socket的close(),触发FIN操作。

2025-12-01 13:47:35 707

原创 【JavaEE】-- 网络编程套接字

网络编程是指网络上的主机通过不同的进程,以编程的方式实现网络通信(或称为网络数据传输)。当然,只需要满足进程不同就行,即便是在同一个主机,只要是不同进程基于网络来传输数据也属于网络编程。操作系统为用用提供了一组实现传输协议的接口–Socket API。JDK为系统API进行了封装,Java程序员使用JDK提供的API。ServerSocket是创建TCP服务端Socket的API.主要用于服务器端,创建一个TCP服务。方法签名方法说明创建⼀个服务端流套接字Socket,并绑定到指定端⼝方法签名。

2025-11-24 08:43:30 1014

原创 【JavaEE】-- Spring Web MVC入门

该注解是用来注册接口的的。路由映射:当用户访问一个URL时,将用户的请求对应到程序中的某个类的某个方法的过程。

2025-11-17 08:32:21 536

原创 【JavaEE】-- IoC & DI

Spring MVC 和 Spring Boot 都属于Spring ,Spring MVC是基于Spring的一个MVC框架,而Spring Boot 是基于Spring 的一套快速开发整合包。这三者专注的领域不同,解决的问题也不一样。总的来说,Spring就像一个大家族,有众多衍生产品,但他们的基础都是Spring。@Bean@Bean定义多个对象的时候我们就不能通过类型来获取对象了,需要使用Bean的名称来获取。IoC: 控制反转。也就是说Spring是一个“控制反转”的容器。

2025-11-13 19:56:54 972 1

原创 为什么封装第三方组件

本文阐述了封装第三方组件的五大优势:1)通过抽象层实现解耦,降低第三方变更对业务代码的影响;2)统一接口简化调用,屏蔽底层差异;3)封装复杂逻辑提升扩展性;4)规范化错误处理机制;5)通过注释文档增强代码可读性和团队协作效率。同时建议保持原始返回值以便调试。这种封装模式能显著提升项目的可维护性和开发效率。

2025-11-13 12:57:37 231

原创 【JavaEE进阶】-- 加密算法

在数据库中通常存放一些用户的隐私信息,这些隐私信息通常不可以将其明文存放:1. 代码角度:代码bug漏洞可能会导致数据泄漏。2. 管理角度:管理员有权限查看数据表的数据,有可能会直接泄漏表数据。

2025-11-11 21:39:40 401

原创 【Spring Cloud 微服务】-- 服务拆分原则

以上面的电商系统为例,每一个微服务应该有自己的存储,配置,在进行开发,构建,部署,运行和测试时,并不需要过多关注其他微服务的状态和数据。在微服务架构中,一个微服务也应该只负责一个功能或业务领域,每个服务应该有清晰的定义和边界,只关注自己的特定业务领域。服务自治是指每个微服务都应该具备高度自治的能力,即每个服务要能做到独立开发,独立测试,独立构建,独立部署,独立运行.如果一些场景确实无法避免循环依赖或者双向依赖,可以考虑使用消息队列等其他方式实现。微服务之间需要做到单向依赖,严禁循环依赖,双向依赖。

2025-11-07 14:09:02 261

原创 【Spring Cloud微服务】-- DependencyManagement 和 Dependencies

如果子项目中没有对依赖指定版本,会从父项目中读取版本;如果子项目中指定了版本,就会使用子项目中指定的版本。只是对依赖进了声明,并没有实现jar包的引入,如果子项目需要用到相关依赖,需要进行显式声明。将所依赖的jar直接加到项目中,子项目也会继承该依赖。父工程的打包方式应该是pom,不是jar。

2025-11-07 12:29:50 301

原创 【JavaEE】-- Cookie &&Session

HTTP协议自身是属于“无状态”协议。无状态:默认情况下HTTP协议的客户端与服务器之间的这次通信,和下次通信之间没有直接关系。但是在实际开发中,我们很多时候是需要知道请求之间的关联关系的,比如:保存登陆状态。上图中的“令牌”,通常就存储在Cookie字段中。

2025-11-04 21:04:19 582

原创 【JavaEE】-- B/S && C/S 架构

1. 必须要安装客户端程序。不同的应用需要安装不同的客户端程序。2. 大部分业务都可以在客户端完成,包括客户端可以直接操作数据库等服务。充分利用本地的计算机资源。3. 由于客户端承担了更多的业务,所以其响应速度快。

2025-11-04 16:38:34 121

原创 【Redis】-- 分布式锁

在一个分布式系统中,也会涉及到多个节点访问统一公共资源的情况。此时就需要通过锁来做互斥控制,避免出现类似于“线程安全”的问题。而Java的synchronized或者C++的std::mutex,这样的锁都是只能在当前进程中生效,在分布式锁的这种多个进程多个主机之间就很难产生制约,分布式系统中多个进程之间的执行顺序也是不确定的。此时就需要分布式锁。

2025-09-17 17:45:46 1038 1

原创 【Redis】-- 缓存

缓存是一个相对的概念,访问速度快的设备可以作为访问速度慢的设备的缓存。CPU寄存器 > 内存 > 硬盘 > 网络。缓存速度虽然快,但是空间小,缓存之所以有意义,是由于二八定律(20%的数据能够应对80%的请求)。

2025-09-17 16:07:44 821

原创 【Redis】--集群

节点之间通过心跳包通信,心跳包中包含了该节点持有哪些slots.这个是使⽤位图这样的数据结构表示的. 表示 16384 (16k) 个 slots, 需要的位图大小是 2KB. 如果给定的 slots 数更多了, 比如 65536 个了, 此时就需要消耗更多的空间, 8 KB 位图表示了. 8 KB, 对于内存来说不算什么, 但是在频繁的网络心跳包中, 还是⼀个不小的开销的.

2025-09-16 19:49:44 909

原创 【Redis】-- 哨兵

再控制其他节点,执行slave of,让这些其他节点,作为新的主节点的从节点。多个哨兵进行投票,一个哨兵节点一票,多个Redis都认为这个Redis服务节点挂了(达到了法定票数)就认为这个Redis服务节点挂了。哨兵节点通过心跳包,判断Redis服务器是否正在正常工作,如果心跳包没有如期而至,就认为该Redis节点主观下线了。哨兵节点会自动的通知客户端程序,告知新的主节点是谁,并且后续客户端再进行写操作,就会针对新的主节点来进行操作。哨兵节点不负责存储数据,只是对其他的redis服务节点起到监控的作用。

2025-09-16 12:44:13 342

原创 【Redis】-- 主从复制

主节点将从生成RDB到接收完成期间主节点执行的写命令,写入到复制缓冲区中,等从节点保存完RDB文件之后,主节点再将缓冲区中的数据不发给从节点,不发的文件仍按以rdb的二进制格式追加写入到收到的rdb文件中,保持主从一致性。主节点可以进行读操作和写操作。本来在主节点上保存一堆数据,引入从节点之后,就是要把主节点上的数据复制到从节点上,后续如果主节点的数据有修改,也会同步到从节点上。主节点只需要同步部分从节点,剩下的节点交给从节点慢慢的去向从节点的从节点进行同步,这样主节点就不需要那么高的网络带宽了。

2025-09-15 20:16:51 1159

原创 【Redis】-- 事务

Redis的事务是否保证了原子性,这件事是存在争议的。原子性原本的含义:把多个操作打包在一起,要么 全部执行,要么全都不执行。Redis是做到了上述的原子性的含义的,但是Redis事务中的若干个操作,如果存在有操作失败,不会有回滚操作,错就错了。

2025-09-14 10:09:07 647

原创 【Redis】-- 持久化

Redis提供了两种持久化机制:RDB和AOF。RDB通过定期生成数据快照实现持久化,支持手动(save/bgsave)和自动触发,但存在数据丢失风险。AOF通过记录所有写操作命令实现实时备份,包含缓冲区写入、文件重写等流程,能更好保证数据完整性但恢复速度较慢。Redis还支持混合持久化,在AOF重写时将内存数据以RDB格式写入文件头,结合了两种机制的优势。RDB适合备份和快速恢复,AOF提供更高可靠性,混合模式则平衡了性能和数据安全性。持久化机制的选择需要根据业务需求和数据重要性进行权衡。

2025-09-13 16:31:32 687

原创 【JavaEE初阶】-- JVM

当我们创建一个类时,先从应用程序加载器开始向上转发,一直转发到启动类加载器。类启动加载器在自己的路径下找,看有没有要创建的这个类,有则加载,没有就继续向下转发到扩展加载器。扩展加载器在自己的路径下找,看有没有要创建的这个类,有则加载,没有就继续向下转发到应用程序加载器。应用程序加载器在自己的路径中找到类并加载。

2025-09-12 20:54:39 1173

原创 【Spring Cloud】-- SpringBoot集成redis报错:Unable to connect to 47.93.212.12/<unresolved>:6379

配置隧道之后需要重新连接云服务器

2025-09-09 17:25:04 178

原创 【Spring Cloud】-- Nacos

如果设置了权重时候,发现该权重配置并没有生效,原因时我们当前使用的应用框架(Spring Cloud LoadBalancer)有自身的负载均衡配置方法,并没有使用nacos的权重属性进行负载均衡。由于成本和跨区访问是通过网络进行传输的,会出现延迟的现象,所以当微服务进行访问时,是尽量访问同机房的实例的,如果同机房的实例不可用时,才会去访问其他机房的实例。环境隔离就是这几个环境之间是不能相互通信的,Nacos提供了namespace来实现环境的隔离,不同的namespace的服务之间是不可见的。

2025-08-07 00:27:23 1335

原创 【Spring Cloud】-- 注册中心

服务提供者会在启动时向注册中心注册服务,并且会定时向注册中心发送心跳汇报存活状态。服务消费者会从注册中心中获取服务提供者提供的地址,并通过获取的地址调用服务提供者的接口。服务发现就是给服务消费者提供一个可用的服务列表。

2025-08-05 23:56:52 378

空空如也

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

TA关注的人

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