你知道BFF模式吗？解决了哪些问题？适用于哪些场景？
什么是BFF模式？BFF（Backend For Fronted），后端服务于前端。是一个API网关的特例，为特定的前端（移动端、Web端）提供定制化接口的聚合层。没有前端都有一个专属的BFF服务。 BFF解决了哪些问题？前端数据聚合提供一个聚合服务，避免了前端直接调用多个后端服务接口，减少了复杂性。BFF层从多个微服务中获取数据，进行转换、聚合，形成一个前端容易解析和易读的API数据格式。 前端API细粒度为不同的前端提供不同颗粒度的API，避免了一个大而全的接口。 协议转换数据转换层的功能。如果后端服务提供的API是一个RPC接口，可以通过BFF层进行协议转换为Restful风格接口。 安全和性能优化BFF层针对不同的前端进行认证鉴权、数据脱敏、缓存等，提供安全和性能优化。 BFF适用场景？多端应用iOS、Android、Web、小程序等多端应用，对后端数据结构差异大。 微服务拆分粒度较细后端微服务拆分粒度较细，前端直接调用会非常复杂。
如何通过Kafka实现死信队列？
什么是死信队列？存放那些无法被正确处理的消息。这些消息可能因为格式错误、业务逻辑异常、下游服务不可用导致。 Kafka中没有类似于RabbitMQ那样的内置死信队列。 如果通过Kafka实现死信队列？创建一个独立的专门用于存放消息的死信Topic 工作流程： 消费者判断失败：消费者处理消息时，判断消息无法被正常消费，例如格式错误、消费异常等。 消息转发：将原始消息发送到死信Topic。 死信消费者：启动一个独立的消费者组，专门消费死信消息。例如人工干预、日志记录等。 微服务架构中的作用 故障隔离： 避免因少量异常消息导致整个消费者组阻塞或崩溃。 错误分析： 集中管理异常消息，方便运维人员和开发人员分析错误原因。 数据修复与重试： 对于临时性错误，可以在DLQ中对消息进行修复后重新投递；对于永久性错误，则进行记录和人工处理。 提高系统韧性： 即使部分消息处理失败，也不会影响主业务流程的正常运行。
在Kafka中，你如何处理消息的重复消费和消息丢失问题？请结合实际场景说明
什么是消息重复消费？消费者订阅MQ消费时，收到多条消息内容一致的数据进行处理，对业务造成重复处理。 重复消费的原因有哪些？ 生产者重试发送 消费者提交偏移量失败导致重复拉取 如何解决重复消费？唯一ID每条消息的消息体内添加一个全局唯一ID字段（订单号、流水号），在消费数据时查看数据是否被处理过。 数据库唯一索引对业务关键字段创建唯一索引，重复插入会报错。 业务流程状态机业务流程通过状态机流转，每个操作只允许在特定的状态下进行操作。如果之前处理过流转到下一个状态，出现重复消息时因为状态不匹配不处理。 场景：购物支付，即时收到多次支付请求也只扣款一次。 什么是消息丢失？生产者生产的消息无法正确让消费者消费，中间过程出现消息丢失的现象。 消息丢失的原因有哪些？生产者丢失 如果ack设置为0，不等待broker响应确认，消息发送失败 网络抖动 Broker丢失 Leader宕机，消息未及时同步到Follower 消息未及时刷盘。pageCache -> 硬盘 消费者丢失先提交偏移量，后消费时出现异常 如何解决消息丢失？生产者端 ack=all，等待所有的ISR副...
千万级订单表新增字段怎么弄?
在千万级订单表中新增字段是一项高风险操作，需综合考虑数据量、业务连续性、查询性能等因素。 核心挑战 锁表风险 直接使用 ALTER TABLE 在 MySQL 5.7 及以下版本会导致表锁，阻塞读写操作，可能引发系统雪崩。 执行耗时 大表结构变更可能耗时数小时甚至数天（如数据复制、索引重建）。 资源消耗 高 I/O 和 CPU 占用，影响线上业务性能。 五大方案详解在线 DDL 工具（推荐）适用场景：MySQL 5.6+ 或兼容工具的环境。工具：pt-online-schema-change（Percona Toolkit）或 MySQL 8.0 的 INSTANT 操作。原理： 创建影子表（新结构）→ 复制原表数据 → 同步增量数据（通过触发器）→ 原子切换表名。 操作示例： 1pt-online-schema-change --alter "ADD COLUMN new_field VARCHAR(255)" D=database,t=order_table --execute 优点：几乎不停机，对业务影响小。缺点：需额...
如何定位&避免死锁?
如何定位&避免死锁？ 请问：死锁是如何产生的，如何预防？ 请问：死锁产生条件？ 请问：解决死锁的基本方法 ？ 请问：死锁产生的原因 ？ 什么是死锁？死锁是指两个或多个任务（比如线程、进程）彼此等待对方释放资源，结果谁也不愿意先让步，导致程序卡住不动。 如下图场景汇总： 任务A 拿着资源1，还要资源2才能继续。 任务B 拿着资源2，还要资源1才能继续。 谁都不肯放手自己手里的资源，于是都卡在那等着。 这种互相等待的情况就叫 死锁。 死锁通常有两种情况： 一种是使用 synchronized 内置锁 造成的， 另一种是使用 Lock 显式锁引起的。 下面我们分别来看这两种情况。 内置锁：synchronized死锁这是一个演示死锁的小程序。我们用两个线程和两把锁来展示什么是死锁。 基本流程： 1、 创建两个锁对象：lockA 和 lockB。2、 启动两个线程： 线程 1 先拿 lockA，然后尝试拿 lockB。 线程 2 先拿 lockB，然后尝试拿 lockA。 3、 每个线程拿到第一个锁之后都会停顿 1 秒钟，再去拿第二个锁。4、 最终...
服务与发现,该选择CP还是AP,为什么?
为什么要使用服务发现?在云原生+微服务时代，服务实例是 云原生的，动态部署的，我们甚至 不知道这个服务运行在哪台服务器上，不知道它的 IP 地址和端口 。 所以，现在的云原生+微服务架构下，情况变得复杂了： 服务的地址不是固定的，每次启动都可能不一样。 服务可能会自动扩容、缩容、重启或升级，导致地址频繁变化。 这就带来一个问题：怎么让client 客户端始终找到正确的服务server？ 为了解决这个问题，引入了一个叫“服务发现”的机制。 具体流程如下： (1) 服务注册：每个服务启动后，会把自己的网络地址告诉一个叫“服务注册中心”的地方。 (2) 定期更新：服务会定时发送“心跳”来告诉注册中心自己还活着。 (3) 服务下线：如果服务停止或者出问题，注册中心会把它从列表中移除。 (4) 客户端查询：当其他服务想调用它时，先去注册中心获取可用的服务地址。 (5) 负载均衡：客户端从多个可用实例中选一个，发起请求。 这样即使服务地址经常变，也能保证请求能正确发到可用的服务上。 微服务环境下，服务地址不固定。 需要通过“服务注册中心”动态管理服务位置。 客户端通过查询注册中...
慢SQL优化：从发现到解决的完整实战指南
慢SQL优化：从发现到解决的完整实战指南 在生产环境中，慢SQL就像是系统性能的隐形杀手，一条糟糕的查询可能拖垮整个数据库！本文将从慢SQL的识别、分析到优化，为你提供一套完整的解决方案。 🔍 什么是慢SQL？慢SQL（Slow Query）是指执行时间超过预设阈值的SQL查询语句。通常来说： 在线业务：执行时间超过100ms的查询 报表系统：执行时间超过5秒的查询 数据分析：执行时间超过30秒的查询 简单来说：慢SQL = 执行时间长 + 影响系统性能 慢SQL的危害 🎯 慢SQL识别方法MySQL慢查询日志开启慢查询日志： 12345678-- 查看慢查询配置 SHOW VARIABLES LIKE'%slow_query%'; SHOW VARIABLES LIKE'long_query_time'; -- 开启慢查询日志 SET GLOBAL slow_query_log ='ON'; SET GLOBAL long_query_time =0.1; -- 设置阈值为0.1秒 ...
Spring事务失效：原因分析与最佳实践
Spring事务失效：原因分析与最佳实践 在使用Spring事务时，你是否曾遇到明明添加了@Transactional注解，事务却不生效的情况？本文将深入分析Spring事务失效的常见原因，并提供相应的解决方案，帮助你正确使用Spring事务。 Spring事务基础回顾在深入分析事务失效原因前，我们先简要回顾Spring事务的基本概念和使用方式，这有助于更好地理解后续内容。Spring事务管理主要有两种方式：编程式事务和声明式事务。其中，声明式事务通过@Transactional注解实现，是我们最常用的方式。 1234567891011@Service public class UserService { @Autowired private UserMapper userMapper; @Transactional publicvoidcreateUser(User user) { userMapper.insert(user); // 其他操作... } } Spring事务的核心原理是...
JVM通关指南（八）JVM性能调优方法最全指南
JVM内存模型与关键参数内存区域划分： 堆内存(Heap)：新生代(Eden, Survivor0, Survivor1) + 老年代(Old Generation) 非堆内存：方法区(Metaspace)、JIT代码缓存、线程栈等 关键参数： 12345678-Xms 初始堆大小-Xmx 最大堆大小-XX:NewRatio 新生代与老年代比例-XX:SurvivorRatio Eden与Survivor区比例-XX:MetaspaceSize 元空间初始大小-XX:MaxMetaspaceSize 元空间最大大小-XX:+UseConcMarkSweepGC 使用CMS收集器-XX:+UseG1GC 使用G1收集器 垃圾回收机制JVM通关指南（三）吃透JVM的垃圾回收机制 - GC 垃圾收集器类型： 串行收集器：-XX:+UseSerialGC 并行收集器：-XX:+UseParallelGC CMS收集器：-XX:+UseConcMarkSweepGC G1收集器：-XX:+UseG1GC ZGC/Shenandoah：低延迟收集器 GC...
JVM通关指南（七）快速了解JVM的直接内存及常见问题与解决方案
直接内存(Direct Memory)直接内存(Direct Memory)是Java中一种特殊的内存分配方式，它不是在Java堆中分配，而是直接在操作系统的本地内存中分配。这部分内存不受Java堆大小限制，但会受到本机总内存的限制。 直接内存的特点 非堆内存：不占用JVM堆空间 零拷贝：可以减少数据在JVM堆和本地堆之间的复制 高性能：适合大内存操作 手动管理：需要显式释放，否则可能导致内存泄漏 不受GC管理：但会通过Cleaner或PhantomReference机制进行间接管理 直接内存的应用场景 NIO网络编程：SocketChannel、FileChannel等 高性能I/O：大文件读写 内存映射文件：MappedByteBuffer JNI调用：与本地代码交互 图形处理：OpenGL/DirectX绑定 科学计算：大规模数值计算 直接内存与堆内存比较 直接内存的核心类Java中主要通过java.nio.ByteBuffer来操作直接内存： 1234// 分配堆内存ByteBufferByteBuffer heapB...