没有需求，就没有价值

随着前段时间阿里语雀、滴滴生产事故的发生，从招聘信息来看越来越多的中小企业开始重视系统的稳定性建设。那么，系统的稳定性建设会涉及哪些方面呢？

这里可以根据用户等级拆分不同主题的队列，如免费版的topic和vip版的topic，里面调度逻辑一模一样，只不过对应不同的消费者，发送使用的账号可能也不同

SpringCloud体系有分布式配置中心和配置客户端组件，开发者可将开发、测试、生产不同环境下的配置文件，包括微服务配置文件发布到仓库，配置中心对外提供访问接口用于读取配置信息，配置中心可作为微服务注册到服务中心，配置客户端用于从配置中心读取配置文件的特定信息。配置中心所需依赖 <dependency&amp

网关过滤器是配置在具体服务下的，只作用于配置对应的服务。如果参数是key-value结构的，可以实现org.springframework.cloud.gateway.filter.factory.AbstractNameValueGatewayFilterFactory抽象类，实际上也是继承了AbstractGatewayFilterFactory。如果需要自定义，同样实现org.springframework.cloud.gateway.filter.GlobalFilter，重写filter方法。

事务的传播机制，枚举定义了7种，如果不指定，默认是REQUIRED，比如父方法调用子方法，如果父方法已经有事务了，子方法就共用父方法的事务。如果子方法修改了事务的传播机制，改成REQUIRES_NEW，就不会共用父方法的事务，而是重新创建一个新的，实现上就是新建一个数据库连接去进行数据库操作，两个连接不互相影响。事务的隔离级别，MySQL的事务隔离级别都知道是4种，默认是RR，在一定程度上解决了幻读问题，有间隙锁、临键锁，容易导致数据库死锁，整个吞吐量也较低，所以有些并发高的业务或大厂会改成RC。

我们项目中多用MyBatis进行数据库的读写，开源的MyBatis-Plus框架对其进行了增强，使用上更加简单，我们之前的很多项目也是直接用的MyBatis-Plus。数据库操作的时候，简单的单表读写，我们可以直接在方法里链式组装SQL，复杂的SQL或涉及多表联合join的，需要在xml手写SQL语句，这些框架上怎么执行的呢？MyBatis其实用到了很多设计模式。MyBatis的二级缓存。

当我们的应用从一个大单体拆分成多个微服务之后，服务间调用有多少种方式？服务间调用如果出现超时，如果避免雪崩，即如何做限流熔断机制，原理是什么？

RocketMQ整个中间件可以分两块，一块是NameServer，保存注册上来的Broker地址信息，另一块是Broker，保存队列消息，直接与发送端或消费者通信。NameServer是一个AP模型的架构。关键代码？Broker是一个CP模型的架构。关键代码？主要涉及3个物理文件commit_log，单个文件1G大小，顺序写入，保持实际消息内容consume_queue，保存消息ID和队列消息存储的offset地址index_file，辅助队列消息轨迹搜索。

而在实际生产中，大部分中小企业不会自建云，容易故障踩坑，更多选择云托管。自主搭建Jenkins，Maven私服，Rancher管理k8s集群，好一点的会自主研发Devops平台加入审批流，上线前研发Leader审批版本发布、sql脚本等。阿里云效其实也是干这种事情，最近在上面走了下流程，可以给大家简单看下我成功运行过的流水线。一般互联网公司的发布流程大致也是这样，前面还会有git分支管理合并等，如果代码合并有冲突也会中断。在代码构建前会有代码扫描、安全扫描、漏洞检测、单元测试覆盖率等，代码扫描完可以查看

传统上，Java使用的是平台线程（Platform Threads），也就是操作系统线程，每个平台线程都对应一个操作系统线程，创建和切换成本较高，尤其是在高并发场景下，线程数量增多会导致资源消耗大，甚至可能引发性能问题。虚拟线程（Virtual Threads）是Project Loom引入的，旨在解决这些问题。虚拟线程是轻量级的，由JVM管理，而不是直接映射到操作系统线程。这使得可以创建大量的虚拟线程而不会显著增加系统开销。听起来这很适用于高并发的I/O密集型应用，比如Web服务器处理大量请求的情况。

传统做法是在任务执行前设置ThreadLocal变量，但线程池中的任务可能由不同的线程执行，导致主线程设置的ThreadLocal变量在任务线程中不可见。任务可能在另一个线程执行，该线程的ThreadLocal变量未被设置，导致任务无法获取到主线程的上下文。如果这个线程之前执行过某个任务，并且该任务设置了ThreadLocal变量，那么这些变量可能仍然存在于该线程中，导致后续任务访问到旧的数据，或者如果任务没有正确清理ThreadLocal变量，可能导致内存泄漏或数据混乱。

Spring框架支持多种Bean作用域，开发者可以根据需求选择合适的作用域。

它们可以帮助开发者集中处理异常，避免在Controller中重复编写异常处理逻辑。Spring MVC 提供了多种方式来处理异常，其中最常用的是。

Spring事务管理通过AOP实现，核心是。注解提供了丰富的事务控制属性，如传播行为、隔离级别、超时时间等。默认传播行为是REQUIRED，默认回滚行为是和Error。注意代理失效问题和异常处理。

分布式事务的核心挑战是无法通过本地事务保证全局一致性。常见的解决方案包括最终一致性、最大努力一致性、2PC、TCC、Saga等。最终一致性适合高并发场景，但需要设计补偿机制。强一致性方案（如2PC、TCC）适合对一致性要求较高的场景，但性能较低。

雪花算法的结构是由时间戳、工作机器ID和序列号构成。要确保全局唯一，必须保证每个节点的机器ID唯一，并且同一毫秒内序列号不重复。在分库分表的环境下使用雪花算法，机器ID的分配是关键。常见的做法是通过分布式系统协调，比如使用ZooKeeper或者数据库来分配唯一的机器ID，在启动时从外部服务获取ID，并持久化存储，防止重启后ID变化。另外，时间戳部分需要保证各节点的时钟同步，否则可能出现时间不一致导致ID冲突。

针对使用ShardingSphere分库分表后MySQL单表数据仍然过大的问题，以下是分步骤的解决方案：首先明确单表数据量过大的具体原因：2.2 增加分片数量若当前分片数为，可扩容至或更高，需配合数据迁移工具（如ShardingSphere-Scaling）平滑迁移。动态分片：设计支持动态扩容的分片规则（如按范围分片时预留分片空间）。2.3 多维度分片组合分片策略：例如同时按和分片，避免单维度热点。**3. 冷热数据分离3.1 归档历史数据将历史数据（如3年前订单）迁移至归档

灵活选择子查询、JOIN或窗口函数。：JOIN通常比IN子查询更高效，尤其是关联字段有索引时。：单次表扫描 + 窗口函数计算，时间复杂度O(N)。：对每条记录执行子查询，时间复杂度O(N²)。：确保JOIN字段有索引，避免笛卡尔积（如。：窗口函数只需一次表扫描，避免嵌套查询。在重写SQL语句时，需结合。

ICP：优化复合索引的非前导列过滤，减少回表。覆盖索引：直接通过索引返回数据，避免IO开销。索引跳跃扫描：弥补缺失前导列的查询，避免全表扫描。实践建议：通过EXPLAIN分析执行计划，结合业务场景设计索引，优先选择覆盖索引，必要时启用ICP或Skip Scan。

任意时间段的慢sql数量，具体的sql语句和参数，执行次数、执行时间和总耗时等。以下简述如何应用mysql自身集成的命令和第三方工具统计慢sql，定位瓶颈。

本文主要讲述通过Flink将数据以Paimon格式写入外部对象存储，过程中各种问题的处理、数据存储形式以及如何通过doris读取外部对象存储上面的分片数据。

Canal是通过解析MySQL的binlog来获取数据变更事件的，然后将这些变更事件发送到下游，比如Redis。在同步的过程中需要解决实时性和一致性的问题。首先，实时性方面，可能涉及到Canal本身的处理速度，比如是否及时解析binlog，以及下游处理的速度，比如Redis写入是否够快。此外，网络延迟也是一个因素。一致性方面，可能需要确保数据变更的顺序正确，以及事务的原子性，比如一个事务内的多个操作是否被正确处理。

当表的数据量非常大，达到几千万甚至上亿行时，全表扫描会很慢，这时候分区可以帮助缩小扫描范围。比如，在一个电商系统中，订单表可能按月份分区，这样查询某个月的订单时，只需要扫描对应的分区，而不是整个表。或者在日志系统中，按天分区，方便归档和删除旧日志。另外，如果数据有明显的分区键，比如时间字段，按时间分区可以方便地管理历史数据，比如删除旧数据时直接删除整个分区，效率更高。当然，分区键的选择不当可能导致性能问题，或者分区过多带来的管理复杂性。分区表是将一个大表分成多个较小的、更易管理的部分，每个部分称为一个

悲观锁：优先保证数据强一致，以性能为代价，适合短事务、高冲突场景。乐观锁：以重试成本换取高并发能力，适合长事务、低冲突场景。选型核心：根据业务冲突概率、一致性要求及系统架构（如分布式环境）综合决策。

分库分表主要是为了解决单库单表的性能瓶颈，但拆分后数据分散在不同库和表中，这就导致了跨库查询和分布式事务的问题。

在 高并发场景和 微服务架构中，合理配置和优化连接池对系统性能和稳定性至关重要。

本文演示了Doris开发环境部署与过程中的问题处理，最后结合Go开发了数据埋点接口，演示数据写入和读取的实战流程，为后面湖仓一体的落地打下基础。