Hurried1y

RocketMQ - ConsumerRocketMQ Consumer底层原理分析消费者模型在 RocketMQ 的官方文档中，定义了在 Rocket MQ 的领域模型中，消费者的位置和流程。 消息由生产者初始化并发送到 RocketMQ 服务端。 消息按照到达 RocketMQ 服务端的顺序存储到主题的指定队列中。 消费者按照指定的订阅关系从 RocketMQ 服务端中获取消息并消费。 内部属性消费者分组名称 当前消费者关联的消费者分组名称，消费者必须关联到指定的消费者分组，通过消费者分组获取消费行为。 客户端ID 消费者客户端的标识，用于区分不同的消费者。集群内全局唯一。 预绑定订阅关系列表 指定消费者的订阅关系列表。RocketMQ 服务端可在消费者初始化阶段，根据预绑定的订阅关系列表对目标主题进行权限及合法性校验，无需等到应用启动后才能校验。 消费监听器 RocketMQ 服务端将消息推送给消费者后，消费者调用消息消费逻辑的监听器。 消费者启动流程要具体地了解 RocketMQ的消费者逻辑，我们先从消费流程开始看起，这里我直接引用了 rocketmq 源码中的消费消息测 ...

RocketMQ - Producer前言在之前发过 rocketmq 的 namesrv 和 broker 两个模块的一些理解，但在后面总结下来，更多是自顾自地翻代码，感觉自己抓住一个点就一直往下看，对逻辑主线没有一个很好地梳理，不过人总是慢慢成长的，这篇文章用作记录自己简单学习生产者模块的记录。 消费者模型在 RocketMQ 的官方文档中，定义了在 Rocket MQ 的领域模型中，消费者的位置和流程。 消息由生产者初始化并发送到 RocketMQ 服务端。 消息按照到达 RocketMQ 服务端的顺序存储到主题的指定队列中。 消费者按照指定的订阅关系从 RocketMQ 服务端中获取消息并消费。 内部属性消费者分组名称 当前消费者关联的消费者分组名称，消费者必须关联到指定的消费者分组，通过消费者分组获取消费行为。 客户端ID 消费者客户端的标识，用于区分不同的消费者。集群内全局唯一。 预绑定订阅关系列表 指定消费者的订阅关系列表。RocketMQ 服务端可在消费者初始化阶段，根据预绑定的订阅关系列表对目标主题进行权限及合法性校验，无需等到应用启动后才能校验。 消费监听器 ...

Nacos Server Register and Discovery前言之前尝试去简单梳理了一下RocketMQ的两个模块的初始执行流程，感觉还是没有做到与客户端结合，很多点停留在表面，并没有深入地去思考其为什么要这么写，后续还要继续完善。因为之前的一个个人项目中用到了Zookeeper作为注册中心，就想深入地去看一下同为注册中心的Nacos，这篇文章参考了Nacos的官方文档，从其数据模型到实现逻辑一一展开。 Nacos 注册中心的设计原理一、数据模型在讲服务注册与发现的源码之前，我们先要对 Nacos 中的数据模型有一个简单了印象。注册中心的核心数据是服务的名字和它对应的网络地址，其还包括了实例的健康状态、权限、权重等等信息。Nacos 采用的是一种服务-集群-实例的分级模型，这样基本可以满足服务在所有场景下的数据存储和管理。 除此之外，Nacos 提供了四层的数据逻辑隔离模型，用户账号对应的可能是⼀个企业或者独立的个体，这个数据⼀般情况下不会透传到服务注册中心。⼀个用户账号可以新建多个命名空间，每个命名空间对应 ⼀个客户端实例，这个命名空间对应的注册中心物理集群是可以根据规 ...

RocketMQ梳理 - broker一、前言上一篇文章简单的过了一遍namesrv的流程，其中很多的细节都没有进行展开，整篇文章抓不住重点，权当流程速览了。在这篇文章中将会尝试对rocketmq的流程进行简单的分析。 二、源码分析1、启动流程分析下图就是broker的启动类，在namesrv中，有着一个NamesrvController，负责管理Name Server节点的状态、消息的路由注册与查询等功能，在broker中也有类似的BrokerController，负责管理broker的核心逻辑和状态。在brokerController中，包含了对消息存储、消息发送和接收、消息队列管理等方面的处理逻辑。 broker的启动流程跟namesrv差不多，可以大致分为 initialize、start，我们先来看initialize初始化。 1）BrokerController initializeinitialize可以分为两部分，初始化broker的元数据和broker中的消息存储的一些配置(比如commitLog、storePath等)。 可以看到，第一步初始化元数据，就是从文件 ...

RocketMQ梳理 - namesrv一、前言最近实习用到了rocketmq，在完成项目后，心血来潮，突然想深入地了解一下rocketmq，特在此记录一下。 本文结合rocketmq官方文档和网上的一些零零散散的资料，常识去简单梳理rocketmq整体执行流程，作为个人学习历程的记录。 二、整体模块如下 这是从gitHub上down下来的rocketmq源码，可以大致分为以下模块： rocketmq-namesrv：namesrv服务，更新和路由发现 broker服务。 rocketmq-broker：mq的核心，主要做消息存储，可以接收consumer和producer的请求，然后通过调用rocketmq-store服务对消息进行处理。 rocketmq-store：存储层实现。 rocketmq-remoting：基于netty的底层通信实现，rocketmq的底层实现。 rocketmq-common：common服务，比如一些配置文件、常量。 rocketmq-client：java版本的mq客户端。 rocketmq-filter：消息过滤服务，相当于在broker和co ...

Hadoop核心组件—Yarn的工作流程一、作业提交阶段 Client 向整个集群提交 Job，同时申请一个 job_id ResourceManager 收到 Client 的请求后，给 Client 返回该 job 资源的提交路径、hdfs 路径、job_id （每一个 job 都有一个唯一的 job_id） Client 收到 ResourceManager 的响应后，将 Jar包、Configuration信息、InputSplit（数据分片信息）等数据到指定的资源提交路径 Client 向 ResourceManager 发送执行作业请求 二、作业初始化阶段 ApplicationManager 将 Job 添加到 ResourceScheduler（资源调度器），其维护了一个 job队列 当轮到任务执行，ResourceScheduler 通知 ApplicationManager 有空闲的 NodeManager 可以用来执行当前任务 ApplicationManager 调用分配给它的 NodeManager，在其中开辟一个 Container，并在容器中启动需要被执 ...

关于加密解密的小小总结一、前言这篇文章不讲具体的加密算法，主要总结加密解密在项目中的具体应用，其中加密算法介绍内容来自 流程内容自于自己平常工作学习的总结，在这里小小记录一下。 二、可逆加密与不可逆加密加密算法我们整体可以分为：可逆加密和不可逆加密，可逆加密又可以分为：对称加密和非对称加密。 1、不可逆加密常见的不可逆加密算法有MD5，HMAC，SHA1、SHA-224、SHA-256、SHA-384，和SHA-512，其中SHA-224、SHA-256、SHA-384，和SHA-512我们可以统称为SHA2加密算法，SHA加密算法的安全性要比MD5更高，而SHA2加密算法比SHA1的要高。其中SHA后面的数字表示的是加密后的字符串长度，SHA1默认会产生一个160位的信息摘要。 由于这些加密都是不可逆的，因此比较常用的场景就是用户密码加密，其验证过程就是通过比较两个加密后的字符串是否一样来确认身份的。网上也有很多自称是可以破解MD5密码的网站，其原理也是一样，就是有一个巨大的资源库，存放了许多字符串及对应的MD5加密后的字符串，通过你输入的MD5加密串来进行比较，如果过你的密码复杂度 ...

PostgreSQL 存储过程一、前言最近在实习期间遇到的一些问题，其实逻辑思路很简单，就是需要把关联表的一些脏数据清除，逻辑就是从原表获得所有id，再根据这个id去关系表中遍历所有数据，根据关系表中的数据进行判断更新。 理想的 sql 如下： 1234567update dt_app_user_rel r2set r2.is_delete=1where r2.range_type=2 and r2.data_key not in ( select r1.data_key from dt_app_user_rel r1 where r1.app_id=r2.app_id and r1.range_type=1 and r1.is_delete=0) 这过程中存在单表的自查询和更新，但这种情况是不被允许的，这个时候就需要用到存储过程了。 这里先附上存储过程的简单结构： 1234567891011121314151617-- 基础的存储过程语法模板create or replace procedure public.proc_check_data(check_period charact ...

Flink中TaskManager与Slots的关系一、基本概念1、TaskManagerFlink 采用 Master-Slave 主从架构，其中 JobManager 作为集群 Master节点 ，主要负责任务协调和资源分配，TaskWorker （TaskManager） 作为Salve节点，用于执行流task。 JobManager是控制一个应用程序执行的主进程，相当于集群的Master节点，且整个集群有且只有一个活跃的 JobManager ，JobManager 负责整个 Flink 集群任务的调度以及资源的管理。 Flink TaskManager 执行作业流的 task，并且缓存和交换数据流，TaskManager 负责执行用户代码。根据实际需求为 TaskManager 配置内存将有助于减少 Flink 的资源占用，增强作业运行的稳定性。 2、SlotsFlink中每一个worker(TaskManager)都是一个 JVM进程 ，它可能会在独立的线程上执行一个或多个subtask。为了控制一个TaskManager能接收多少个task，TaskManager通过t ...

怎么去实现动态扩展机制SPI一、前言关于动态扩展机制SPI，在之前我有发过该类的文章，感兴趣的可以去看一下，或者可以自己去百度了解一下，在本篇文章中就不做过多的赘述了。 本篇主要是着重于怎么去实现SPI，参考于Dubbo SPI，感兴趣的可以去了解一下。 二、实现Dubbo SPI的核心类在于ExtensionLoader，通过加载本地目录的配置文件以实现动态植入扩展类。 1、配置类定义我们这里仿照Dubbo里面对配置文件的定义，讲扩展接口的配置定义在资源路径下的 META-INF/extensions/ 目录下，配置文件以对应扩展接口的类路径命名 配置文件的内部以 Key-Value 键值对形式定义，key 由自己定义，value为对应实现类的类路径 具体的结构如下图所示： 基于上面的定义，给出获取实现类最简单的方式： 程序运行情况： 2、模块化实现基于上面的思路，已经可以简单的实现了，现在我们把它给完善一下。 核心类属性 内部方法 getExtensionLoader 首先传入扩展接口的类型 ，以获取对应泛型的 ExtensionLoader 对象，在这里还可以做一 ...