- 博客(47)
- 收藏
- 关注
RSS订阅原创 Redis集群网络分区导致脑裂问题
Redis集群在发生网络分区（脑裂）时，确实可能导致数据丢失，其核心问题在于哨兵选举机制与客户端写入策略的交互。• 场景：主节点（Master）与哨兵（Sentinel）、从节点（Slave）之间的网络断开，但客户端仍能访问原主节点。◦ 网络分区时，若从节点不可达，主节点拒绝写入（牺牲可用性，保证一致性）。◦ 延长哨兵判定主节点下线的超时时间（默认30秒），避免瞬时网络波动误判。◦ 哨兵检测到主节点“失联”，触发故障转移，选举新的主节点。◦ 全量同步启动：原主节点清空自身数据，加载新主节点的数据。
2025-04-27 15:27:12
693
原创 Feign接口调用失败降级机制
使用 Sentinel 替代 Hystrix，支持流量控制、实时规则配置等高级功能。是否生效，或尝试手动添加日志框架配置（如 Logback）。通过上述验证和优化，可确保服务降级机制稳定生效。• 验证方式：在服务提供者端手动抛出异常（如。方法抛出异常时，Hystrix 会通过。• 检查 Hystrix 是否启用：确认。方法中的降级逻辑（记录日志并返回。建议：返回包含状态码和错误信息的。• 是的，当 Feign 调用。：在 Feign 接口上通过。• 启用 Hystrix：在。），观察消费者端是否返回。
2025-04-25 16:45:42
847
原创 ApplicationRunner的run方法与@PostConstruct注解
• 作用于 整个应用上下文，可访问所有已初始化的 Bean，适合全局任务（如多数据源同步、分布式锁初始化）。• 触发于 应用上下文完全启动后，所有 Bean 已初始化完成，但 HTTP 请求尚未处理。• 触发于 单个 Bean 的初始化阶段，在构造函数执行完成后、依赖注入完成后立即调用。• 仅作用于 当前 Bean，适合处理单个组件的初始化（如校验配置、建立连接）。：适合 Bean 级 的初始化，依赖注入完成后立即执行，简单高效。：适合 应用级 的全局初始化，可协调多组件，支持复杂逻辑。
2025-04-25 16:33:35
428
原创 MySQL InnoDB 存储引擎间隙锁（Gap Lock）
间隙锁（Gap Lock）是 MySQL InnoDB 存储引擎为解决幻读问题而设计的锁机制，其核心作用是锁定索引记录之间的“间隙”，防止其他事务在该范围内插入新数据。当事务 A 读取某个范围的数据后，事务 B 在该范围内插入新记录，事务 A 再次读取时会发现新增数据（幻影行）。结果：事务 B 的插入操作需等待事务 A 提交，避免统计结果不一致。• 缩小事务范围：减少事务持有间隙锁的时间，尽快提交或回滚。），InnoDB 会使用间隙锁锁定查询范围末端之后的间隙。结果：防止超卖且避免新商品插入干扰统计。
2025-04-25 14:21:55
432
原创 幂等性设计保障系统可靠性和数据一致性
实际应用中，需结合业务场景选择幂等策略（如唯一ID、状态机、分布式锁），并借助消息队列的幂等特性（如RocketMQ的事务消息）实现端到端的可靠性保障。• 消息去重：消费者端维护已处理消息的缓存（如Redis），通过唯一ID判断是否已处理。• 状态一致性：通过记录已处理消息的ID或状态（如Redis缓存），避免因重试导致数据状态多次变更。• 补偿机制：若事务提交失败，幂等设计允许通过补偿逻辑（如回滚）恢复一致性，而非重复执行。• Broker不可用时，生产者可能因未收到ACK而持续重试，导致消息重复投递。
2025-04-23 15:14:42
228
原创 Spring解决循环依赖
Spring 通过三级缓存和早期暴露机制解决了 单例 Bean 的 Setter/字段注入循环依赖，但受限于 Bean 作用域和注入方式。Spring 通过 三级缓存机制 解决循环依赖问题，其核心思想是 提前暴露未完全初始化的 Bean，允许依赖方在 Bean 完全初始化前引用其早期版本。• 填充属性时发现依赖 A，从三级缓存中获取 A 的工厂对象，生成 A 的早期引用。• A 从一级缓存获取已初始化的 B，完成属性填充和初始化，放入一级缓存。• 将 A 的早期引用放入二级缓存，移除三级缓存中的工厂对象。
2025-04-21 22:16:38
1006
原创 并发设计模式之双缓冲系统
双缓冲的本质是 通过空间换时间，通过冗余的缓冲区解决生产者和消费者的速度差异问题，同时提升系统的并发性和稳定性。数据一致性：如果切换时机不当，可能导致数据丢失或重复处理。切换开销：缓冲区切换时需要加锁和同步，可能引入短暂延迟。减少锁持有时间：消费者处理数据时释放锁，避免阻塞生产者。内存占用翻倍：需要维护两个缓冲区，内存消耗增加。添加优雅终止机制：通过标志位控制消费者线程退出。// 处理数据时无需持有锁。
2025-04-21 21:15:51
317
原创 CopyOnWriteArrayList核心源码解析
通过源码分析可见，CopyOnWriteArrayList 是典型的 空间换时间 设计，在特定场景下能显著提升读并发性能，但需谨慎评估内存和写操作开销。• 快照机制：迭代器保存创建时的数组引用，后续修改不影响已存在的迭代器。• 线程安全：迭代器基于创建时的数组快照，与后续修改无关。• 增量复制（如 Btrfs 的 extent 级复制）• 混合锁策略（小数据量用 CAS，大数据量用复制）• 写时复制：每次修改都创建新数组，旧数组保持可读。• 写操作性能显著低于 Vector（因全量复制）
2025-04-21 17:10:23
484
原创 环形缓冲区容量耗尽解决方案
• 分块存储：将环形缓冲区分割为多个独立子块（如每块128条数据）• 异步处理：主缓冲区数据写入磁盘或异步队列，备缓冲区承接新请求。• 触发条件：当缓冲区使用率超过阈值（如90%）时启动扩容。• 渐进扩容：按需分配（如每次增加25%），减少内存抖动。• 过期清理：后台线程定期清理超时数据（如每秒执行一次）• 倍增策略：新容量 = 原容量 × 2（简单高效）• 时间戳索引：每个数据项附加时间戳，按时间排序存储。• 切换策略：主缓冲区满时冻结统计，切换至备缓冲区。• 差值编码：存储相邻时间戳差值（节省空间）
2025-04-21 16:48:47
457
原创 使用有界线程池结合信号量限制任务提交速率
通过 BoundedExecutor 控制任务队列容量 和 Semaphore 限制并发执行数，可实现对任务提交速率的双重管控。这种组合既能避免内存溢出（队列有界），又能防止资源过载（并发受限），是构建高可靠系统的关键技术之一。表示当队列满时，由提交任务的线程直接执行任务（而非抛出异常），避免任务丢失。• 若信号量无许可 → 任务提交被阻塞，直到有许可释放。• 任务完成后释放信号量许可，允许新任务提交。• 并发任务数限制：通过信号量避免系统过载。• 线程池中的线程从队列中取出任务执行。
2025-04-21 15:43:31
1010
原创 高并发场景下重试策略的演进设计
问题定位：先描述传统滑动窗口的内存和计算瓶颈（结合场景数据，如“曾遇到10万QPS导致内存飙升40MB”）。• 原子指针更新：通过CAS操作实现无锁并发写入，避免锁竞争（吞吐量提升至120,000 QPS）。扩展思考：提及动态窗口调整（如QPS低时扩大窗口提升精度）、混合策略（结合令牌桶应对突发流量）。• 内存爆炸：每秒数万次请求需存储数万条记录，内存占用高达40MB（10万QPS场景）。数据结构：维护一个固定时间窗口（如1秒），记录所有请求的时间戳和超时状态。一、基础方案：传统滑动窗口的局限性。
2025-04-20 23:31:05
737
原创 Semaphore的核心机制
通过 许可计数器 和 同步队列 的机制实现并发线程数的限制。• 输出结果：前 3 个线程立即执行，后续线程按顺序获取许可，确保同一时刻最多 3 个线程并发。• 释放许可时，AQS 会从队列头部唤醒等待的线程，尝试重新获取许可。• 当线程因许可不足被阻塞时，会被放入 AQS 的同步队列 中等待。• 释放许可时，队列中的线程会被唤醒并尝试重新获取许可。• 公平性策略 通过队列顺序控制线程获取许可的优先级。• 许可数耗尽时，新线程会被阻塞，直到有许可被释放。加 1，并唤醒队列中的等待线程。
2025-04-20 23:21:26
1007
原创 双层Key缓存
双层 Key 缓存通过主备分离 + 异步更新的机制，在保障高可用的同时平衡了性能与一致性要求。其核心价值在于以空间换时间，适用于对短暂数据不一致容忍度较高的场景。实际应用中需结合业务特点，选择同步策略（如异步队列或定时刷新）并监控缓存命中率，以优化资源利用率。
2025-04-18 16:48:43
1033
原创 synchronized与内存屏障
内存屏障是实现线程安全的核心底层机制，其通过强制内存操作顺序和可见性，解决了多核 CPU 下的乱序执行与缓存不一致问题。开发者需理解其工作原理，结合锁状态升级、JVM 优化策略（如锁消除、锁粗化）设计高效并发程序。
2025-04-18 16:14:15
535
原创 深入理解synchronized
是 Java 中实现线程同步的核心机制，其底层实现依赖于 JVM 的监视器（Monitor）和对象头（Object Header）结构。
2025-04-18 15:49:32
530
原创 设计模式之责任链模式
责任链模式通过链式结构将请求处理逻辑解耦，其核心在于处理器间的动态链接和条件传递机制。实际应用中需根据场景选择单向或双向链表，并注意链长控制和调试优化。
2025-04-15 17:38:33
927
原创 灰度流量控制
维度Nginx阿里云 MSE适用架构单体/传统微服务架构云原生（K8s/ACK）微服务架构配置复杂度低（静态规则）中高（动态规则、全链路）全链路支持有限（仅网关层）完整（覆盖 RPC、MQ 等）运维成本低（自主管理）高（依赖云平台）典型场景简单灰度、A/B 测试复杂灰度、生产环境全链路验证。
2025-04-10 01:45:46
317
原创 MySQL切换PolarDB-X方案
切换期间延迟订单：通过双写和异步补偿确保最终写入 PolarDB-X。部分流量写入 MySQL：持续运行 DTS 同步任务，结合补偿机制处理剩余数据。核心原则•最终一致性：允许短暂延迟，但需保证数据最终同步。•可观测性：通过监控和日志实时跟踪数据状态。•回滚能力：若切换后异常，快速回滚到 MySQL 双写模式。
2025-04-10 01:35:47
609
原创 DTS增量数据同步
•无需代码修改：DTS 增量同步自动捕获 MySQL 变更并路由到 PolarDB-X，业务代码仅需控制 MySQL 写入开关。•核心配置：分片规则、主键冲突策略、序列接管。•风险控制：通过 DTS 监控和数据校验确保一致性，避免业务中断。
2025-04-10 00:59:27
962
原创 DTS全量数据同步
在使用阿里云 DTS（Data Transmission Service）进行数据同步时，必须先执行全量数据同步，再执行增量数据同步。这是由 DTS 的设计机制决定的，目的是确保目标数据库的数据完整性和一致性。
2025-04-10 00:39:30
758
原创 kafka存储原理
遍历Segment的.timeindex，找到第一个timestamp >= T_start的Segment。消费者在分区中查找偏移量为k的消息：找到偏移量为k的那个segment。log.segment.ms 指定单个日志段的最大存活时间，如果超过了时间，kafka会滚动到一个新段。kafka的消息是有索引的，便于快速定位。消息写入分区时，kafka会将这些消息写入段，写满了再创建一个新的段开始写消息。.log：存储消息内容（Segment文件）。log.segment.bytes表示分段的最大大小。
2025-04-08 23:32:31
697
原创 分布式数据库LSM树
刷盘触发：追加到一定程序，比如到了几MB，就生成一个MemTable，MemTable是跳表结构，当MemTable容量达到阈值时，转换为ImmutableMemTable，不可变跳表。clickhouse列式数据库，多核数据库，是做统计数据的，很容易发生读放大，因此他的设计是只有level 0，硬盘层面只有一层。分布式数据库是要做数据分布的，hash计算分布到某个节点上，比如存储视频播放，按照视频id做hash，大up主一个视频几千万播放，都会hash到同一个节点，造成数据严重倾斜，非常不均匀。
2025-04-08 22:20:07
974
原创 秒杀系统的性能优化
4核8G的机器，一般就是开200-300个工作线程，这是个经验值。每秒一个线程处理3-5个请求，200多个线程的QPS可以达到1000左右。线程不能太多，太多的话就会导致cpu负载过高，请求处理不过来，增加接口的延迟响应。JVM参数优化的核心在于尽量避免FGC，那么YGC次数肯定会变多，每次YGC时间大概几十毫秒的话，这个其实也没有太大的影响，基本接口还是在200毫秒左右。redis一个分片大概可以扛2-3wQPS，8个分片大概是20w的QPS。此时的redis的cpu负载大概是在50%左右，尚可以支撑。
2025-04-07 23:26:40
367
原创 redis高并发缓存架构与性能优化
Redis的刷盘频率，1s刷盘一次，否则写一条刷盘一条性能就非常差了。如果redis挂了或者重启，可能导致这1s内的数据没有持久化，因此也会造成锁丢失，别的线程也可以加锁成功。RedLock 依赖 Redis 实例的系统时钟计算锁的剩余有效期。若不同实例的时钟不同步（如时钟跳跃或漂移），可能导致锁被提前释放或无法释放。如果增加redis主节点数，那么加锁的性能更差，要给半数节点加锁，如果没有加成功，还要回滚。如果主节点挂掉，还没有同步到从节点，重新选举出主节点，那加锁就没有加到这个新的主节点上。
2025-04-06 21:40:07
605
原创 Redis集群核心原理剖析
slave节点发送psync命令同步数据，发送命令之前会跟master建立socket长连接。（发命令）master收到psync命令执行bgsave生成最新rdb快照数据。（做rdb）master开始记录rdb之后新数据到repl buffer缓存，就是记录一些写命令。（增量数据）master send rdb数据给slave。（发送rdb）slave清空老数据并加载主节点rdb数据。（跑rdb）master send buffer给slave。（发送增量数据）
2025-04-06 00:01:32
1212
原创 秒杀服务技术方案概要
巨大瞬时流量击垮服务造成瘫痪，或者机器资源高负载，整个请求链路的响应时间拉长。热点数据问题秒杀活动抢购的同一个商品，对存储系统是非常大的考验。刷子流量刷子通过程序实现接口的高频调用，挤占正常用户的抢购渠道。
2025-04-05 21:20:07
962
原创 数据库死锁故障产生
1.3.1. innodb_lock_wait_timeout 设置超时时间，当一个事务的等待时间超过设置的某一阈值，就对这个事务进行回滚，此时另一个事物就可以执行了。当事务A和事务B都持有间隙（1，+∞）的间隙锁，并且插入的时候获取插入意向锁是要等待对方事务释放gap lock，形成了循环等待的局面。除了唯一索引之外，其他索引查询都会获取gap lock和next-key lock。除此之外，插入的时候也会获取插入意向锁，插入意向锁与gap lock是互斥的。有两个事务，事务A和事务B。
2025-04-03 00:27:25
292
原创 缓存一致性
先更新数据库，再删除缓存。先更新数据库，删除缓存，然后线程读从库获取到旧值（因为主从延迟此时更新了主库，还没有同步到从库）写入缓存。并发导致数据不一致：多线程并发环境下，线程A先读取了旧值，然后线程B去更新数据库删除缓存，此时线程A将旧值写入缓存。操作原子性问题：由于数据库更新和删除缓存是两个独立的操作，无法保证原子性。数据临时不一致：删除缓存后，读取请求读取旧值，更新成功后，缓存被新值覆盖，但在此期间数据可能是过时的。先删除缓存再更新数据库，线程A删掉了缓存，但是线程B又读取旧值到缓存。
2025-04-02 16:47:21
165
原创 kafka消费者之多线程方案
在一个消费者组中，每个分区都只能被组内的一个消费者实例所消费。假设一个消费者组订阅了100个分区，那么他只能扩展到100个线程。，如果消息获取速度慢，增加获取消息的线程数；如果消息处理速度慢，增加消息处理的线程。Consumer获取到消息后，处理消息的逻辑是否采用多线程，由开发者决定。Kafka consumer其实是双线程，用户主线程和心跳线程。最大的缺陷是获取消息和处理消息分开了，不是同一个线程处理了，因此。而且线程池来消费会加长消费链路，导致位移提交变得困难，可能。完成的，从这个角度是单线程的。
2025-04-01 23:35:11
267
原创 一致性哈希算法
新增节点：仅影响相邻节点之间的数据，需将这部分数据迁移到新节点。比如AC之间新增B节点，那么需要将hash值在B与C之间的数据迁移到B节点。 逻辑连续性：环的顺时针方向保证了数据与节点之间关系的连续性，便于动态调整时局部迁移数据，而非全局重新分配。每个真实节点对应多个虚拟节点（如 node-A-01、node-A-02），通过向真实节点标识符添加后缀编号。唯一性：每个数据在环上的位置唯一，顺时针方向必然存在一个最近的节点（除非环上无节点），避免了定位歧义。真实节点的多个虚拟节点分布在环上的不同位置。
2025-03-31 15:29:48
135
原创 CPU飙高生产事故分析
晚上六点左右CPU告警，从日志量判断是在这段时间进行了大量的业务处理，追踪到是有人触发了订单推送的方法，时间跨度22天，订单量40w左右。
2025-03-24 21:09:50
294
原创 Netty如何解决空轮询BUG
Netty通过重建Selector实现状态重置，核心步骤包括注销旧Channel、创建新Selector、关闭旧Selector，最终使新Selector的selectedKeys()集合为空。这一机制强制下一次轮询必须依赖真实事件，彻底规避了旧Selector因残留Key导致的空轮询问题。
2025-03-22 16:13:57
325
原创 Netty核心类之NioEventLoopGroup
NioEventLoopGroup是一个线程池，负责管理和调度一组NioEventLoop线程。
2025-03-21 16:44:45
364
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人