Activiti7 2024-10-23 ll# 工作流引擎Activiti7 多数互联网和IT公司里面用的技术，钉钉、飞书等效能工具、企业OA、ERP、CRM 需求背景 公司规定连续加班3天，去按摩可以报销一定比例的费用。 什么是工作流(WorkFlow) 就是通过计算机对业务流程自动化执行管理。 主要解决的是使在多个参与者之间按照某种预定义的规则自动进行传递文档或任务的过程,促使此目标的实现 企业日常中很多工作流程，比如：请假流程、报销流程、报价处理、合同审核 使用行业 消费品行业，制造业，电信服务业，银证险等金融服务业，物流服务业，物业服务业 物业管理，大中型进出口贸易公司，政府事业机构，研究院所及教育服务业等，特别是大的跨国企业和集团公司。 具体应用 关键业务流程：合同审核、客户电话处理、供应链管理等 行政管理类:出差申请、加班申请、请假申请、用车申请、各种办公用品申请 等凡是原来手工流转处理的行政表单。 财务相关类：付款请求、应收款处理、日常报销处理、出差报销、预算和计划申请等 特殊服务类：贸易公司报关处理、物流公司货物跟踪处理等各种通过表单逐步手工流转均可应用工作流软件自动规范地实施 基于上面的需求，就....
Redis分布式锁同步问题-Redlock 2024-07-10 分布式锁知识回顾 业务场景 优惠券领券限制张数 商品库存超卖 …… 起因 为了防止分布式系统中的多个进程之间相互干扰，我们需要一种分布式协调技术来对这些进程进行调度 利用互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题 实现目标 保证同一时间只有一个客户端可以对共享资源进行操作。 解决方案 Redis+Lua脚本 使用Redission框架(底层也是Lua+WatchDog机制) Redis主从架构下的锁同步问题 生产环境下一般都是集群部署，则存在主从架构下的锁同步问题。 节点一在主节点获取分布式锁成功。 Redis主节点再同步数据到从节点时宕机，数据没同步成功。 高可用机制则Redis从节点升级为主节点(但是没有锁信息)。 节点二在新的Redis上也成功获取分布式锁。 导致一个锁资源同时被两个节点获取，这个就出现了问题。 Redlock算法 官方文档 Redis从3.0版本开始支持 Redlock算法，通过在多个 Redis 节点上创建同一个锁来防止主从节点之间出现的数据不一致的问题。 在 Redlock 算法中，需要从多个Redis节点获取锁，并对取锁结果进行校验，从而避免....
XXL-Job 2024-01-02 定时任务 通过时间表达式这一方式来进行任务调度的被称为定时任务。 在平常的业务场景当中，经常有一些场景需要使用到定时任务，比如：在某个时间点会发送优惠券、发送短信等等的一些业务操作。又比如：比如一些支付系统，需要在每天的凌晨1点来进行对前一天的清算。 分类 单机定时任务 单机的容易实现，但应用于集群环境做分布式部署，就会带来重复执行 解决重复执行的方案有很多，比如加锁、数据库等，但是增加了很多非业务逻辑 分布式调度（分布式定时任务） 把需要处理的计划任务放入到统一的平台，实现集群管理调度与分布式部署的定时任务 叫做分布式定时任务 支持集群部署、高可用、并行调度、分片处理等 常见定时任务 单机：Java 自带的 java.util.Timer 类配置比较麻烦，时间延后问题 单机：ScheduledExecutorService 是基于线程池来进行设计的定时任务类，在这里每个调度的任务都会分配到线程池里的一个线程去执行该任务，并发执行，互不影响 单机：SpringBoot 框架自带 SpringBoot 使用注解方式开启定时任务 启动类里面 @EnableSc....
Kafka 2024-01-01 为什么要序列化？ 序列化：把对象转化为可传输的字节序列过程称为序列化。 反序列化：把字节序列还原为对象的过程称为反序列化。 如果光看定义我想你很难一下子理解序列化的意义，那么我们可以从另一个角度来推导出什么是序列化, 那么究竟序列化的目的是什么？ 其实序列化最终的目的是为了对象可以跨平台存储，和进行网络传输。而我们进行跨平台存储和网络传输的方式就是IO，而我们的IO支持的数据格式就是字节数组。 因为我们单方面的只把对象转成字节数组还不行，因为没有规则的字节数组我们是没办法把对象的本来面目还原回来的，所以我们必须在把对象转成字节数组的时候就制定一种规则（序列化），那么我们从IO流里面读出数据的时候再以这种规则把对象还原回来（反序列化）。 如果我们要把一栋房子从一个地方运输到另一个地方去，序列化就是我把房子拆成一个个的砖块放到车子里，然后留下一张房子原来结构的图纸，反序列化就是我们把房子运输到了目的地以后，根据图纸把一块块砖头还原成房子原来面目的过程。 MQ 使用场景 跨平台 、多语言、分布式事务、最终一致性 RPC调用上下游对接，数据源变动->通知下属 解耦：订单系统....
ShardingSphere-JDBC 2023-10-19 ShardingSphere Apache ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈，它由 JDBC、Proxy 和 Sidecar（规划中）这 3 款相互独立，却又能够混合部署配合使用的产品组成。 它们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如 Java 同构、异构语言、云原生等各种多样化的应用场景。 三大组件对比 ShardingSphere-Sidecar(规划中，简单知道就行) 定位为 Kubernetes 的云原生数据库代理，以 Sidecar 的形式代理所有对数据库的访问 通过无中心、零侵入的方案提供与数据库交互的啮合层，即 Database Mesh，又可称数据库网格 ShardingSphere-JDBC 它使用客户端直连数据库，以 jar 包形式提供服务 无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis,或直接使用 JDBC 支持任何第三方的数据库连接池，如....
分布式事务 2023-10-12 分布式事务 在分布式条件下，相互关联的多个数据由于跨系统，彼此的事务之间不被感知，无法保证 如何实现分布式下的一致性 典型情况下是两个思路： 理想状态：直接像单机数据库事务一样，多个数据库自动通过某种协调机制，实现了跨数据库节点的一致性。 使用场景：要求严格的一致性，比如金融交易类业务。 强一致 : 数据库使用XA协议实现，不是所有数据库都支持XA协议 一般情况：可以容忍一段时间的数据不一致，最终通过超时终止，调度补偿，冲正等等方式，实现数据的最终状态一致性。 使用场景：准实时或非实时的处理，比如 T+1的各类操作，或者电商类操作。 弱一致 : 1) 不用事务，业务侧补偿冲正 2) 所谓的柔性事务，使用一套事务框架保证最终一致的事务 XA 分布式事务协议 基于第一个强一致的思路，就有了基于数据库本身支持的协议，XA 分布式事务。XA 整体设计思路可以概括为，如何在现有事务模型上微调扩展，实现分布式事务。 X/Open X/Open，即现在的 open group，是一个独立的组织，主要负责制定各种行业技术标准。X/Open 组织主要由各大知名公司或者厂商进行支持....
数据库拆分 2023-10-11 主从架构无法解决单节点容量问题 部分解决高可用 降低主库一部分读压力 无法解决容量问题 主从结构解决了高可用，读扩展，但是单机容量不变，单机写性能无法解决。 提升容量--> 分库分表，分布式，多个数据库，作为数据分片的集群提供服务。 降低单个节点的写压力。 提升整个系统的数据容量上限。 单机数据库已经无法适应互联网的发展 传统的将数据集中存储至单一数据节点的解决方案，在容量、性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景。我们在单库单表数据量超过一定容量水位的情况下，索引树层级增加，磁盘 IO 也很可能出现压力，会导致很多问题。 性能：由于关系型数据库大多采用 B+ 树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的 IO 次数增加，进而导致查询性能的下降；同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈。 可用性：从可用性的方面来讲，服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。 运维：当一个数据库实例中的数据达到阈值以上，....
