- 博客(189)
- 资源 (7)
- 收藏
- 关注
RSS订阅原创 Kubernetes调度单位Pod
一个 pod 可包含一或多个容器（container），它们共享一个 namespace（用户，网络，存储等），其中进程之间通过 localhost 本地通信，就相当于我们在本地起两个进程。如果Pod中运行了一个Web服务，可以通过端口转发来从本地访问这个服务。若有两个 Nginx，默认进入第一个，-c 选项可指定进入哪一个。在开发过程中，可以通过端口转发来方便地调试Pod中运行的服务。咋才能映射一个可访问ip，本地也能与 nginx 通信？但这样如果把该命令停止，就无法访问。2.2 按yaml创建。
2024-09-23 23:13:16
126
原创 快速搭建Kubernetes集群
切换到 Kubernetes 标签页，并勾选启动 Enable Kubernetes，点击 Apply。启用swap设备会对系统的性能产生很负面影响，因此k8s要求每个节点都要禁用swap设备。以上内容全部配置好以后，重启。所有节点都要执行以上操作！swap分区即虚拟内存分区，云服务器没有这个概念，可不设置。因为本地机器和云服务器时间可能不一致，所以需要同步时间。作用：物理内存使用完，之后将磁盘空间虚拟成内存来使用。获取更多干货内容，记得关注我哦。若使用的云服务器，则忽略此步。
2024-09-23 23:08:19
202
原创 #到底什么是大模型Attention机制
上文所举的机器翻译的例子里，因为在计算Attention的过程中，Source中的Key和Value合二为一，指向的是同一个东西，也即输入句子中每个单词对应的语义编码，所以可能不容易看出这种能够体现本质思想的结构。在一般任务的Encoder-Decoder框架中，输入Source和输出Target内容是不一样的，比如对于英-中机器翻译来说，Source是英文句子，Target是对应的翻译出的中文句子，Attention机制发生在Target的元素Query和Source中的所有元素之间。
2024-09-23 08:36:11
477
原创 #面试系列-腾讯后端一面
我回答的是，既然要应对这种问题，就要探测这个线程是否在执行，那么就可以在加锁的用户线程中加一个发送心跳的操作，在另外一个服务中去接收这个心跳，如果在一段时间内都收不到用户线程的心跳，那么就说明这个用户线程出现问题了，一直没有得到执行，因此就可以主动的去将这个用户线程加的分布式锁给释放掉，那么这里判断线程出现问题的时间就可以设置的短一些，比如 5s 都没有收到该线程的心跳，那么就判断该线程得不到调度，出现问题，就主动去释放他的锁。无论从哪个节点到其叶子节点的路径，经过的黑色节点数量必须相同。
2024-09-22 22:32:55
1067
原创 一文详解大语言模型Transformer结构
首先，self-attention会计算出三个新的向量，在论文中，向量的维度是512维，我们把这三个向量分别称为Query、Key、Value，这三个向量是用embedding向量与一个矩阵相乘得到的结果，这个矩阵是随机初始化的，维度为（64，512）注意第二个维度需要和embedding的维度一样，其值在BP的过程中会一直进行更新，得到的这三个向量的维度是64。随着这种情况的发展，数据的偏差越来越大，我的反向传播需要考虑到这些大的偏差，这就迫使我们只能使用较小的学习率来防止梯度消失或者梯度爆炸。
2024-09-22 18:41:19
746
原创 Spring框架总体结构
一站式：在 IOC 和 AOP 的基础上可以整合各种企业应用的开源框架和优秀的第三方类库（实际上 Spring 自身也提供了展现层的 SpringMVC和 持久层的 Spring JDBC）包含基本的面向网络的集成特性，如文件分部上传，使用Servet监听器和面向网络的应用上下文初始化IoC容器。轻量级：Spring 是非侵入性的 - 基于 Spring 开发的应用中的对象可以不依赖于 Spring 的 API。模块，包含Spring的模型-视图-控制器（model-view-controller，
2024-09-22 17:06:04
874
原创 分布式选举协议-ZAB协议概述与选主流程详解
服务器1收到服务器2的选票（1, 2, 0）和服务器3的选票（1, 3, 0）后，由于所有的logicClock都相等，所有的zxid都相等，因此根据myid判断应该将自己的选票按照服务器3的选票更新为（1, 3, 0），并将自己的票箱全部清空，再将服务器3的选票与自己的选票存入自己的票箱，接着将自己更新后的选票广播出去。即消息已经发送到队列中。在上图中，(1, 1, 0)第一位数代表投出该选票的服务器的logicClock，第二位数代表被推荐的服务器的myid，第三位代表被推荐的服务器的最大的zxid。
2024-09-04 08:00:42
712
原创 浅谈分布式锁的几种方案
然后由于必须获取到5个节点中的3个以上，所以可能出现获取锁冲突，即大家都获得了1-2把锁，结果谁也不能获取到锁，这个问题，redis作者借鉴了raft算法的精髓，通过冲突后在随机时间开始，可以大大降低冲突时间，但是这问题并不能很好的避免，特别是在第一次获取锁的时候，所以获取锁的时间成本增加了。如果5个节点有2个宕机，此时锁的可用性会极大降低，首先必须等待这两个宕机节点的结果超时才能返回，另外只有3个节点，客户端必须获取到这全部3个节点的锁才能拥有锁，难度也加大了。=t3说明锁被其他线程获取了。
2024-09-03 08:00:06
661
原创 #分布式系统为啥需要消息队列
消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发的Notify、MetaQ、RocketMQ等。本文不会一一介绍这些消息队列的所有特性，而是探讨一下自主开发设计一个消息队列时，你需要思考和设计的重要方面。过程中我们会参考这些成熟消息队列的很多重要思想。本文首先会阐述什么时候你需要一个消息队列
2024-09-02 08:13:35
1603
原创 分布式缓存常见更新套路
一个是查询操作，一个是更新操作的并发，首先，没有了删除cache数据的操作了，而是先更新了数据库中的数据，此时，缓存依然有效，所以，并发的查询操作拿的是没有更新的数据，但是，更新操作马上让缓存的失效了，后续的查询操作再把数据从数据库中拉出来。于是，在缓存中的数据还是老的数据，导致缓存中的数据是脏的，而且还一直这样脏下去了。不是的，比如，一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。
2024-09-01 16:46:57
957
原创 分布式技术实践总结
cookie-id？4 redis的集群方案，p2p的Redis Cluster部署了多台Redis服务器，每台Redis拥有全局的分片信息，所以任意节点都可以对外提供服务，当然每个节点只保存一部分分片，所以某台机器宕机时不会影响整个集群，当然每个节点也有slave，哨兵自动进行故障切换。好，这个方式拦住了写for循环发http请求的程序员，有些高端程序员（黑客）控制了10w个肉鸡，手里有10w个uid，同时发请求（先不考虑实名制的问题，小米抢手机不需要实名制），这下怎么办，站点层按照uid限流拦不住了。
2024-08-31 20:47:08
1370
原创 一文体系化搞懂分布式LVS实现负载均衡的原理与实践
在实际应用中，在Web服务器集群之前总会有一台负载均衡服务器，负载均衡设备的任务就是作为Web服务器流量的入口，挑选最合适的一台Web服务器，将客户端的请求转发给它处理，实现客户端到真实服务端的透明转发。我们有个中间层啊，对，就是DNS，我们可以设置一下，让我们网站的域名映射到多个服务器的IP，用户面对的是我们系统的域名，然后我们可以采用一种轮询的方式， 用户1的机器做域名解析的时候，DNS返回IP1, 用户2的机器做域名解析的时候，DNS返回IP2……然而，我们的网站对外提供的访问入口都是一个的，比如；
2024-08-26 08:56:40
315
原创 Redis入门概述
一般像 MySQL 这类的数据库的 QPS（Query Per Second，服务器每秒可以执行的查询次数）大概都在 1w 左右（4 核 8g） ，使用 Redis 缓存之后很容易达到 10 w+，甚至最高能达到 30 w+（单机 Redis 的情况，Redis 集群的话会更高）。由此可见，直接操作缓存能够承受的数据库请求数量是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库，也就提高了系统整体的并发。
2024-08-04 22:30:43
675
原创 应用服务器集群的Session管理方案
应用服务器开启Web 容器的Session复制功能，在集群中的几台服务器之间同步Session对象，使得每台服务器上都保存所有用户的Session信息,这样任何一台机器宕机都不会导致 Session 数据丢失，而服务器使用Session时，也只需在本机获取。早期系统使用C/S架构,一种管理Session的方式是将Session记录在客户端,每次请求服务器的时候,将Session放在请求中发送给服务器,服务器处理完请求后再将修改过的Session响应给客户端。答案就是Session服务器!
2024-07-31 09:27:22
434
原创 几种分库分表后全局id生成方案
假设，在2175/11/7 12:12:14时间里，机房17的机器25，发送了第二条消息，snowflake算法服务，会发现说机房17的机器25，在2175/11/7 12:12:14时间里，在这一毫秒，之前已经生成过一个id了，此时如果你同一个机房，同一个机器，在同一个毫秒内，再次要求生成一个id，此时我只能把加1。twitter开源的分布式id生成算法，把一个64位的long型的id，1个bit是不用的，用其中的41 bit作为毫秒数，用10 bit作为工作机器id，12 bit作为序列号。
2024-07-30 21:10:12
420
原创 如何保证分布式服务接口的幂等性
系统异常时666请求到了，单号更成666，接着888请求到了，单号又更新成888，但是666更新成功的响应丢了，调用方没收到成功响应，自动重试，再次发起666请求，单号又被更新成666了，这数据显然就错了.若有一个订单已支付，就已经有了一条支付流水，那么如果重复发送这个请求，则此时先插入支付流水，orderId已存在，唯一键约束生效，报错插入不进去。对于更新订单服务，可以通过一个版本号机制，每次更新数据前校验版本号，更新数据同时自增版本号，这样的方式，来解决ABA问题，确保更新订单服务的幂等性。
2024-07-29 09:38:40
300
原创 分布式Session架构演示史
相应的用户会话都能放入redis中进行管理，如此，Tomcat中的会话，就是有状态的，一旦用户和服务端交互，就有会话，会话保存了用户的信息，这样用户就"有状态”了， 服务端会和每个客户端都保持着这样的一层关系，这个由容器来管理(也就是tomcat) , 这个session会话是保存到内存空间里。本质都是多个系统，假设这个里有两个服务器节点，分别是AB系统，他们可以是集群，也可以是分布式系统，一开始用户和A系统交互，那么这个时候的用户状态，我们可以保存到redis中， 作为A系统的会话信息，随后用户的请求。
2024-07-28 22:10:29
347
原创 从RPC角度如何看待Dubbo还是SpringCloud
所以语言不会成为使用上面这几种RPC框架的约束，而gRPC和Thrift虽然支持跨语言的RPC调用，但是因为它们只提供了最基本的RPC框架功能，缺乏一系列配套的服务化组件和服务治理功能的支撑，所以使用它们作为跨语言调用的RPC框架，就需要自己考虑注册中心、熔断、限流、监控、分布式追踪等功能的实现，不过好在大多数功能都有开源实现，可以直接采用。IDL使用了ProtoBuf，ProtoBuf是由Google开发的一种数据序列化协议，它的压缩和传输效率极高，语法也简单，所以被广泛应用在数据存储和通信协议上。
2024-07-28 09:25:20
277
原创 java常用消息模型
在Topic的消费过程，由于消息需要被不同组进行多次消费，所以消费完的消息并不会立即被删，这需要RocketMQ为每个消费组在每个队列维护一个消费位置（Consumer Offset），该位置之前的消息都被消费过，之后消息都未被消费过，每成功消费一条消息，消费位置加一。消费者在收到消息并完成消费业务逻辑（比如将数据保存到数据库）后，也会给服务端发消费成功的确认，服务端只有收到消费确认后，才认为一条消息被成功消费，否则它会给消费者重发送这条消息，直到收到对应的消费成功确认。如果可以，该如何实现？
2024-07-27 19:19:11
410
原创 消息队列面试之为什么要使用消息队列
如果你说的共享内存指的是PageCache，很多消息队列都会用到，RDMA据我所知常见的几种消息队列应该都还没有使用，像Kafka它在消费的时候，直接使用Zero Copy，数据直接从PageCache写到NIC的缓冲区中，都不需要进入应用内存空间。消息队列不可能能存放无限的消息，消息队列满应该也会有拒绝策略，比如线程池的任务队列，任务队列满，并且超过最大的线程池数，四种的拒绝策略。秒杀开始后，当短时内大量秒杀请求到达网关，不会直接冲击后端秒杀服务，而是先堆积在MQ，后端服务尽力从MQ消费请求并处理。
2024-07-26 08:35:17
233
原创 Java异步编程常用 场景梳理
看transfer()方法，先调用一次账户服务accountService.add()方法从fromAccount扣减相应金额，因add()方法返回的就是个CompletableFeture对象，可用CompletableFeture的thenCompose()方法将下一次调用accountService.add()串联起来，实现异步依次调用两次账户服务完整转账。太多的线程会造成频繁的cpu上下文切换，你可以想象一下，假设你的小公司只有8台电脑，你雇8个程序员一直不停的工作显然是效率最高的。
2024-07-25 08:46:47
731
原创 NIO网络编程详解之Selector事件选择器
在并发量大的时候，使用同一个线程处理连接请求以及消息服务，可能会出现拒绝连接的情况，这是因为当该线程在处理消息服务的时候，可能会无法及时处理连接请求，从而导致超时；通过keys()和selectKeys()返回的键的集合是Selector对象内部的私有的Set对象集合的直接引用。已注册的键的集合是只读的。如果在多个线程并发地访问一个选择器的键的集合的时候存在任何问题，可以采用同步的方式进行访问，在执行选择操作时，选择器在Selector对象上进行同步，然后是已注册的键的集合，最后是已选择的键的集合。
2024-07-24 08:24:09
809
原创 Netty4-实战精华之EventLoop和线程模型详解
然而在一些无状态上下文中，它仍可被用于在多个 Channel 之间共享一些重度的或者代价昂贵的对象，甚至是事件。但在 Netty3 的模型，因这是个入站事件，需在调用线程中执行代码，然后将事件移交给 I/O 线程去执行，这会带来额外上下文切换开销。而 Netty 的线程模型强大又易用，正如 Netty 的宗旨：简化你的应用程序代码，同时最大限度提高性能和可维护性。除这种受限场景，传输所采用的不同事件处理实现，其线程模型也会严重影响排队的任务对整体系统性能影响。中所产生的所有事件，则解决了该问题。
2024-07-21 14:36:17
607
原创 Java高性能系统缓存的最佳实践
如果你的系统是那种可预测未来访问哪些数据的，比如有的系统它会定期做数据同步，每次同步数据范围都一样，这样的系统，缓存策略简单，你要访问什么数据，就缓存什么数据，甚至可做到百分百命中。读写缓存的设计，本身就不可靠，牺牲数据一致性换取性能。从不更新缓存数据，而是给缓存中的每条数据设较短的过期时间，数据过期后即使还存在缓存，也认为不再有效，需从磁盘再次加载这数据，变相实现数据更新。再比如，有会话的系统，你知道现在哪些用户是在线，哪些用户已离线，那优先置换那些已离线用户的数据，尽量保留在线用户的数据也是好策略。
2024-07-20 20:33:05
603
原创 IO多路复用之poll、epoll和select区分
对于第二个缺点，epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中，而只在epoll_ctl时把current挂一遍（这一遍必不可少）并为每个fd指定一个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数，而这个回调函数会把就绪的fd加入一个就绪链表）。取而代之的是，每个孩子如果自己需要尿尿的时候，自己主动的站到事先约定好的地方，而保姆的职责就是查看事先约定好的地方是否有孩子。select的调用复杂度是线性的，即O(n)。
2024-07-20 10:38:15
1214
原创 操作系统之存储管理
新复制的页面对执行写操作的进程是私有的，对其他共享写时复制页面的进程是不可见的。根据程序的局部性原理，一般情况下，进程在一段时间内总是集中访问一些页面，这些页面称为活跃页面，如果分配给一个进程的物理页面数太少了，使得该进程所需的活跃页面不能全部装入内存，则进程在运行过程中将频繁发生中断。缺页越多，系统的性能越差，这称为颠簸（抖动）：虚存中，页面在内存与磁盘之间频繁调度，使得调度页面所需的时间比进程实际运行的时间还多，这样导致系统效率急剧下降，这种现象称为颠簸或抖动。的处理速度和内存的访问速度。
2024-07-16 08:31:46
491
原创 操作系统详解之进程管理
大多数系统调用是阻塞的，因此，由于内核阻塞进程，故进程中所有线程也被阻塞。以一次一页的方式复制父进程的地址空间，这是一个无用功，因为创建子进程就是为了让子进程完成与父进程不同的工作，所以父进程的很多内容其实子进程是不需要的。上面的两个进程都有这样一个地址空间，也就是说这两个进程是在不同的地址空间上的相同的位置，所以虽然地址是一样的，但是实际上在实际内存中的地址是不一样的。一组进程中，每个进程都无限等待被该组进程中另一进程所占用的资源，因而永远无法得到的资源，这种现象称为进程死锁，这一组进程就称为死锁进程。
2024-07-15 08:15:59
1019
原创 操作系统之内存管理
内存管理包括内存管理和虚拟内存管理内存管理包括内存管理概念、交换与覆盖、连续分配管理方式和非连续分配管理方式（分页管理方式、分段管理方式、段页式管理方式）。虚拟内存管理包括虚拟内存概念、请求分页管理方式、页面置换算法、页面分配策略、工作集和抖动。3.1 内存管理的概念内存管理(Memory Management)是操作系统设计中最重要和最复杂的内容之一。虽然计算机硬件一直在飞速发展，内存容量也在不断增长，但是仍然不可能将所有用户进程和系统所需要的全部程序和数据放入主存中，所以操作系统必须将内存空间
2024-07-14 21:11:55
700
原创 Java常见JUC并发工具类
所谓的乐观读模式，也就是若读的操作很多，写的操作很少的情况下，你可以乐观地认为，写入与读取同时发生几率很少，因此不悲观地使用完全的读取锁定，程序可以查看读取资料之后，是否遭到写入执行的变更，再采取后续的措施(重新读取变更信息，或者抛出异常) ，这一个小小改进，可大幅度提高程序的吞吐量。当RPC结果返回时，会调用doReceived()方法，这个方法里面，调用lock()获取锁，在finally里面调用unlock()释放锁，获取锁后通过调用signal()来通知调用线程，结果已经返回，不用继续等待了。
2024-07-13 19:55:45
709
原创 了解零拷贝之前必须要了解的操作系统基础知识
当外围设备完成用户请求的操作后，会向 CPU 发出相应的中断信号，这时 CPU 会暂停执行下一条即将要执行的指令而转到与中断信号对应的处理程序去执行，如果前面执行的指令是用户态下的程序，那么转换的过程自然就会是从用户态到内核态的切换。它的原理是：动态保存每一个程序的起始物理内存地址和长度，然后每次访问指定的内存地址时，CPU 会在把地址发往内存总线之前自动把基址寄存器里的值加到该内存地址上，得到一个真正的物理内存地址，同时还会根据界限寄存器里的值检查该地址是否溢出，若是，则产生错误中止程序。
2024-07-13 19:19:37
674
原创 RocketMQ 消费者之顺序消费和流程详解附源码解析
顺序消费的消费任务也由拉取任务提交，逻辑改成了：持续消费一个队列的消息，直到该队列的消息消费完或者超过最大消费时间（1分钟）。队列中的多个消息并发消费：消费者执行消费逻辑时，使用一个消费线程池进行消费，该线程池默认有 20 个线程同时进行消费，所以也有可能并发消费一个队列中的多个消息。），消费任务开始时获取锁，消费任务结束时释放锁，保证就算有多个线程同时消费一个队列，但同时最多只有一个线程真正在执行消费（其他线程都在等待锁释放）。并发消费的消费线程池，每个线程的消费任务是：消费一批（默认一条）消息。
2024-07-12 08:31:19
1149
原创 RocketMQ之消费者，消息消费、消费进度上报流程详解 附源码解析
从上一步拉取消息到消费者后，将拉取到的一批消息提交给并发消费服务，并发消费服务将消息封装成一个个消费请求（每个消费请求将消费一批消息，默认一批只包含一条消息）提交给消费线程池进行消费。新创建的重试消息是定时消息，它的 Topic 是定时消息 Topic，定时消息的机制会不停扫描定时消息 Topic 中的队列，看该消息是否到期，如果到期则投递。Broker 收到请求后用延迟消息机制，用该消息重新消费的次数计算延迟等级，生成一个新消息，将重新消费次数 + 1，作为延迟消息放入消息存储。消费成功则更新消费进度；
2024-07-12 08:24:04
1576
原创 RocketMQ之消费者，消息拉取流程详解附源码解析
上一篇重平衡篇有提到，重平衡将为消费者负载的队列创建拉取请求并放入队列，后续不会新建而是重复使用这个拉取请求，取出执行一次，拉取完成之后更新拉取偏移量，再将它重新放入队列。消息拉取流控检查，检查处理队列中还未被消费的消息，从待消费消息数量、大小和待消费消息偏移量差来判断。根据队列找到对应的消费队列，读取消费队列判断是否有消息可以消费，如果有则根据消费队列中的索引项，用物理偏移量从消息存储中查找消息。消费者的处理线程池处理拉取完成的回调，将消息从拉取到的响应中解码出来，放入消费队列，让消费服务消费。
2024-07-09 08:45:32
750
原创 RocketMQ之消费者，重平衡机制与流程详解附带源码解析
RocketMQ 的重平衡大致实现方式为：在消费者端用一个固定的分配策略将所有的消费队列分配给所有的消费者。通过将每个消费者的分配策略设置成一致，并且将消费者和消费队列排序的方法，保证每个消费者的分配的结果幂等。我把重平衡的触发分为主动触发和被动触发，主动触发是由消费者的启动和停止触发的；推模式消费者启动或恢复时，唤醒本地的重平衡线程，立即重平衡。进行重平衡，客户端实例的该方法没有具体逻辑，仅仅是遍历客户端上注册的所有消费者，获取它们的重平衡实现并且调用。其他消费者收到消费者数量变化请求时进行重平衡。
2024-07-09 08:23:04
1254
原创 RocketMQ之消费者，客户端设计和启动流程详解附带源码解析
推模式消费者实际内部也是通过拉取消息的方式进行消息拉取，只不过封装了订阅和监听器这样的对外接口，让用户在使用时感觉像 Broker 主动推送消息到消费者。拉模式消费者的消费步骤为：拉取消息，执行消费逻辑，上报消费进度，如果有需要的话对于消费失败的消息还需要发回 Broker 重新消费。推模式消费者消费步骤更简单，只需要订阅一个 Topic，然后指定消费回调函数，即可在收到消息时自动消费。就是我们实际消费中需要新建的消费者对象。由于拉模式和推模式消费者的启动流程大致相同，所以只介绍推模式消费者的启动流程。
2024-07-08 22:43:08
906
原创 RocketMQ之消费者带你了解概念和消费流程
需要注意的是，这里所说的顺序消费指的是队列维度的顺序，即在消费一个队列时，消费消息的顺序和消息发送的顺序一致。为消费者分配队列消费的这一个负载过程并不是一劳永逸的，比如当消费者数量变化、Broker 掉线等情况发生后，原先的负载就变得不再均衡，此时就需要重新进行负载均衡，这一过程被称为重平衡机制。如果是集群消费模式，还需要将消费进度让其他消费者知道，所以需要提交消费进度。在集群消费模式下，消费组中的消费者共同消费订阅的 Topic 中的所有消息，这里就存在 Topic 中的队列如何分配给消费者的问题。
2024-07-08 08:15:27
984
原创 RocketMQ IndexFile 索引文件
存储的每个值是在索引文件中 索引的逻辑下标。因为索引文件的 Header 和 Hash Slot 部分长度都是固定的，每个索引的长度也是固定的，所以可以通过逻辑下标计算出索引项在索引文件中的绝对偏移量。列表中的索引文件，查找索引对应的 message 符合时间的 IndexFile（[beginTimestamp, endTimestamp] 与 [begin, end] 有交集的索引文件）索引文件的刷盘机制并不是采取定时刷盘机制，而是每写满一个索引文件时就新建一个文件，并且将上一个写满的索引文件刷盘。
2024-07-04 08:51:51
440
原创 RocketMQ 消息发送设计和原理详解 源码剖析
消息的路由指的是发送消息时需要先获取 Topic 的路由信息（其中包含每个 Topic 的队列和它们所在的 Broker 地址），然后选择一个队列进行发送。消息发送的 API 提供了参数，可以传入要发送的队列信息，或者传入队列选择方法，以供用户选择发往某个 Broker 的具体队列。RocketMQ 的 Java 客户端提供了丰富的消息发送 API，支持多种消息发送的方式和特殊消息的发送。包括 3 种发送方式（同步、异步、单向）和多种特殊消息（顺序消息、延时消息、批量消息、过滤消息、事务消息）。
2024-07-04 08:26:14
394
原创 RocketMQ NameServer源码剖析
基于性能的考虑，NameServer 本身的实现非常轻量，而且可以通过增加机器的方式水平扩展，增加集群的抗压能力，而 zookeeper 的写是不可扩展的，而zookeeper 要解决这个问题只能通过划分领域，划分多个zookeeper集群来解决，首先操作起来太复杂，其次这样还是又违反了CAP中的A的设计，导致服务之间是不连通的。NameServer 是一个简单的 Topic 路由注册中心，类似 Kafka、Dubbo 中的 Zookeeper，支持 Broker 的动态注册与发现。
2024-07-03 08:47:55
707
原创 RabbitMQ 进程内流控（Flow Control） 源码解析
Erlang没有对进程邮箱的大小进行限制，所以当有大量消息持续发往某个进程时，会导致该进程邮箱过大，最终内存溢出并崩溃。这可能是由于将消息存入队列的过程中引起服务器 CPU 负载过高，或者是将队列中的消息存入磁盘的过程中引起服务器 I/O 负载过高而引起的此种情形。状态，说明它们最近处于流控状态。当 reader 进程开始处理一条消息，它会先将自己的信用值-1，然后将消息处理完后发给 channel 进程（图中2）这里的进程与操作系统的进程不同，是一个由 Erlang 系统管理的轻量级进程。
2024-06-30 16:25:23
420
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人