zelxnxy-CSDN博客

转载 Flowable-UI体验及安装详解

绘制完成后，点击左上角的勾进行检查，查看是流程图绘制是否正确，有的时候流程节点之间的连线起点和终点可能并没有放入正确的位置，肉眼不容易看到，点击左上角的勾可以帮我们检查一下。下边没有什么需要配置的，我就设置了一下版本号。点击流程图就可以查看流程图的详情，点击右上角的下载按钮，就可以下载这个流程图对应的 XML 文件了，将 XML 文件拷贝到我们的项目中，就可以开始开发啦。以访问 idm 应用为例，在设置的时候，我们可以直接设置用户，也可以设置用户组，设置用户组的话，则这个组中的所有用户都能访问这个菜单项。

2023-12-27 11:58:38 582

转载 Flowable工作流之Flowable UI画工作流程图

首先下载文件 Flowable 相关的资源，进入 https://github.com/flowable/flowable-engine/releases，选择版本下载，下载下来是一个 ZIP 压缩包，解压压缩会看到如下目录结构。一句话，就是流程图这块有一个特别古老的规范，那就是 BPMN，而我们前面所说的无论是 Activiti、Flowable 还是 Camunda，都是支持这个规范的，所以呢，无论你使用哪一个流程引擎，都可以使用同一套流程图。工作流程图这块其实有一个统一的标准，那就是 BPMN。

2023-12-27 10:56:19 893 1

转载微服务服务之间远程调用的几种方式（RestTemplate、Eureka、Nacos、feign）

因此spring引入了一种新的配置文件：bootstrap.yaml文件，会在application.yml之前被读取，流程就是在项目启动时会读取先bootstrap.yaml和nacos上的配置信息，并整合到项目中，读取application.properties文件，创建spring容器并加载bean。nacos的负载均衡会优先考虑同一个集群中的服务实例进行调用，而在同一个集群中则是以随机的方式调用服务实例，这是可以选择同一个服务下不同实例的权重来改变负载均衡的选择。

2023-09-07 16:18:39 295

转载线上RPC远程调用频繁超时问题排查，大功臣Arthas

对外服务(下文统称服务A)处理终端一次请求的平均耗时在25ms左右，正常情况下并发量突增到服务所能承受的最高点时，最大耗时也在200ms以内，而一次请求中调用某个服务(下文统称服务B)的耗时必然会小于一次请求的处理耗时，所以我把服务A调用服务B的rpc调用超时设置为500ms，避免因调用阻塞等待导致请求堆积问题，所以本次服务崩溃并未看到文件句柄数达上限的异常，也因如此，只会有部分请求处理失败，不止于整个服务完全不可用。优化后，服务B的QPS有了显著的提升，像极了牙膏，挤挤又省几台机器。

2023-09-07 16:02:14 188

转载分布式事务解决方案，2PC与TCC的学习理解

概念：两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。在单体应用中，我们的某些操作需要同时对两个数据库进行操作，如用户支付了订单，需要对订单表库中的订单表增加一条新订单，同时需要对库存库中的库存表减少该物品的一个库存。分析问题：支付不成功、反而减库存成功，一般不存在这个问题，单体应用中两个操作在同一方法中，前一sql抛异常后一sql自然不会执行。支付成功，减库存失败（库存不够减、库存库挂了）。

2023-09-05 22:36:16 125

转载 AOP的实现原理及应用场景

在实际开发中，可能需要对没有实现接口的类增强，用JDK动态代理的方式就没法实现。采用Cglib动态代理可以对没有实现接口的类产生代理，实际上是生成了目标类的子类来增强。横向抽取思想：基于代理思想，对原来目标对象，创建代理对象，在不修改原对象代码情况下，通过代理对象，调用增强功能的代码，从而对原有业务方法进行增强！场景四：缓存优化（第一次调用查询数据库，将查询结果放入内存对象，第二次调用，直接从内存对象返回，不需要查询数据库）1.引入依赖，有spring，单元测，日志管理。

2023-09-05 22:32:23 108

转载微服务-服务调用（Ribbon）

不同配置的主机部署相同的服务时，可能会承受的压力是等效的，但由于主机配置不同，导致出现配置低的主机承受不了，配置高的主机绰绰有余，因此可以为配置高的主机多分摊一些压力，达到负载均衡。在微服务中，服务调用其它服务的api，就可以获取其数据，这样做的好处在于服务细分化，即将一个服务拆分为很多小服务。当服务调用者调用一个服务时，被调用的服务可能无法响应(宕机)，此时调用者无法进行对其调用，那么可以重试请求去调用另一个相同的服务。服务调用，即一个服务调用另一个服务，此过程可以分为服务调用者、服务提供者。

2023-09-05 22:21:38 69

转载锁的四种状态及升级过程

无锁、偏向锁、轻量级锁、重量级锁，这四种锁状态分别代表什么，为什么会有锁升级？其实在 JDK 1.6之前，synchronized 还是一个重量级锁，是一个效率比较低下的锁，但是在JDK 1.6后，Jvm为了提高锁的获取与释放效率对（）进行了优化，引入了偏向锁和轻量级锁，从此以后锁的状态就有了四种（无锁、偏向锁、轻量级锁、重量级锁），并且四种状态会随着竞争的情况逐渐升级，而且是不可逆的过程，即不可降级，也就是说只能进行锁升级（从低级别到高级别），不能锁降级（高级别到低级别）

2023-09-05 22:10:03 53

转载 Kafka如何保证消息的顺序性

也就是说生产者在写消息的时候，可以指定一个 key，比如说我们指定了某个订单 id 作为 key，那么这个订单相关的数据，一定会被分发到同一个 partition 中去，而且这个 partition 中的数据一定是有顺序的。2、kafka的partition的个数一定要大于消费组组员的个数，并且partition的个数对于消费组组员取模一定要为0，不然有些消费者会占用资源却不起作用；先后两条消息发送时，前一条消息发送失败，后一条消息发送成功，然后失败的消息重试后发送成功，造成乱序。

2023-09-05 22:08:34 432

转载 Kafka同步发送与异步发送消息

同步和异步指client(producer)是否收到leader给的ack后才发下一条（对于异步就是同一批），acks = 0， -1和1是指leader节点和follower节点数据同步的方式，可靠性机制，是保证数据能成功备份到其他节点的机制，二者是独立关系。可以提供回调方法，让broker异步的调用callback，告知生产者，消息发送的结果。异步方式，可以发送一条，也可以批量发送多条，特性是不需等第一次(注意这里单位是次，因为单次可以是单条，也可以是批量数据)响应，就立即发送第二次。

2023-09-05 09:24:40 160

转载 ES_深度分页概念与解决方案

但是elasticsearch将来一定是集群，例如我集群有5个节点，我要查询TOP1000的数据，并不是每个节点查询200条就可以了：因为节点A的TOP200，在另一个节点可能排到10000名以外了。当查询分页深度较大时，汇总数据过多，对内存和CPU会产生非常大的压力，因此elasticsearch会禁止from+ size 超过10000的请求。因此要想获取整个集群的TOP1000，必须先查询出每个节点的TOP1000，汇总结果后，重新排名，重新截取TOP1000。_id是文档的唯一标识，是不重复的。

2023-09-04 23:39:31 62

转载 MySQL慢查询及解决方案

10）索引一般用于记录比较多的表，假如有表DBInstance，所有查询都有userID条件字段，目前已知该字段已经能够很好的区分记录，即每一个userID下记录数量不多，所以该表只需在userID上建立一个索引即可，即使有使用其他条件字段，由于每一个userID对应的记录数据不多，所以其他字段使用不用索引基本无影响，同时也可以避免建立过多的索引带来的插入和更新的性能开销；当有大量慢查询并且SQL执行得越慢，消耗的CPU资源或IO资源也会越大，因此，要解决和避免这类故障，关注慢查询本身是关键。

2023-09-04 23:34:46 813

转载 mysql的explain主要看那些指标

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度（key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的）指出MySQL能使用哪个索引在表中找到记录，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用（该查询可以利用的索引，如果没有任何索引显示 null）显示这一步所访问数据库中表名称（显示这一行的数据是关于哪张表的），有时不是真实的表名字，可能是简称，例如上面的e，d，也可能是第几步执行的结果的简称。

2023-09-04 23:27:03 101

转载 Spring中最常用的11个扩展点

我们一说到spring，可能第一个想到的是 IOC（控制反转）和 AOP（面向切面编程）。没错，它们是spring的基石，得益于它们的优秀设计，使得spring能够从众多优秀框架中脱颖而出。除此之外，我们在使用spring的过程中，有没有发现它的扩展能力非常强。由于这个优势的存在，让spring拥有强大的包容能力，让很多第三方应用能够轻松投入spring的怀抱。比如：rocketmq、mybatis、redis等。今天跟大家一起聊聊，在Spring中最常用的11个扩展点。

2023-09-04 23:15:14 136

转载 Java多线程：JUC包下的常见类

更强大的唤醒机制. synchronized 是通过 Object 的 wait / notify 实现等待-唤醒. 每次唤醒的是一个随机等待的线程. ReentrantLock 搭配 Condition 类实现等待-唤醒, 可以更精确控制唤醒某个指定的线程.信号量个数为2，线程1和线程2先得到令牌，信号量为0，直到线程1释放了令牌，线程3才可以得到令牌，线程2释放了令牌，线程4才能拿到令牌。System.out.println("进入线程：" + currThread.getName());

2023-09-04 23:06:49 24

转载创建一个简单的WebService项目

(1).创建一个Webservice服务,即在eclipse中创建一个动态的web工程。2.右键单击helloClient, New-->Others --->Web Services-->Web Service Client。---------------------缺点------------------------5. 产生的Code中，有一个Java 文件以Proxy结尾，这个就是调用的Class了。----------------优点-----------------

2023-08-29 15:21:08 753

转载 HTTP协议

2、第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。3、第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 establised 状态。

2023-08-29 14:52:52 19

转载一文搞懂什么是RESTful API

在具体构建RESTful API的时候，需要对各种请求有更细致的认知，当然，本案例在实现各种请求的时候为了演示的便捷并没有完全遵循RESTful API规范，例如版本号等信息这里就不添加了，案例更侧重于使用SpringBoot实现这个接口。到这里RESTful API的介绍和实战就结束啦，本篇首先从RESTful的一些特点进行介绍，再到SpringBoot实战RESTful API，最后也说了一些RESTful API并不完美的地方，相信睿智的你对RESTful 一定有了很深刻的理解。

2023-08-25 17:31:28 40

转载 MinorGC、MajorGC、FullGC垃圾回收介绍

今天给大家继续分享MinorGC、MajorGC、FullGC相关知识，如有不对的地方欢迎指正！

2023-08-25 17:20:05 257

转载最全 MySQL 优化方法，从此优化不再难

说起MySQL的查询优化，相信大家收藏了一堆奇技淫巧：不能使用SELECT *、不使用NULL字段、合理创建索引、为字段选择合适的数据类型..... 你是否真的理解这些优化技巧？是否理解其背后的工作原理？在实际场景下性能真有提升吗？我想未必。因而理解这些优化建议背后的原理就尤为重要，希望本文能让你重新审视这些优化建议，并在实际业务场景下合理的运用。MySQL逻辑架构如果能在头脑中构建一幅MySQL各组件之间如何协同工作的架构图，有助于深入理解MySQL服务器。下图展示了MySQL的逻辑架构图。

2023-08-22 17:33:51 136

转载 MySql性能优化

MySQL是一个经过互联网大厂验证过的生产级别的成熟数据库，对于Mysql数据库本身的优化，一般是通过Mysql中的配置文件my.cnf来完成的，比如。针对运行慢的SQL，通过profile工具进行详细分析.可以得到SQL执行过程中所有的资源开销情况. 如IO开销,CPU开销,内存开销等.在高并发和高性能的场景中.MySQL数据库必然会承受巨大的并发压力，而此时，我们的优化方式可。读写分离设计，在读多写少的场景中，通过读写分离的方案，可以避免读写冲突导致的性能影响。库的应用全部无法响应。

2023-08-22 17:29:54 69

转载 config、apollo、nacos三种微服务配置中心深度对比

总的来说，Apollo和Nacos相对于Spring Cloud Config的生态支持更广，在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面，不过使用起来也要麻烦一些。Nacos使用起来相对比较简洁，在对性能要求比较高的大规模场景更适合。此外，Nacos除了提供配置中心的功能，还提供了动态服务发现、服务共享与管理的功能，降低了服务化改造过程中的难度。

2023-08-22 16:24:04 746 1

转载分布式ID

本文分析了各种生产分布式ID的算法的原理，以及他们的适用场景，相信你已经能为自己的项目选择好一个合适的分布式ID生成策略了。没有一个策略是完美的，只有适合自己的才是最好的。

2023-08-22 16:21:09 32 1

转载分库分表？如何做到永不迁移数据和避免热点？

1、hash取模方案在我们设计系统之前，可以先预估一下大概这几年的订单量，如：4000万。每张表我们可以容纳1000万，也我们可以设计4张表进行存储。那具体如何路由存储的呢？hash的方案就是对指定的路由key（如：id）对分表总数进行取模，上图中，id=12的订单，对4进行取模，也就是会得到0，那此订单会放到0表中。id=13的订单，取模得到为1，就会放到1表中。为什么对4取模，是因为分表总数是4。优点：订单数据可以均匀的放到那4张表中，这样此订单进行操作时，就不会有热点问题。

2023-08-22 16:19:36 319 1

转载简述常见三种GC和四种GC回收器

上图中有三个Region，每个Region被分成了多个Card，在不同Region中的Card会相互引用，Region1中的Card中的对象引用了Region2中的Card中的对象，蓝色实线表示的就是points-out的关系，而在Region2的RSet中，记录了Region1的Card，即红色虚线表示的关系，这就是points-into。筛选出CSet之后，G1将并行的将这些Region里的存活对象拷贝到其他Region中，这点类似于ParalledScavenge的拷贝过程，整个过程是完全暂停的。

2023-08-22 15:41:40 518 1

转载 JVM原理和调优

为什么要停止呢，如果不停止的话，意味着回收线程和用户线程同步执行，回收线程会认为用户线程的内存不是垃圾对象，因此不予理会，但如果用户线程很快执行完，它使用的对象就变成垃圾对象了，这时候回收线程不知道该如何处理，因此为了更好的控制内存，full gc的时候，必须暂停用户线程，回收完成后，再恢复用户线程。当old区内存满了后，就会触发full gc，但是发现引用还在（list还是运行），因此没法回收，但是死循环又一直在new对象，old区无内存可用，于是就OOM。就是让系统更加的丝滑，让用户体验变得更好。

2023-08-22 15:15:26 46 1

转载 HashMap底层数据结构

重点，记住：HashMap集合初始化容量必须是2的倍数，这也是官方推荐的，这是因为达到散列均匀，为了提高HashMap集合的存取效率，所必须的。// s1.equals(s2)结果已经是true了，表示s1和s2是一样的，相同的，那么往HashSet集合中放的话，放在HashMap集合key部分的，以及放在HashSet集合中的元素，需要同时重写hashCode方法和equals方法。假设有100个元素，10个单向链表，那么每个单向链表上有10个节点，这是最好的，是散列分布均匀的。（数组和链表的结合体。

2023-08-21 11:33:18 228 1

转载 Seata分布式事务框架详解

由上面描述可知，AT模式是强一致性模式，相应性能会有一定影响。例如在前一个事务回滚时，加入第二个事务抢占了本地锁，那么第二个全局事务一直无法抢占全局锁导致事务回滚。这也会造成一定的使用上的影响。

2023-08-17 17:26:32 191 1

转载 OceanBase简介及其与MySQL的比较

俗话说得好，“三个臭皮匠顶过一个诸葛亮”，假设总共有3台服务器，每个事务操作要求至少在2台服务器上成功，无论任何一台服务器发生故障，系统中还有1台包含了全部数据的服务器能够正常工作，从而做到完全不丢数据，并在30秒之内选出新的主库恢复服务，RPO等于0，RTO小于 30秒。不仅如此，OceanBase底层实现的Paxos高可用协议，在主库故障后，剩余的服务器会很快自动选举出新的主库，实现自动切换，并继续提供服务，在实际的生产系统中做到RTO在20秒之内。2、OB的存储结构使用的是两级的LSM tree。

2023-08-17 15:52:53 2330 1

转载 MySQL 大表优化方案

方案一：优化现有mysql数据库。优点：不影响现有业务，源程序不需要修改代码，成本最低。缺点：有优化瓶颈，数据量过亿就玩完了。方案二：升级数据库类型，换一种100%兼容mysql的数据库。优点：不影响现有业务，源程序不需要修改代码，你几乎不需要做任何操作就能提升数据库性能，缺点：多花钱方案三：一步到位，大数据解决方案，更换newsql/nosql数据库。优点：扩展性强，成本低，没有数据容量瓶颈，缺点：需要修改源程序代码以上三种方案，按顺序使用即可，数据量在亿级别一下的没必要换nosql，开发成本太高。

2023-08-17 15:12:45 154 1

空空如也

空空如也