<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[2403_89229523的博客]]></title><description><![CDATA[]]></description><link>https://blog.csdn.net/2403_89229523</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; 2403_89229523]]></copyright><item><title><![CDATA[RabbitMQ---运维]]></title><link>https://blog.csdn.net/2403_89229523/article/details/167566204</link><guid>https://blog.csdn.net/2403_89229523/article/details/167566204</guid><author>2403_89229523</author><pubDate>Sun, 11 Oct 2026 12:24:26 +0800</pubDate><description><![CDATA[Raft是一种用于管理和维护分布式系统一致性的协议，它是一种共识算法。旨在实现高可用性和数据的持久性。Raft通过在节点间复制数据来保证分布式系统中的一致性，即使在节点故障的情况下也能保证数据不丢失。在分布式系统中，为了消除单点提高系统的可用性，通常会使用副本来进行容错，为了保证多个副本的一致性，就引入了共识算法，Raft就属于共识算法。共识算法允许多个分布式节点就某个值或一系列值达成一致性协议。即使在一些节点发生故障，网络分区或其他问题的情况下，共识算法也能保证系统的一致性和数据的可靠性。]]></description><category></category></item><item><title><![CDATA[RabbitMQ---应用问题]]></title><link>https://blog.csdn.net/2403_89229523/article/details/167489971</link><guid>https://blog.csdn.net/2403_89229523/article/details/167489971</guid><author>2403_89229523</author><pubDate>Sat, 10 Oct 2026 17:18:06 +0800</pubDate><description><![CDATA[消息的顺序性指的是消费者消费的消息和生产者发送消息的顺序是一致的。例如，生产者发送的消息顺序为msg1，msg2，那么消费者也要按照msg1和msg2的顺序进行消费。在不考虑消息丢失，网络故障等异常的情况下，如果只有一个生产者，一个消费者，那么是可以保证消息的顺序性的。但是，如果有多个生产者同时发送消息，那么就无法确定消息到达RabbitMQ Broker的前后顺序，也就无法验证消息的顺序性。以下情况会打破RabbitMQ的顺序性：①.多个消费者。]]></description><category></category></item><item><title><![CDATA[Redis---分布式锁]]></title><link>https://blog.csdn.net/2403_89229523/article/details/167484997</link><guid>https://blog.csdn.net/2403_89229523/article/details/167484997</guid><author>2403_89229523</author><pubDate>Sat, 10 Oct 2026 14:50:28 +0800</pubDate><description><![CDATA[在分布式系统中，会涉及到多个节点访问同一个公共资源的情况，此时就需要通过 “锁” 来做互斥控制，避免出现“线程安全”的问题。但是J，但是的场景下就无能为力了。事实上，本质上就是使用一个公共的服务器，来记录加锁状态。]]></description><category></category></item><item><title><![CDATA[Redis---缓存]]></title><link>https://blog.csdn.net/2403_89229523/article/details/167473546</link><guid>https://blog.csdn.net/2403_89229523/article/details/167473546</guid><author>2403_89229523</author><pubDate>Sat, 10 Oct 2026 13:27:03 +0800</pubDate><description><![CDATA[缓存，就是把一些常用的数据放到的地方，方便随时读取。注意：这个“访问速度更快”是一个相对的概念。对于硬件的访问速度，通常情况下，缓存是更快，但是空间上往往是不足的，所以，大部分的时候，缓存只能存放一些。]]></description><category></category></item><item><title><![CDATA[Redis---集群]]></title><link>https://blog.csdn.net/2403_89229523/article/details/167128277</link><guid>https://blog.csdn.net/2403_89229523/article/details/167128277</guid><author>2403_89229523</author><pubDate>Mon, 05 Oct 2026 20:35:17 +0800</pubDate><description><![CDATA[前面介绍哨兵的时候，我们发现，哨兵机制并不能帮助我们解决数据存储容量问题。为了解决这个问题，我们可以引入多组主节点/从节点，每一组主节点/从节点存储数据全集的一部分，从而构成了一个更大的整体，称为通过上图可以发现，每一个红框部分都保存1/3的数据，每部分可以称为是一个“分片”，如果数据量持续增加，那么只需要增加更多的分片来解决即可。]]></description><category></category></item><item><title><![CDATA[Redis---哨兵机制]]></title><link>https://blog.csdn.net/2403_89229523/article/details/167124210</link><guid>https://blog.csdn.net/2403_89229523/article/details/167124210</guid><author>2403_89229523</author><pubDate>Mon, 05 Oct 2026 15:59:09 +0800</pubDate><description><![CDATA[前面介绍了Redis的主从复制，但是主从复制存在一个问题，就是一旦主节点发生故障，那么需要我们进行主从切换，同时大量的客户端需要被通知切换到新的主节点上。下面，我们来介绍“”来解决这个问题。]]></description><category></category></item><item><title><![CDATA[Redis---主从复制]]></title><link>https://blog.csdn.net/2403_89229523/article/details/167082616</link><guid>https://blog.csdn.net/2403_89229523/article/details/167082616</guid><author>2403_89229523</author><pubDate>Sun, 04 Oct 2026 21:56:47 +0800</pubDate><description><![CDATA[psync命令，不需要我们手动执行。当建立好主从复制关系后，从节点会执行psync命令，从主节点这边拉取数据。语法：psync relicationid offset如果 relicationid为？并且offset为-1，则表示全量复制。如果都设置了具体的值，则尝试部分复制指的是主节点的复制id(replid)，当主节点重新启动，或者从节点晋升为主节点的时候，都会生成一个replicationid，每次启动时都会发生变化。]]></description><category></category></item><item><title><![CDATA[RabbitMQ---事务和消息分发]]></title><link>https://blog.csdn.net/2403_89229523/article/details/166897385</link><guid>https://blog.csdn.net/2403_89229523/article/details/166897385</guid><author>2403_89229523</author><pubDate>Wed, 30 Sep 2026 15:28:25 +0800</pubDate><description><![CDATA[RabbitMQ是基于AMQP协议实现的，该协议实现了事务机制。因此RabbitMQ也支持事务机制。Spring AMQP也提供了事务相关的操作。RabbitMQ事务允许开发者确保消息的发送和接收都是原子的。]]></description><category></category></item><item><title><![CDATA[RabbitMQ---死信队列和延迟队列 ]]></title><link>https://blog.csdn.net/2403_89229523/article/details/166893724</link><guid>https://blog.csdn.net/2403_89229523/article/details/166893724</guid><author>2403_89229523</author><pubDate>Wed, 30 Sep 2026 12:58:38 +0800</pubDate><description><![CDATA[1.死信是MQ中的一种特殊消息，它指的是那些无法被正常消费或者处理的消息，在RabbitMQ中，死信队列用于存储这些死信消息。事实上，死信队列本质上就是一个普通的队列，它需要配合死信交换机来使用，当消息成为死信后，会被转发到死信交换机，再路由到死信队列2.死信的来源主要有三种。①.当消息在队列中的存活时间超过了设定的TTL，此时消息就过期了，就会存放进死信队列。②.当消费者在处理消息的时候，因为某些原因导致拒绝处理该消息，此时如果不重新入队(requeue=false)的话，消息也会成为死信。]]></description><category></category></item><item><title><![CDATA[RabbitMQ---重试机制和TTL]]></title><link>https://blog.csdn.net/2403_89229523/article/details/166887656</link><guid>https://blog.csdn.net/2403_89229523/article/details/166887656</guid><author>2403_89229523</author><pubDate>Wed, 30 Sep 2026 11:05:59 +0800</pubDate><description><![CDATA[消息在传递的过程中，可能会遇到各种问题，导致消息处理失败。RabbitMQ提供了重试机制，允许消息在处理失败之后重新发送。但是如果是程序层面出现错误，那么重试多次也没有用，我们可以设置重试次数。]]></description><category></category></item><item><title><![CDATA[RabbitMQ---可靠性传输]]></title><link>https://blog.csdn.net/2403_89229523/article/details/166848611</link><guid>https://blog.csdn.net/2403_89229523/article/details/166848611</guid><author>2403_89229523</author><pubDate>Wed, 30 Sep 2026 01:01:07 +0800</pubDate><description><![CDATA[上图是RabbitMQ的消息传递图。从生产者发送消息到消费者消费消息，这个过程中，消息是可能会丢失的。那么我们就来看一下具体有哪几个场景会出现消息丢失的问题。①.生产者将消息发送到RabbitMQ可能会失败。如果是因为些网络问题，那么就会导致RabbitMQ无法收到生产者发来的消息。②.消息在交换机中，无法路由到指定的队列。当我们的代码或配置信息写错没导致交换机和队列之间无法正确的绑定，此时就会导致消息路由失败，那么队列就无法获取到交换机发来的消息。③.消息队列自身原因导致消息丢失。]]></description><category></category></item><item><title><![CDATA[RabbitMQ---SpringBoot整合RabbitMQ和具体案例]]></title><link>https://blog.csdn.net/2403_89229523/article/details/166841622</link><guid>https://blog.csdn.net/2403_89229523/article/details/166841622</guid><author>2403_89229523</author><pubDate>Tue, 29 Sep 2026 17:09:21 +0800</pubDate><description><![CDATA[这里我们使用的是这个注解，然后，在方法中传递了一个String类型的参数，这个String类型的参数，表示的就是消息的具体的内容。事实上，我们不光能够传递String类型的参数。我们还可以传递Message类型的参数，它指的是原始的消息体以及消息的属性，例如消息ID，内容，队列信息等等；我们还可以传递Channel类型的参数，它指的是RabbitMQ的通道对象，可以用于进行更高级的操作，这个在后面会介绍到。下面，我们来看具体的结果。]]></description><category></category></item><item><title><![CDATA[Redis---事务]]></title><link>https://blog.csdn.net/2403_89229523/article/details/166482591</link><guid>https://blog.csdn.net/2403_89229523/article/details/166482591</guid><author>2403_89229523</author><pubDate>Wed, 23 Sep 2026 15:49:48 +0800</pubDate><description><![CDATA[在前面介绍Mysql的时候也介绍到过事务的概念，例如ACID特性。但是Redis的事务相对于Mysql的事务来说，是比较简单的。：只做到了把多个包打包在一起，要么全都执行，要么全都不执行，不保证成功，如果事务中有若干个操作，存在有失败的，也不会进行回滚操作：不具备一致性。Redis没有约束，也没有回滚操作。事务执行过程中如果某个修改操作出现失败，就可能会导致不一致的情况。：不具备持久性。Redis为内存数据库，数据是存储在内存中的。虽然有持久化机制，但是和事务没有任何关系。：不涉及隔离性。]]></description><category></category></item><item><title><![CDATA[Redis---持久化]]></title><link>https://blog.csdn.net/2403_89229523/article/details/166445285</link><guid>https://blog.csdn.net/2403_89229523/article/details/166445285</guid><author>2403_89229523</author><pubDate>Wed, 23 Sep 2026 14:38:51 +0800</pubDate><description><![CDATA[RDB使用的是二进制的方式来组织数据，直接把数据读取到内存中，按照字节的格式取出来，放到结构体/对象中即可。但是RDB最大的问题就是不能实时的持久化保存数据，在两次生成快照之间，实时的数据可能会随着重启而丢失。]]></description><category></category></item><item><title><![CDATA[RabbitMQ---7种工作模式介绍]]></title><link>https://blog.csdn.net/2403_89229523/article/details/166364229</link><guid>https://blog.csdn.net/2403_89229523/article/details/166364229</guid><author>2403_89229523</author><pubDate>Tue, 22 Sep 2026 21:37:58 +0800</pubDate><description><![CDATA[RabbitMQ一共提供了来进行消息的传递，下面就来具体介绍每一种工作模式。]]></description><category></category></item><item><title><![CDATA[RabbitMQ介绍和快速使用]]></title><link>https://blog.csdn.net/2403_89229523/article/details/166134218</link><guid>https://blog.csdn.net/2403_89229523/article/details/166134218</guid><author>2403_89229523</author><pubDate>Tue, 22 Sep 2026 14:33:28 +0800</pubDate><description><![CDATA[MQ(Message Queue)，本质上是一个队列，具有先进先出的特性，队列中存放的内容是消息，包含字符串，JSON，内嵌对象等等。MQ多用于分布式系统之间进行通信。关于系统间的通信，大致有两种：同步通信，直接调用对方的服务，数据从一段发出后立即到达另一端异步通信，数据从一端发出后，先进入MQ进行来临时存储，当达到某种条件后，再从MQ发送给另一端。Rabbit MQ就是MQ的一种实现。]]></description><category></category></item><item><title><![CDATA[介绍Java的Redis客户端和Spring的Redis客户端]]></title><link>https://blog.csdn.net/2403_89229523/article/details/166129353</link><guid>https://blog.csdn.net/2403_89229523/article/details/166129353</guid><author>2403_89229523</author><pubDate>Sun, 20 Sep 2026 15:27:27 +0800</pubDate><description><![CDATA[在介绍客户端之前，我们先要了解一些基础知识。我们想要编写出一个自定义的Redis客户端，我们就需要知道“redis客户端”和“redis服务器”之间是通过什么协议来进行通信的。。我们可以通过查看官网得知，redis使用的协议是协议。已经有很多人实现了这套协议的构造和解析，我们只需要使用这些提供的库，就可以比较简单方便的完成和redis服务器通信的操作了。]]></description><category></category></item><item><title><![CDATA[渐进式遍历scan和数据库命令]]></title><link>https://blog.csdn.net/2403_89229523/article/details/165489600</link><guid>https://blog.csdn.net/2403_89229523/article/details/165489600</guid><author>2403_89229523</author><pubDate>Tue, 15 Sep 2026 20:24:47 +0800</pubDate><description><![CDATA[在前面介绍Redis中的命令的时候，我们都是用keys * 命令看数据库中所有的key。这趟尝试不太友好的，因为redis是单线程的，如果key太多，会把redis搞垮。为了避免这种情况，我们可以使用scan命令，进行渐进式的遍历当cursor为0的时候，表示遍历结束了，下次如果再遍历的话，就要从头开始遍历了渐进式遍历scan虽然解决了阻塞问题，但是如果在遍历期间键有所变化，例如增加，删除操作，可能导致遍历时键的重复遍历或者遗漏，这点无比在实际开发中考虑。]]></description><category></category></item><item><title><![CDATA[Redis---Zset]]></title><link>https://blog.csdn.net/2403_89229523/article/details/165482643</link><guid>https://blog.csdn.net/2403_89229523/article/details/165482643</guid><author>2403_89229523</author><pubDate>Tue, 15 Sep 2026 19:51:25 +0800</pubDate><description><![CDATA[Zset，有序集合。它保留了集合不能有重复成员的特点。。]]></description><category></category></item><item><title><![CDATA[SpringCloud---SkyWalking]]></title><link>https://blog.csdn.net/2403_89229523/article/details/165453166</link><guid>https://blog.csdn.net/2403_89229523/article/details/165453166</guid><author>2403_89229523</author><pubDate>Tue, 15 Sep 2026 14:59:24 +0800</pubDate><description><![CDATA[这里我们使用的是SkyWalking。为了方便观察，我们增加一个查询订单的接口ControllerService这里，我们手动实现一个慢SQLControllerServiceMapper此时，我们再来测试可以看到，会显示出慢的SQLSkyWalking默认会对接口提供追踪，我们也可以自定义追踪来对业务方法进行链路追踪。]]></description><category></category></item></channel></rss>