<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[Martin_rui的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/Martin_rui</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; Martin_rui]]></copyright><item><title><![CDATA[kafka专题-1、集群安装]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/147044206</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/147044206</guid><author>Martin_rui</author><pubDate>Mon, 07 Apr 2025 14:59:58 +0800</pubDate><description><![CDATA[1、需要3个服务器节点，并且节点都安装了java82、组件版本。]]></description><category></category></item><item><title><![CDATA[DDD领域驱动模型]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/140200636</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/140200636</guid><author>Martin_rui</author><pubDate>Fri, 05 Jul 2024 10:15:20 +0800</pubDate><description><![CDATA[消除信息不对称；常规MVC三层架构中自底向上的设计方式做一个反转，以业务为主导，自顶向下的进行业务领域划分；将大的业务需求进行拆分，分而治之。]]></description><category></category></item><item><title><![CDATA[Reactor模型详解]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/140200445</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/140200445</guid><author>Martin_rui</author><pubDate>Fri, 05 Jul 2024 10:09:39 +0800</pubDate><description><![CDATA[针对传统阻塞 I/O 服务模型的 2 个缺点，比较常见的有如下解决方案：1）基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理；2）基于线程池复用线程资源：不必再为每个连接创建线程，将连接完成后的业务处理任务分配给线程进行处理，一个线程可以处理多个连接的业务。]]></description><category></category></item><item><title><![CDATA[RocketMq消息可靠性投递]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/139812682</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/139812682</guid><author>Martin_rui</author><pubDate>Wed, 19 Jun 2024 20:54:12 +0800</pubDate><description><![CDATA[达到最⼤重试次数后，若消费依然失败，则表明消费者在正常情况下⽆法正确地消费该消息，此时，消息队列 RocketMQ 不会⽴刻将消息丢弃，⽽是将其发送到该消费者对应的死信队列中。消息消费的场景下，消息已投递到消费者并完成业务处理，当客户端给服务端反馈应答的时候⽹络闪断。⼴播消费模式不提供失败重试特性，即消费失败后，失败消息不再重试，继续消费新的消息。⼀条消息进⼊死信队列，意味着某些因素导致消费者⽆法正常消费该消息，因此，通常需要对其进⾏特殊处理。#发送同步消息失败时，重试次数，默认是 2。]]></description><category></category></item><item><title><![CDATA[RocketMQ⾼可⽤和负载均衡]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/139812474</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/139812474</guid><author>Martin_rui</author><pubDate>Wed, 19 Jun 2024 20:43:44 +0800</pubDate><description><![CDATA[Master 也可以部署多个。在创建 Topic 的时候，把 Topic 的多个 Message Queue 创建在多个 Broker 组上（相同 Broker 名称，不同 brokerId 的机器组成⼀个 Broker 组），这样当⼀个Broker 组的 Master不可⽤后，其他组的 Master 仍然可⽤， Producer 仍然可以发送消息。具体流程是，消息写⼊内存的 PAGECACHE 后，⽴刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执⾏完成后唤醒等待的线程，返回消息写成功的状态。]]></description><category></category></item><item><title><![CDATA[RocketMQ消息存储]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/139812310</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/139812310</guid><author>Martin_rui</author><pubDate>Wed, 19 Jun 2024 20:33:21 +0800</pubDate><description><![CDATA[（1）消息⽣产与消息消费相互分离，Producer端发送消息最终写⼊的是CommitLog（消息存储的⽇志数据⽂件），Consumer端先从ConsumeQueue（消息逻辑队列）读取持久化消息的起始物理位置偏移量offset、⼤⼩size和消息Tag的HashCode值，随后再从CommitLog中进⾏读取待消费消息的实体内容；⼀般来说依赖的外部系统越多，也会使得本身的设计越复杂，所以采⽤⽂件系统作为消息存储的⽅式，更贴近消息中间件本身的定义。1073741824。]]></description><category></category></item><item><title><![CDATA[Rocketmq消息类型]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/139812069</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/139812069</guid><author>Martin_rui</author><pubDate>Wed, 19 Jun 2024 20:19:32 +0800</pubDate><description><![CDATA[Message partOrderMsg = new Message("part_order_topic_test", "order_" + orderId, "KEY_" + orderId, ("局部顺序消息处理_" + orderId + ";Message message = new Message("GLOBAL_ORDER_TOPIC", "", ("全局有序消息" + i).getBytes(RemotingHelper.DEFAULT_CHARSET));]]></description><category></category></item><item><title><![CDATA[Rocketmq系统架构]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/139812034</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/139812034</guid><author>Martin_rui</author><pubDate>Wed, 19 Jun 2024 20:11:56 +0800</pubDate><description><![CDATA[3）Producer启动时，先跟NameServer集群中的某⼀个节点建⽴⻓连接，并从中获取当前订阅Topic的Queue与Broker的地址(IP+Port)之间的映射关系。当Topic路由信息发⽣变化时，NameServer不会主动推送给Client，导致客户端⽆法被动感知Topic信息的动态变化，因此客户端会每30s去NameServer拉取Topic最新的路由信息。2）启动Broker集群，每个Broker主动发起请求，与NameServer集群内所有节点建⽴⻓连接，每隔30s发送⼀次⼼跳包数据；]]></description><category></category></item><item><title><![CDATA[Rocketmq介绍以及基本概念]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/139795108</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/139795108</guid><author>Martin_rui</author><pubDate>Wed, 19 Jun 2024 20:09:06 +0800</pubDate><description><![CDATA[MQ：消息队列。队列，是⼀种FIFO 先进先出的数据结构。消息由⽣产者发送到MQ进⾏排队，然后按原来的顺序交由消息的消费者进⾏处理。MQ的作⽤主要有以下三个⽅⾯：异步处理：提⾼系统的响应速度、吞吐量。例如：发短信解耦：服务之间进⾏解耦，提⾼系统整体的稳定性以及可扩展性;实现数据分发,⽣产者发送⼀个消息后，可以由⼀个或者多个消费者进⾏消费，并且消费者的增加或者减少对⽣产者没有影响。削峰：以稳定的系统资源应对突发的流量冲击。]]></description><category></category></item><item><title><![CDATA[ZAB一致性协议]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/139737235</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/139737235</guid><author>Martin_rui</author><pubDate>Mon, 17 Jun 2024 10:33:08 +0800</pubDate><description><![CDATA[在分布式系统中，确保数据的一致性和原子性是一个很大的挑战，因为在分布式系统中，多个节点可能会同时修改数据，这可能导致数据的不一致和部分执行。但是，ZAB协议和Paxos协议有一些区别，比如ZAB协议使用了状态机来存储和管理配置和数据，而Paxos协议则使用了一系列的值。但是，ZAB协议和Raft协议有一些区别，比如ZAB协议使用了状态机来存储和管理配置和数据，而Raft协议则使用了一系列的日志。状态机算法是ZAB协议的一个核心部分，它用于存储和管理Zookeeper集群中的配置和数据。]]></description><category></category></item><item><title><![CDATA[Redis底层数据结构实现]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/139451483</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/139451483</guid><author>Martin_rui</author><pubDate>Tue, 04 Jun 2024 18:54:20 +0800</pubDate><description><![CDATA[所以没有完美的数据结构，只有更合适业务的设置。]]></description><category></category></item><item><title><![CDATA[Hash冲突解决方案总结]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/139441724</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/139441724</guid><author>Martin_rui</author><pubDate>Tue, 04 Jun 2024 14:15:07 +0800</pubDate><description><![CDATA[原理是当发生hash冲突时，会以当前地址为基准，然后根据寻址方法（探查寻址），去寻找下一次地址。若依旧发生冲突，则继续寻址，直到找到一个空的位置为止。通用的散列函数形式为：其中h[key]为哈希函数、hi为算出的存储地址、m 为hash表的长度、i称为增量序列。增量序列的取值方式不同，相应的再散列方式也不同。]]></description><category></category></item><item><title><![CDATA[Raft算法]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/139421347</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/139421347</guid><author>Martin_rui</author><pubDate>Mon, 03 Jun 2024 22:26:36 +0800</pubDate><description><![CDATA[如果不匹配，]]></description><category></category></item><item><title><![CDATA[HashMap源码分析]]></title><link>https://blog.youkuaiyun.com/Martin_rui/article/details/127744124</link><guid>https://blog.youkuaiyun.com/Martin_rui/article/details/127744124</guid><author>Martin_rui</author><pubDate>Tue, 08 Nov 2022 09:25:16 +0800</pubDate><description><![CDATA[HashMap源码分析]]></description><category></category></item></channel></rss>