暂时未有相关云产品技术能力~
LiteFlow学习三之业务编排处理之外
liteflow学习二
liteflow学习一
如何设计一个灵活的审批流程
Austin消息中心
ageiport使用
eventMesh源码学习
rocketmq获取默认的MQAdminExt时候,需要进行对象的获取,主要在rocketmq可视化中,方便使用,池化作为一个循环利用的过程,其类似于我们常用的数据库连接池一样,节省启动的成本。同时MQAdminExt是作为二次开发的一个主要使用的类。
RocketMQ整合Spring中推拉模式的相关配置介绍和遇到推拉配置出现的问题的解决
CacheCloud作为一款可视化方便管理redis的开源软件,可以方便redis集群的管理、开发、监控、运维管理,下面就CacheCloud的代码进行一些整理和学习
Mysql文件包括:参数文件、日志文件、socket文件、pid文件、mysql表结构文件、存储引擎文件、参数文件、日志文件,通过了解mysql的文件相关组成,我们可以知道mysql的组成。
InnoDB存储引擎最早由Innobase Oy公司开发,被包括在mysql数据库所有的二进制发行版本中,从mysql5.5版本开始默认的表存储引擎。其中Heikki Tuuri是InnoDB存储引擎的创始人。 InnoDB架构体系包含后台线程、内存、checkpoint技术,其中后台线程包含主线程、io处理线程、回收分配undo线程、页清理线程;内存包括缓冲池、重做日志缓冲、额外缓冲池;checkpoint技术包含 Sharp Checkpoint、FuzzyCheckpoint,数据库运行时,通常会和FuzzyCheckpoint打交道,通常会根据检查点age来处理
整理的原因是在Sentinel源码中,我们可以看到很多关于CompletableFuture的thenCompose的源码。同时在业务系统里面也看到别人写过类似的代码。因此整理了一下关于CompletableFuture使用的相关类型和特性,在处理复杂耗时业务时可以选择组合使用。
们可以它的一系列动作操作,会首先将相关配置MessageConverterConfiguration、ListenerContainerConfiguration、ExtProducerResetConfiguration、ExtConsumerResetConfiguration、RocketMQTransactionConfiguration、RocketMQListenerConfiguration进行导入。在自动注入前处理事务配置RocketMQTransactionConfiguration,在自动注入后处理消息转换器配置MessageConverterConfiguration。
通常spi可以配合责任链模式、策略模式使用。此时spi,类似于一个上下文的过程,拿到所有的实现class。 与之类似的还有:SpringUtil.getBeans或者ApplicationContext.getBeansOfType。在一些固定的场景下,处理业务的流程过程通常比较明确,第一步做什么,第二步做什么,第三步做什么的时候,这个时候就可以使用责任链模式在处理。也即存在固定的模式的时候,就可以使用。同时在Netty、Sentinel中有重要使用场景,其过程是一个pipeline流水线的过程。
### 一、如何实现一个简单的认证中心? 我们知道单点登录系统:出名的有[apereo](https://github.com/apereo)的cas和OAuth2、JWT等。通常认证有两个方案: 一个方案是基于token,另一个方案是基于cookie的。基于xxl-sso,我们可以学习到实现的基本是基于过滤器的增强,从而实现重定向。我之前的公司使用的是基于[apereo](https://github.com/apereo)的cas进行的二次开发配合统一授权系统使用。cas的单点登录的登录涉及到三个概念:
### 一、实现一个轻量级简单的配置中心,同时不考虑使用zk? 1.由于我们使用的配置中心需要兼容多套环境,因此需要多环境 2.需要有权限控制 3.需要对配置的信息,能够实时响应 4.如果配置信息存储在数据库,为了减轻数据库的压力,可以进行持久化到磁盘文件中 当时这里会有一个问题需要考虑,如果持久化到磁盘,需要考虑如果配置发生了改变,需要能够实时同步到磁盘文件中,因此此时需要考虑一个线程进行实时同步。 5.对应配置信息发生增、删、改,能够实时更新和修改
1)BinLog是Mysql本身就有的,不管使用哪种引擎,都会存在BinLog,而Redo Log是InnoDB引擎特有的。 2)BinLog是一种逻辑日志,记录的是对数据库的所有修改操作,而RedoLog是一种物理日志,记录的是每个数据页的修改。 3)BinLog具有幂等性,而Redo Log不具有幂等性。 4)BinLog开启事务时,会将每次提交的事务一次性写入内存缓冲区,如果未开启事务,则每次成功执行插入、更新和删除语句时,就会将对应的事务信息写入内存缓冲区修改数据,而Redo Log是在数据准备之前将数据写入缓冲区的Redo Log中,然后在缓冲区中修改数据。而且在提交事务时,先将Re
通常递归算法可以将一个问题的重复调用进行分解,将其分解成一个多次调用,最终完成筛选或者需要的数据。比如我们常见的斐波那契数列就是这样的: 0、1、1、2、3、5、8、13、21、34这样的递归数据,可以通过此来总结出它的数学公式规律:F(n) = F(n-1) + F(n-2)的这个过程就是是借助上面的F(0)和F(1)的结果来进行递推的,这个过程在数学上是一个数列的递推公式,在高中我们学过的数列上。我还记得当时求解递推公式可以使用函数方程,而函数方程的思想想想其实是借助了微分方程逆推得到积分方程的过程,或者说是采用不动点法可以实现这一求解的过程。这个过程,在我看到高等数学的时候才明白,现在想
一个好的通信框架是怎样的?同时如何使用netty? 一个好的通信框架,必然是支持双工通信的,同时它能够对半包黏包进行处理,方便高效的编解码、序列化,拥有心跳超时机制,同时支持大量连接并发,方便调用。而这个通信的过程,我始终是觉得它的起源是三次握手和四次挥手。它们影响着消息中间件和通信框架以及SOA框架的发展。netty最简单的是它的EchoServer和EchoClient,两者有同时有自己对应的处理器EchoServerHandler、EchoClientHandler。
首先需要对当前的id进行拦截操作,也即使用aop的切面Aspect对切点进行拦截,在进行新增的时候进行拦截: 也就是说在进行主键的生成时,我们拦截好需要生成的主键,此时就可以对其进行新增操作了,而首要的就是拿到它的primaryKey。由于进行新增操作,通常分为两种情况: 通过字节码拿到声明的方法getId,如果此时存在id,则说明此时的操作是更新操作,因此直接返回。如果当前通过字节码拿到的声明方法getTenant,通过租户方法拿到租户id。拿到租户id后,就可以进行主键id获取了。
需求是基于治疗数据,推送给平台,使用xml对数据进行组装,同时进行加密,里面包含所有的治疗数据与pdf,而生成是在完成治疗后进行数据的推送。这个过程是实时的,因此就需要考虑性能的问题,同时不能影响主流程。因此使用异步进行数据的推送,同时对生成的pdf需要进行加密,放入xml中。而提前的数据信息使用并行流的方式对数据进行组装。这里主要解决推送过程的方式。下面是最近的需求和解决的思路和方式。
SpringFactoriesLoader加载器加载指定ClassLoader下面的所有的META-INF/spring.factories文件,并将文件解析内容存在Map<string,list>中。然后通过loadFactoryNames传递过来的class的名称从map中获取该类的配置列表。通过Set集合进行去重操作。执行过滤组件操作,而这些操作都是在AutoConfigurationImportFilter接口下的组件实现的,也即FilterSpringBootCondition实现抽象类的。下面有OnBeanCondition、OnClassCondition、OnWebApplic
创建大数组实现对象:里面包含的信息公共初始化: 初始化页工厂:索引页工厂、数据页工厂、元数据页工厂,初始化数组索引、初始化数据页索引,通过队列前置索引页工厂获取索引页,获取队列front索引buffer,获取front,也即索引。这个实现和kafka是类似的,也即需要有相关页信息 入队列:进行入队操作是一个追加的操作,首先判断容量是否够,不够,则进行扩容操作。通过缓存拿到映射页实现,然后通过映射页。再通过锁,仅锁定创建页,索引用完后进行移除操作,映射页面实现,使用双向校验,如果为空,则创建页索引对象,通过索引拿到文件名称,然后通过读写通道进行读写操作。使用fileChannal调用映射方法获取
如果我们遇到的缓存比较大时,此时又需要考虑怎样的缓存设计呢? 此时由于缓存的消息或者信息比较大时,同时呈现成批量时,可以基于消息,考虑使用文件存储的方式进行,此时可以考虑NIO的处理方式,使用FileChannel和MappedByteBuffer或者堆外内存的方式,此时基于块状消息处理,使用缓冲区或者使用通道。此时的处理不经过用户态,因此性能上也是比较高的。 当然基于LinkedHashMap也可以实现LRU缓存设计。LinkedHashMap本身就是基于HashMap+双向链表实现的。
基于interceptor可以实现sql的完整打印,除了实现打印之外。其实还可以实现分页和排序,下面的分页和排序基于aop+mybatis的interceptor实现。其本质还是对mappedStament的boundSql进行增强。 下面的项目来源于github,通过这个我们可以很好的学习mybatis中插件interceptor的使用。
pmq是信也科技开源的一款消息中间件,虽然没有RocketMQ和Kafka出名,但是里面的代码还是有值得我们学习的地方的。 pmq的源码里面很多套路还是值得学习的,说实话,这些都是可以用到项目里面的。下面的代码来源于pmq。 首先安装好maven、mysql,对下载下拉的包进行打包: 如果遇到时区问题,则可以调整时区问题。 1.MqBootstrapListener 观察者模式的使用
kafka分为客户端和服务端,通常我们知道broker是服务端,而生产者和消费者作为客户端。因此在服务端就必定需要解决并发和网络IO的问题。因此不可避免需要用到SocketChannel和ServerSocketChannel,可以看到kafka就使用了ServerSocketChannel,采用Netty来解决这个问题,这里socketServer采用了1个Acceptor,多个Processor。同时将请求发送到请求通道RequestChannel中。而我们知道RequestChannel中有一个请求队列和多个响应队列,通常响应队列是3个,这个参数是在kafka的配置中配置的。通过kafk
这里思考问题,什么时候会用到延迟组件,同时哪些时候会用到延迟组件,同时为什么要用延迟组件? 从kafkaApi中,我们可以知道具体的逻辑实现都是在这里实现的: DelayedOperation调用过程 同时基于时间轮进行时间过期的检测操作。 也即从这里我们可以看到DelayedProduce是协助副本管理器完成相应的延迟操作的,而副本管理器则主要是完成将生产者发送的消息写入到leader副本、管理follwer副本与leader副本之间的同步以及副本角色之间的转换。在上面的生产延迟中,我们可以看到在消息写入leader副本时需要DelayedProdue的协助。同时我们也可以看到:当生产请求的
在kafka启动时,首先执行的broker的操作,然后接着会执行生产者操作,接着将生产者的消息放入到存储中,此时生产者和broker会进行交互,而消费者发送消息,接着消费者会和broker交互。前面我们知道kafka在kafkaApi中会处理具体的请求。首先,我们再次来看kafkaApi的handle,可以看到其入参的参数是RequestChannel.request,也即我们需要找到ReuqestChannel,回忆在RocketMQ中,我们也可以看到请求的参数:ChannelHandlerContext和request在Processor中。也即request.header.apiKey匹
前面我们已经学习了特质类似接口,其可以被继承,同时如果需要继承多个特质的话,则需要使用extends…with…进行继承。其类似java中的接口和抽象方法的结合体,但又比java中的其要强大,因为其可以定义抽象字段和普通字段、抽象方法和普通方法。而在java中接口中可以定义常量,不能定义变量。同时特质还可以继承class类,而在java中接口通常是用来实现的。 Object继承trait
放入消息之后,进行操作体现在asyncSendMessage中。将消息以异步方式存储到存储器中,处理器可以处理下一个请求,而不是在结果完成后等待结果,以异步方式通知客户端。此时可以看到asyncPutMessage的操作中会进入到CommitLog中,此时进行提交日志操作,此时会执行写入到ByteBuffer中,然后刷盘到硬盘中。同时执行统计操作,进行HA同步。
首先从github中拉取Rocketmq的代码,进行运行。 1.由于rocketmq需要依赖nameServer,类似于zookeeper。首先启动时,配置好NamesrvStartup的环境变量信息,也即rocketmq的ROCKEMQ_HOME与你的项目对应。接着就可以启动了。
前面我们已经知道CompletionService是可以解决Future带来的阻塞问题的,同时我们除了前面我们看到的take方法之外,还可以使用poll方法,这样可以使你的程序免受阻塞之苦。因为poll方法也是无阻塞性的。同时在kafka的源码中,我们如果使用消费者的话,可以看到会使用一个基于future的poll方法。同时我们可以在dubbo的新版本2.7中,可以看到其异步编程采用的就是我们要介绍的CompletableFuture。因此,我们有必要了解CompletableFuture,同时其也是真正意义上的异步编程的实现。
如果是多个对象呢?那怎么解决这个问题? 此时就可以用到: multiRequestBodyDemo(@MultiRequestBody("dog") Dog dog, @MultiRequestBody("user") User user) 这种方式进行接收了。但spring boot是不支持这种方式的。因此,就需要自己写一个解析器来解析这样的传入方式和接收的方式。通常,比如我们有分页和对象时,就可以采用这种方式进行接收。
2.Mysql的逻辑架构 其可分为三层: 最上层为基于网络的客户端/服务端的工具或服务类似的架构。比如:连接处理、授权认证、安全等。每个客户端连接都会在服务器进程中拥有一个线程,同时对其进行认证。 第二层:大部分Mysql的核心服务功能都在这一层,包括:解析、分析、优化、缓存以及所有的内置函数,所有跨存储引擎的功能都在这一层实现:存储过程、视图、触发器等。Mysql首先会解析查询,并创建内部数据结构(解析树),然后对其进行各种优化,包括重写查询、决定表的读取顺序,以及选择合适的引擎等。同时可以请求优化器解释(explain)优化过程的各个因素,提供优化参考。 第三层:包含了存储引擎,存储引擎负
首先我们知道Dubbo是一个RPC框架,因此解决的问题是服务治理,这个治理是解决服务注册和调用列表的维护治理,产生注册中心维护服务列表和更新,同时方便远程调用和本地调用是一样的,同时方便解耦,我猜这个是dubbo框架产生的初衷吧。而服务的调用和服务的引用是采用网络编程框架Netty,由于其基于NIO,因此其具有很高的性能。同时因为服务的调用和服务的引用,与IM通信或者我们看到的Http请求三次握手是类似的,采用的是应答模式。
首先,我们知道dubbo在以前都是基于zookeeper作为配置中心的,同时是建立在spring基础之上的。因此,就需要思考一些问题: 首先dubbo是怎样和spring集成的,也即dubbo集成在spring上需要具备什么条件?接着dubbo作为一个服务治理的微服务框架,那它的生产者和消费者与注册中心怎样进行交互的。 dubbo是基于spring的基础之上进行开发的RPC框架。需要和spring整合,必然就需要按照Spring解析默认标签和自定义标签的方式进行。而在Spring中,我们知道在Spring中是在ParseBeanDefintions(Elemen
Producer:生产者,数据的发布者,将消息发布到kafka的topic中,broker接收到生产者发送的消息后,broker将该消息追加到当前用于追加数据的segment文件中。生产者发送消息,存储到一个partition中,生产者也可以指定数据库存储的partition. Consumer:消费者,可以从broker中读取数据,消费者可以消费多个topic中的数据.同时每个消费者都属于一个特定的消费组(ConsumerGroup).
由于业务需要,需要在接口中传递参数,调用消息中心的短信接口,进行短信的发送。如果使用Feign接口,没有携带token时,调用Feign接口,可以正常调用,但是如果携带token,就会出现appId拼接参数的情况。appId出现拼接时什么原因导致的呢?
在整合在项目中,我们通常需要基于事件去触发另外的业务逻辑动作的完成。也即在我们做需求时,通常会基于不同的事件码来完成业务处理,此时可以考虑将其单独处理,基于观察者模式+策略模式。还有一种如果当Spring完成Bean的初始化,需要做一些特殊处理,此时除了使用InitializingBean,还可以使用监听完成一些定制化的初始化动作,实现ApplicationListener<ContextRefreshedEvent>。
内容来源于alibaba的开源项目ageiport,场景:如果需要基于集群节点进行均摊,对数据进行处理分而治之的话,就可以采用。
想实现一个轻量级的延迟队列,此时可以考虑基于Redis来实现,如果当前的基础设施不是阿里云Mq,开源的RocketMQ只有18个等级,1ms~2h的18个等级。当然商业版的阿里云可以实现精度的延迟。
一个完整的工作流生命周期会经过5步,并且迭代循环。 定义:工作流生命周期总是从流程定义开始。这个过程包括收集需求,将其转化成流程定义,也就流程图、相关变量、角色定义。 发布:由开发人员打包各种资源,然后在系统管理中发布流程定义。包括:bpmn.xml、自定义表单、任务监听类等。 执行:具体的流程引擎按照事先定义的流程处理路线以任务驱动的方式执行业务流程。 监控:此阶段是依赖执行阶段。业务人员在办理任务的同时收集每个任务(Task)的结果,然后根据结果做出相应处理。 优化:在此阶段,一个完整的流程已经结束,或许能满足业务需求,或者需要优化。
TinyId生成器 的nextId、getNextSegmentId,一个是获取segmentId,一个是获取nextId。也即生成的过程中,首先会生成一批数据的maxId和delta、reminder等信息,然后获取nextId。而这个过程中,首先需要有idGenerator对象。目前可以看到其多次使用double check,基于单例模式。同时基于缓存,使用了抽象工厂模式,获取idGenerator的时候。
1)如果要实现一个动态线程池,首先需要考虑的是将线程池的相关配置信息外置。这样出现问题的时候,能够基于配置修改,实现热部署。修改配置后,就能生效。因此,可以考虑的配置方式有多种:nacos、apollo、zookeeper、consul、etcd等。 2)如果线程池出现问题或者完成修改后,能够基于监控的信息,进行通知和告警。这样就需要考虑通知和告警的方式的多样性:比如基于钉钉、微信、飞书、电子邮件等渠道进行通知和告警。
首先需要考虑涉及到哪些状态节点和哪些事件,如何方便状态节点的获取、状态节点如何串联起来呢?串联的方式下,如何拿到下一个状态节点?如果基于角色,如何实现? 我们知道工作流可以实现基于角色进行流程的流转,但是此时我们涉及到事件和状态,会出现多个分支,如果使用工作流实现,流程处理上,比如activiti上,可能比较复杂,因此考虑比较轻量级的状态机来实现的话,相对来说要方便一些。
前面说过,seata在做二阶段提交前会生成前镜像、执行sql、生成后镜像。那么首先需要做的是,有数据源进行连接,然后需要对表的元数据信息进行抽取。这样才可以进行前镜像以及后镜像的操作。
seata 一阶段:首先拦截sql,解析sql语句的语义,提取元数据,找到sql语句,在执行sql前生成前镜像,执行业务sql后,生成后镜像。生成seata事务锁数据,然后构建事务日志并插入事务日志表,注册分支事务。 二阶段:二阶段分支提交,删除保存的事务日志数据,完成数据清理。通过异步线程批量删除在二阶段提交的分支事务日志数据。如果是二阶段回滚操作,则通过事务协调管理器执行二阶段回滚,此时资源管理器会执行回滚一阶段已经执行的业务sql语句,还原数据。