<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[hyldzbg的博客]]></title><description><![CDATA[]]></description><link>https://blog.csdn.net/hyldzbg</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; hyldzbg]]></copyright><item><title><![CDATA[selenium自动化测试]]></title><link>https://blog.csdn.net/hyldzbg/article/details/156095048</link><guid>https://blog.csdn.net/hyldzbg/article/details/156095048</guid><author>hyldzbg</author><pubDate>Sun, 08 Mar 2026 16:08:06 +0800</pubDate><description><![CDATA[Web 自动化测试的操作核心是能够找到页面对应的元素，然后才能对元素进行具体的操作。常见的元素定位方式非常多，如idclassnametagnamexpath。常用的主要由和xpath。]]></description><category></category></item><item><title><![CDATA[测试方法篇]]></title><link>https://blog.csdn.net/hyldzbg/article/details/156086329</link><guid>https://blog.csdn.net/hyldzbg/article/details/156086329</guid><author>hyldzbg</author><pubDate>Fri, 19 Dec 2025 19:13:19 +0800</pubDate><description><![CDATA[不同的版本(软件,系统),浏览器的兼容性(同一个浏览器上不同版本打开我写的系统)不同浏览器(不同浏览器上打开我的系统),(比如谷歌浏览器是否能在苹果,联想,win10,win11...上打开),还有数据的兼容性(场景 : 可以进行手机号注册,可以进行微信注册,邮箱注册...邮箱注册之后,个人手机号是否可以登录)常见的测试方法有黑盒测试、白盒测试和灰盒测试。但是，灰盒测试没有白盒测试详细和完整，黑盒测试是覆盖产品范围最广的测试，因此灰盒测试基本是不能够替代黑盒测试，否则需要很大的代价，设计非常多的用例。]]></description><category></category></item><item><title><![CDATA[测试基础篇]]></title><link>https://blog.csdn.net/hyldzbg/article/details/156083853</link><guid>https://blog.csdn.net/hyldzbg/article/details/156083853</guid><author>hyldzbg</author><pubDate>Fri, 19 Dec 2025 19:12:26 +0800</pubDate><description><![CDATA[我个人对测试的理解就是，软件测试就是验证软件产品特性是否满足用户的需求。]]></description><category></category></item><item><title><![CDATA[RabbitMQ:应用问题]]></title><link>https://blog.csdn.net/hyldzbg/article/details/149445463</link><guid>https://blog.csdn.net/hyldzbg/article/details/149445463</guid><author>hyldzbg</author><pubDate>Sun, 23 Nov 2025 20:00:57 +0800</pubDate><description><![CDATA[不过其实在很多场景下是不需要保证消息的顺序性的，除非是一些对顺序性要求严格的操作，比如银行转帐的顺序，或者同一用户短时间内进行大量的个人信息修改操作，这种就要求以最后一次修改为准。幂等性关注的是对资源的影响，而非返回结果。当有消息成功发送到MQ后，此时因为网络问题生产者宕机，导致MQ对生产者的应答失败，如果之后生产者意识到消息发送失败并且尝试重新发送，那么消费者就会收到两条相同的消息了并且ID一致。MQ的幂等性是指，同一条消息被多次消费，对系统的影响是相同的，一般MQ的消息传输分为三个层级。]]></description><category></category></item><item><title><![CDATA[JAVA微服务脚手架项目详解(四)]]></title><link>https://blog.csdn.net/hyldzbg/article/details/155076275</link><guid>https://blog.csdn.net/hyldzbg/article/details/155076275</guid><author>hyldzbg</author><pubDate>Sat, 22 Nov 2025 15:31:59 +0800</pubDate><description><![CDATA[就好比我们的身份证，之所以能标识一个人的身份，是因为它不能被篡改，而不是因为内容加密。在本项目中，C端用户的CRUD操作主要放在fw-admin模块下，而fw-portal里主要写一些用户行为的接口，比如登录注册，退出等用户操作的功能。还有一点需要注意，在涉及到一些敏感的信息时，比如用户电话或者账号密码之类的，肯定是不能明文传输的，所以我们就需要对这些字段进行加密。字典服务：通常是管理员在后台配置好，用户去读取，可以方便对⼀些内容进行分类查询，⼀般会是名词。AuthFilter 网关拦截器。]]></description><category></category></item><item><title><![CDATA[JAVA微服务脚手架项目详解(三)]]></title><link>https://blog.csdn.net/hyldzbg/article/details/155076256</link><guid>https://blog.csdn.net/hyldzbg/article/details/155076256</guid><author>hyldzbg</author><pubDate>Sat, 22 Nov 2025 15:31:16 +0800</pubDate><description><![CDATA[与传统文件系统（如块存储或文件存储）不同，对象存储将数据存储为独立的“对象”，每个对象包含数据本身、元数据以及唯一的全局标识符（如对象ID），结合元数据和唯一的标识符可以进行数据检索。对象存储通常用于存储大量非结构化数据，如图片、视频、日志文件、备份数据等。这种方式提供一个独立的文件微服务，文件微服务向业务微服务提供统一的上传、下载、查看接口，不同的业务微服务调用方式相同，并且屏蔽了底层调用OSS服务（或其他厂商所提供对象存储服务的）的接口，即使以后迁移OSS服务商，业务微服务层面的系统也不需要变动。]]></description><category></category></item><item><title><![CDATA[JAVA微服务脚手架项目详解(二)]]></title><link>https://blog.csdn.net/hyldzbg/article/details/155076224</link><guid>https://blog.csdn.net/hyldzbg/article/details/155076224</guid><author>hyldzbg</author><pubDate>Sat, 22 Nov 2025 15:30:32 +0800</pubDate><description><![CDATA[/ 问题3：A线程释放了B线程的锁，可能当t1线程获取锁proKey后这种执行减库操作时卡住了，然后时间超过了锁过期时间，此时t2线程也过来成功拿到锁，结果还没执行完任务，t1线程恢复了并执行了finally里的解锁操作，就把t2线程的锁给解开了。redis相关配置，这里要对redisTemplate进行序列化配置，不然redisTemplate会以16进制存储key-value，虽然对于redisTemplate来说可以认识，但是对于开发者来说并不友好而且内存占用较大，所以这里要进行序列化配置。]]></description><category></category></item><item><title><![CDATA[RabbitMQ:持久化和发送方确认]]></title><link>https://blog.csdn.net/hyldzbg/article/details/149348538</link><guid>https://blog.csdn.net/hyldzbg/article/details/149348538</guid><author>hyldzbg</author><pubDate>Sat, 22 Nov 2025 13:55:44 +0800</pubDate><description><![CDATA[一个快递，从商家发到买家手里，这个快递在运输途中任何时候都可能出问题，比如在运输路上可能会搞丢，或者在对应分拣栈站也可能被搞丢，就像是消息一样，可能在传输途中丢失，也可能在交换机或队列丢失，所以我们需要对消息进行持久化处理，来保证消息的持久性。RabbitMQ的持久化分为三个部分，交换机持久化，队列持久化，消息持久化。]]></description><category></category></item><item><title><![CDATA[JAVA泛型擦除问题]]></title><link>https://blog.csdn.net/hyldzbg/article/details/155076186</link><guid>https://blog.csdn.net/hyldzbg/article/details/155076186</guid><author>hyldzbg</author><pubDate>Sat, 22 Nov 2025 13:54:50 +0800</pubDate><description><![CDATA[在java中的泛型是伪泛型，在编译器编译泛型代码时，会移除泛型类型参数的相关信息，使得字节码中不包含泛型类型信息，让java泛型在运行时表现为原始类型。比如List<Object>和List<String>，对于JVM来说，都是list，里面的Object和String类型信息，JVM是看不到的。下面举个例子。这段代码的结果为true，这里定义了两个ArrayList，但是他们的类型参数信息不一样，一个是String，一个是Integer。]]></description><category></category></item><item><title><![CDATA[RabbitMQ:消息确认]]></title><link>https://blog.csdn.net/hyldzbg/article/details/149308876</link><guid>https://blog.csdn.net/hyldzbg/article/details/149308876</guid><author>hyldzbg</author><pubDate>Thu, 20 Nov 2025 15:54:55 +0800</pubDate><description><![CDATA[消息的唯一标识，它是一个单调递增的64位长整型值。手动确认时可以将队列中的信息分为两个部分，一时等待发送给消费者的，二是以及发送，正在等待确认的，如果RabbitMQ一直没有收到确认信号，并且消费这条消息的消费者已经断开链接了，那么RabbitMQ就会重新安排这条消息入队列，等待下一个消费者。在RabbitMQ的管理界面里也可以看到，这里的get message其实也可以看作是一个消费者，从队列中拿取数据，自上而下分别是，不确认拿完后放回队列，自动确认拿完后不放会队列，拒绝并重新入队，拒绝但不重新入队。]]></description><category></category></item><item><title><![CDATA[JAVA微服务脚手架项目详解(一)]]></title><link>https://blog.csdn.net/hyldzbg/article/details/155068245</link><guid>https://blog.csdn.net/hyldzbg/article/details/155068245</guid><author>hyldzbg</author><pubDate>Thu, 20 Nov 2025 15:52:51 +0800</pubDate><description><![CDATA[为了满足业务需求，Java提供了一些内置的异常类，但是它们并不一定能够满足我们的具体业务需求，所以我们需要自定义异常类。核心设计给出一份自定义异常模板，项目可按自身需求扩展更多异常类型。继承自 RuntimeException，异常一般在运行阶段抛出。核心字段：状态码 + 提示信息，具体可随项目调整。提供异常捕获：微服务和网关全局异常处理中应该应该分别提供自定义异常的捕获和处理三种构造方式：传入标准状态码，自动取用对应的 code 与 msg。仅传入提示信息，code 使用默认状态码。]]></description><category></category></item><item><title><![CDATA[SpringCloud:Eureka和负载均衡]]></title><link>https://blog.csdn.net/hyldzbg/article/details/149572279</link><guid>https://blog.csdn.net/hyldzbg/article/details/149572279</guid><author>hyldzbg</author><pubDate>Sat, 15 Nov 2025 20:31:36 +0800</pubDate><description><![CDATA[在最初的架构体系中，集群的概念还不那么流行，且机器数量也比较少，此时直接使用 DNS + Nginx 就可以满足几乎所有服务的发现。相关的注册信息直接配置在 Nginx。但是随着微服务的流行与流量的激增，机器规模逐渐变大，并且机器会有频繁的上下线行为，这种时候需要运维手动地去维护这个配置信息是一个很麻烦的操作。所以开发者们开始希望有这么一个东西，它能维护一个服务列表，哪个机器上线了，哪个机器宕机了，这些信息都会自动更新到服务列表上，客户端拿到这个列表，直接进行服务调用即可。这个就是注册中心。注册中心主要有三]]></description><category></category></item><item><title><![CDATA[Rabbit MQ:概述]]></title><link>https://blog.csdn.net/hyldzbg/article/details/149298209</link><guid>https://blog.csdn.net/hyldzbg/article/details/149298209</guid><author>hyldzbg</author><pubDate>Sat, 15 Nov 2025 20:30:32 +0800</pubDate><description><![CDATA[MQ就是Message Queue的缩写，本质上就是一个队列只不过队列里存放的元素是一些消息而已，消息的类型可以很简单比如一个数字或者一个字符串，也可以是一些内嵌对象等等。MQ一般用于分布式系统之间的通信数据直接由一端到达另一端数据由一端发送到一个容器存储起来，之后达到某个条件后再由这个容器发送给另外另一端。]]></description><category></category></item><item><title><![CDATA[深入探讨redis：分布式锁]]></title><link>https://blog.csdn.net/hyldzbg/article/details/147673318</link><guid>https://blog.csdn.net/hyldzbg/article/details/147673318</guid><author>hyldzbg</author><pubDate>Mon, 10 Nov 2025 16:15:24 +0800</pubDate><description><![CDATA[分布式锁，也就是在分布式系统中用的锁，在分布式系统中也会遇见像多个节点访问同一个公共资源的情况，随机产生类似线程安全资源这样的问题，和java中的synchronized以及C++中的std::mutex这种锁不同的是，分布式系统中竞争的公共资源的从线程升级为进程。]]></description><category></category></item><item><title><![CDATA[深入探讨redis：缓存]]></title><link>https://blog.csdn.net/hyldzbg/article/details/147669371</link><guid>https://blog.csdn.net/hyldzbg/article/details/147669371</guid><author>hyldzbg</author><pubDate>Mon, 02 Jun 2025 11:25:06 +0800</pubDate><description><![CDATA[缓存的核新思路就是把⼀些常用的数据放到触手可及(访问速度更快)的地方，方便随时读取。比如我们一般都把钱存在银行，并且会拿出一部分出来放在自己的钱包里用来日常开销，那么这个钱包就相当于银行的缓存，我们为了不每次用钱的时候都去银行取，所以用个钱包在钱包里放一部分钱要使用的时候直接从钱包里拿(不考虑电子支付)。对计算机来说，速度往往和存储空间是成反比的，访问速度越快存储空间越小，redis是读内存的访问速度要比Mysql快但空间也比mysql小很多，所以一般缓存里只会放一些(热点数据)会频繁访问的数据。]]></description><category></category></item><item><title><![CDATA[深入探讨redis：万字讲解集群]]></title><link>https://blog.csdn.net/hyldzbg/article/details/147539579</link><guid>https://blog.csdn.net/hyldzbg/article/details/147539579</guid><author>hyldzbg</author><pubDate>Sun, 01 Jun 2025 10:06:36 +0800</pubDate><description><![CDATA[首先做完准备工作后，生成每个redis节点的配置文件接着使用docker创建出11个redis节点，并启动容器最后使用redis-cli 执行构建集群命令。]]></description><category></category></item><item><title><![CDATA[深入探讨redis：主从复制]]></title><link>https://blog.csdn.net/hyldzbg/article/details/146120008</link><guid>https://blog.csdn.net/hyldzbg/article/details/146120008</guid><author>hyldzbg</author><pubDate>Sat, 31 May 2025 14:41:11 +0800</pubDate><description><![CDATA[在若干个redis节点(物理服务器)中，有的节点被作为主节点，有的则作为从节点分别部署在redis-server进程中，从节点上的数据跟随主节点上的数据变化并保持一致。也就是说如果主节点上保存了一些数据，那么就要将这些数据复制一份出来给从节点，当主节点对这些数据有修改时，从节点也要进行对应的修改，并且从节点上的数据是不能主动或直接修改的，只能读取数据。//从节点也可以看作是主节点的副本。]]></description><category></category></item><item><title><![CDATA[深入浅出：Spring IOC&DI]]></title><link>https://blog.csdn.net/hyldzbg/article/details/147775806</link><guid>https://blog.csdn.net/hyldzbg/article/details/147775806</guid><author>hyldzbg</author><pubDate>Fri, 30 May 2025 17:44:42 +0800</pubDate><description><![CDATA[IOC(Inversion of Control)，是一种设计思想，在之前的里就在类上添加@RestController和@Controller注解就是使用了IOC，这两个注解IOC的意思就是，在之前我们的面向对象编程中，我们要使用一个对象需要自己new出来，但是现在使用IOC思想后，我们创建对象的时候，是通过容器来创建的，。控制反转这个词听起来很高大上其实就是一个很简单的思想，比如之前我们需要什么工具都要自己去找，这个工具可能在车库可能在卧室。]]></description><category></category></item><item><title><![CDATA[深入探讨redis：哨兵模式]]></title><link>https://blog.csdn.net/hyldzbg/article/details/146315697</link><guid>https://blog.csdn.net/hyldzbg/article/details/146315697</guid><author>hyldzbg</author><pubDate>Tue, 20 May 2025 16:30:14 +0800</pubDate><description><![CDATA[本文介绍了Redis主从复制和哨兵机制的基本概念、手动与自动恢复主从复制的方法，以及使用Docker搭建哨兵环境的步骤。主从复制在主节点故障时，从节点无法自动接替主节点功能，需手动恢复。哨兵机制通过监控Redis节点，自动在主节点故障时选举新的主节点，确保系统的高可用性。文章详细描述了使用Docker和Docker-compose编排主从节点和哨兵节点的过程，包括配置文件的编写和容器的启动。此外，还介绍了哨兵节点重新选举主节点的流程，包括主观下线、客观下线、选举leader和选择新主节点的步骤。最后，文章强]]></description><category></category></item><item><title><![CDATA[一篇解决Redis：持久化机制]]></title><link>https://blog.csdn.net/hyldzbg/article/details/145949263</link><guid>https://blog.csdn.net/hyldzbg/article/details/145949263</guid><author>hyldzbg</author><pubDate>Wed, 14 May 2025 23:01:40 +0800</pubDate><description><![CDATA[Redis持久化方案主要包括RDB（Redis DataBase）和AOF（Append-Only File）两种方式。RDB通过定期生成数据快照进行持久化，适合备份和全量复制，但可能因未及时保存导致数据丢失。AOF则记录每次写操作，通过重写机制优化文件大小，提高数据恢复效率。AOF支持多种缓冲区刷新策略，以平衡数据可靠性和性能。此外，Redis还引入了混合持久化，结合RDB和AOF的优点，以二进制格式存储快照，同时追加文本格式的写操作，进一步提升性能和可靠性。]]></description><category></category></item></channel></rss>