goMars的学习随记

kafka基础概述Apache Kafka 是一个分布式流处理平台，最初由 LinkedIn 开发，并在 2011 年作为开源项目贡献给 Apache 软件基金会。Kafka 的设计目标是实现高吞吐量、低延迟、可扩展和容错的数据流处理和消息传递功能。 基础架构 主题（Topic） 定义：主题是消息的分类单位，用于组织和管理消息流。 分区（Partition）：每个主题可以划分为多个分区。分区是有序的、不可变的消息序列，消息在分区内有唯一的偏移量（Offset）记录消费位置。 为了配合多个分区的概念，提出了消费组的概念进行并行消费；并且一个分区只能由消费组的一个消费者进行消费，这样单个分区的消息就是有序的 生产者（Producer） 功能：生产者是将消息发布到 Kafka 主题的客户端。 工作方式：生产者将消息发送到特定的主题和分区，可以根据某种策略（如轮询、键散列）选择分区。 消费者（Consumer） 功能：消费者是从 Kafka 主题中读取消息的客户端。 消费者组（Consumer Group）：消费者可以组成一个组，共同消费一个主题的消息。每个消息只会被消 ...

驱动架构事件驱动架构概述事件驱动架构（Event-Driven Architecture，EDA）是一种软件架构模式，其中系统通过事件的生成、传递和处理来进行通信和工作。事件是系统中发生的动作或变化，可以是用户操作、传感器数据、系统状态改变等。 架构图： 优点： 解耦合：生产者和消费者通过事件代理进行通信，彼此不直接依赖。 扩展性：易于扩展，可以轻松添加新的事件生产者和消费者。 缺点： 复杂性：事件流和处理逻辑较复杂，需要仔细设计和管理。 一致性：处理异步事件时，需要额外考虑数据一致性和幂等性。 事件顺序性：需要额外的机制去保证事件的顺序性。 调试困难：由于系统是异步的，跟踪和调试问题可能更加困难。 组成部分 事件生产者（Event Producers）：生成事件的实体，如用户操作、传感器、服务等。 事件代理（Event Brokers）：负责接收、存储和分发事件的中间件，如Kafka、RabbitMQ等。 事件消费者（Event Consumers）：处理和响应事件的实体，如服务、函数、微服务等。 事件流（Event Streams）：事件在系统中流动的路径。 工作机制 ...

基因法分表概述随着数据量的迅速增长，单表存储和查询的效率问题愈加突出。传统的数据库在面对海量数据时，容易出现性能瓶颈和存储压力。为了解决这一问题，分表策略被广泛应用。基因法作为一种数据分表策略，通过将大表按照一定规则拆分成多个小表，从而提高查询效率和系统性能。 基因法的核心思想是根据数据的某些属性（如用户ID、时间戳等）进行哈希计算或者其他分配算法，将数据分布到不同的子表中。这种方法不仅能够有效平衡各个子表的数据量，还能提高查询的并发性能。 实现思路案例：例如对账户相关表（user、account、account_detail）按照user_id分库分表 执行user表的insert语句会被DAL数据代理（于ShardingProxy类似）所拦截 DAL会拉取数据库信息以及映射关系 再对user_id进行哈希算法进行分片，例如上图的66，DAL将其放在DB1中 计算出user_id的hash值，并返回 这样对于一套需要放一个库的表，主键id都在结尾加上这个hash值，之后就会很方便的路由到一个库 查询的时候，无论带上哪个表的主键都会顺利路由到一个库 好处： 方便一套业务表能够方 ...

跨库分页概述跨库分页是一种在分布式数据库系统中常见的技术挑战。在使用 ShardingJDBC 或其他数据分片技术时，数据通常会被分散到多个数据库实例或表中。跨库分页需要在这些分片中进行数据的合并和排序，以便返回一个统一的分页结果集。 跨库分页的挑战 数据分布不均匀：由于数据分布在多个分片中，直接进行分页查询可能会导致部分分片返回过多或过少数据，影响整体分页结果的准确性。 排序和合并：各个分片返回的数据需要进行全局排序和合并，以确保分页结果的正确性。这涉及到跨库的数据传输和合并计算。 性能问题：跨库分页通常会涉及多个数据库实例的查询操作，可能会导致性能瓶颈，尤其是在数据量较大或网络延迟较高的情况下。 解决方案全局视野法这种方法主要是通过构建全局视野法模拟单库操作的方法解决跨库分页 操作步骤： 在每个分片上执行相同的分页查询，并将结果集返回到应用层。 应用层将各个分片的结果集进行全局排序和合并，然后再进行分页处理。 案例： 将order by time offset X limit Y，改写成order by time offset 0 limit X+Y 服务层将改写后的SQL ...

ShardingJDBC分片策略概述ShardingJDBC 提供了多种分片策略，以适应不同的应用场景。这些策略通过将数据分布到多个数据库实例或表中，提高系统的性能和可扩展性。分片策略的选择对系统的查询性能、数据均衡性以及扩展性有重要影响。常见的分片策略包括范围分片、哈希分片、列值分片、连续分片、复合分片、广播表分片和异构分片。 分片策略详解自动分片算法这种算法会根据相应配置以及选择的不同算法，自动进行分片 取模分片算法（MOD）：取模分片算法通过对分片键进行取模运算来决定分片位置，适用于数据量大且均匀分布的场景 12345678sharding-algorithms: # 分片算法名 my_mod_algorithms: #类型 type: MOD # 算法配置 props: sharding-count: 2 哈希取模分片算法（HASH_MOD）：哈希取模分片算法通过对分片键进行哈希运算后再取模来决定分片位置，进一步均匀数据分布。 12345678sharding-algorithms: # 分片算法名 my_hashmod_algori ...

ShardingJDBC概述ShardingJDBC是一个开源的基于 Java 的分库分表中间件，用于处理关系型数据库的分片操作（供了水平分片和垂直分片两种分片方式）。它可以将数据按照某种规则分散存储在不同的数据库中，从而有效地解决了单一数据库在处理大量数据时的性能瓶颈问题。 ShardingJDBC定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。 它使用客户端直连数据库，以 jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。 适用于任何基于 JDBC 的 ORM 框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template 或直接使用 JDBC； 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, HikariCP 等； 支持任意实现 JDBC 规范的数据库，目前支持 MySQL，PostgreSQL，Oracle，SQLServer 以及任何可使用 JDBC 访问的数据库。 ShardingJDBC是以SDK的方式集 ...

SpringBoot自动装配概述使用 Spring 进行开发各种配置过于麻烦比如开启某些 Spring 特性时，需要用 XML 或 Java 进行显式配置。于是，Spring Boot 诞生了！Spring 旨在简化 J2EE 企业应用程序开发。Spring Boot 旨在简化 Spring 开发（减少配置文件，开箱即用！） Spring Boot只是简化了配置，如果你需要构建MVC架构的Web程序，你还是需要使用Spring MVC作为MVC框架，只是说SpringBoot帮你简化了Spring MVC的很多配置，真正做到开箱即用! 自动装配原理SpringBoot 定义了一套接口规范，这套规范规定：SpringBoot 在启动时会扫描外部引用 jar 包中的META-INF/spring.factories文件，将文件中配置的类型信息加载到 Spring 容器（此处涉及到 JVM 类加载机制与 Spring 的容器知识），并执行类中定义的各种操作。对于外部 jar 来说，只需要按照 SpringBoot 定义的标准，就能将自己的功能装置进 SpringBoot。通过注解或者一些简单 ...

线程池的监控概述线程池的监控是指对应用程序中使用的线程池进行实时跟踪、分析和管理的过程。线程池监控旨在确保线程池的有效运行，并及时发现并解决潜在的问题，以保障应用程序的性能和稳定性。 线程池监控最好支持三个地方： 动态调参：在运行时动态调整线程池参数，包括核心线程数、最大线程数、空闲线程超时时间、任务队列大小等 从前端接参，根据前端传的线程池名从map中获取线程池进行set方法动态修改（这个参数也可以持久化数据库） 通知报警：目前支持调参通知、活性、队列容量、拒绝策略、超时共六类通知报警维度，在运行时实时+定时检测，触发阈值进行推送 运行监控：定时采集线程池运行指标数据，提供 jsonlog、micrometer、endpoint、jmx 四种指标数据采集方式，可灵活选择 监控指标 核心参数： 线程池名称 基本配置：核心线程数、最大线程数 最大线程过期时间 任务队列类型、以及最大容量 拒绝策略 活跃度监控： 当前存在线程数、活跃线程数（通过get方法） 任务队列大小、任务队列剩余大小（通过get方法） 任务总数、完成任务数（通过get方法）、拒绝任务数（自定义拒绝策略 ...

LiteFlow规则引擎概述规则引擎是一种计算机系统，它允许将业务规则从应用程序代码中分离出来，以便更灵活、可维护、可扩展和可管理。这些规则可以是条件、动作和约束的组合，用于自动化决策和业务逻辑。规则引擎的主要目标是实现“业务逻辑与应用程序代码分离”的原则，从而使业务规则更易于修改和更新。 为什么需要规则引擎？ 灵活性：规则引擎允许业务规则在不修改应用程序代码的情况下进行动态更改。这提供了更大的灵活性，可以应对不断变化的业务需求。 可维护性：业务规则的维护和管理变得更加容易，因为它们可以独立于应用程序逻辑进行维护。 可扩展性：通过规则引擎，可以轻松添加新规则或调整现有规则，而无需大规模修改代码。 决策自动化：规则引擎可以用于自动执行决策，从而降低人为错误的风险并提高效率。 LiteFlow规则引擎 LiteFlow是一个非常强大的现代化的规则引擎框架，轻量，快速，稳定可编排的组件式规则引擎，融合了编排特性和规则引擎的所有特性。 优点： 组件化：让每一个业务片段都是一个组件，可以任意编排，组件与组件之间是解耦的，组件可以用脚本来定义，组件之间的流转全靠规则来驱动。 组件可实时热更替 ...

系统监控概述分布式系统的系统指标监控是确保系统正常运行、性能稳定和问题排查的关键方面之一。这种监控涵盖了一系列指标，用于衡量系统的各个方面，以及帮助管理员和运维团队识别问题、优化性能和规划资源。以下是分布式系统的一些常见系统指标监控的概述： 性能指标： 响应时间：衡量系统对请求的响应速度，通常以毫秒或秒为单位。 吞吐量：指系统在单位时间内能够处理的请求数量，通常以请求/秒来表示。 并发连接数：跟踪同时连接到系统的客户端数量。 资源利用率： CPU利用率：监控CPU的负载，以确保系统不超负荷。 内存利用率：跟踪系统内存使用情况，以防止内存泄漏或资源耗尽。 磁盘利用率：监控磁盘空间的使用情况，以确保不会出现存储问题。 网络带宽利用率：测量网络连接的带宽利用率，以确保网络性能。 错误和异常： 日志和异常信息：监控系统日志以及异常和错误报告，以识别问题和故障。 错误码计数：跟踪特定错误代码的出现次数，以便快速定位问题。 安全指标： 入侵检测：检测未经授权的访问或潜在威胁。 漏洞扫描：定期扫描系统以查找潜在的安全漏洞。 访问控制日志：记录系统访问以跟踪用户活动并排查潜在的安全问题。 ...