- 博客(29)
- 收藏
- 关注
RSS订阅原创 灰度流量控制
维度Nginx阿里云 MSE适用架构单体/传统微服务架构云原生（K8s/ACK）微服务架构配置复杂度低（静态规则）中高（动态规则、全链路）全链路支持有限（仅网关层）完整（覆盖 RPC、MQ 等）运维成本低（自主管理）高（依赖云平台）典型场景简单灰度、A/B 测试复杂灰度、生产环境全链路验证。
2025-04-10 01:45:46
290
原创 MySQL切换PolarDB-X方案
切换期间延迟订单：通过双写和异步补偿确保最终写入 PolarDB-X。部分流量写入 MySQL：持续运行 DTS 同步任务，结合补偿机制处理剩余数据。核心原则•最终一致性：允许短暂延迟，但需保证数据最终同步。•可观测性：通过监控和日志实时跟踪数据状态。•回滚能力：若切换后异常，快速回滚到 MySQL 双写模式。
2025-04-10 01:35:47
574
原创 DTS增量数据同步
•无需代码修改：DTS 增量同步自动捕获 MySQL 变更并路由到 PolarDB-X，业务代码仅需控制 MySQL 写入开关。•核心配置：分片规则、主键冲突策略、序列接管。•风险控制：通过 DTS 监控和数据校验确保一致性，避免业务中断。
2025-04-10 00:59:27
927
原创 DTS全量数据同步
在使用阿里云 DTS（Data Transmission Service）进行数据同步时，必须先执行全量数据同步，再执行增量数据同步。这是由 DTS 的设计机制决定的，目的是确保目标数据库的数据完整性和一致性。
2025-04-10 00:39:30
702
原创 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
688
原创 分布式数据库LSM树
刷盘触发：追加到一定程序，比如到了几MB，就生成一个MemTable，MemTable是跳表结构，当MemTable容量达到阈值时，转换为ImmutableMemTable，不可变跳表。clickhouse列式数据库，多核数据库，是做统计数据的，很容易发生读放大，因此他的设计是只有level 0，硬盘层面只有一层。分布式数据库是要做数据分布的，hash计算分布到某个节点上，比如存储视频播放，按照视频id做hash，大up主一个视频几千万播放，都会hash到同一个节点，造成数据严重倾斜，非常不均匀。
2025-04-08 22:20:07
954
原创 秒杀系统的性能优化
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
344
原创 redis高并发缓存架构与性能优化
Redis的刷盘频率，1s刷盘一次，否则写一条刷盘一条性能就非常差了。如果redis挂了或者重启，可能导致这1s内的数据没有持久化，因此也会造成锁丢失，别的线程也可以加锁成功。RedLock 依赖 Redis 实例的系统时钟计算锁的剩余有效期。若不同实例的时钟不同步（如时钟跳跃或漂移），可能导致锁被提前释放或无法释放。如果增加redis主节点数，那么加锁的性能更差，要给半数节点加锁，如果没有加成功，还要回滚。如果主节点挂掉，还没有同步到从节点，重新选举出主节点，那加锁就没有加到这个新的主节点上。
2025-04-06 21:40:07
590
原创 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
1201
原创 秒杀服务技术方案概要
巨大瞬时流量击垮服务造成瘫痪，或者机器资源高负载，整个请求链路的响应时间拉长。热点数据问题秒杀活动抢购的同一个商品，对存储系统是非常大的考验。刷子流量刷子通过程序实现接口的高频调用，挤占正常用户的抢购渠道。
2025-04-05 21:20:07
951
原创 数据库死锁故障产生
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
285
原创 缓存一致性
先更新数据库，再删除缓存。先更新数据库，删除缓存，然后线程读从库获取到旧值（因为主从延迟此时更新了主库，还没有同步到从库）写入缓存。并发导致数据不一致：多线程并发环境下，线程A先读取了旧值，然后线程B去更新数据库删除缓存，此时线程A将旧值写入缓存。操作原子性问题：由于数据库更新和删除缓存是两个独立的操作，无法保证原子性。数据临时不一致：删除缓存后，读取请求读取旧值，更新成功后，缓存被新值覆盖，但在此期间数据可能是过时的。先删除缓存再更新数据库，线程A删掉了缓存，但是线程B又读取旧值到缓存。
2025-04-02 16:47:21
160
原创 kafka消费者之多线程方案
在一个消费者组中，每个分区都只能被组内的一个消费者实例所消费。假设一个消费者组订阅了100个分区，那么他只能扩展到100个线程。，如果消息获取速度慢，增加获取消息的线程数；如果消息处理速度慢，增加消息处理的线程。Consumer获取到消息后，处理消息的逻辑是否采用多线程，由开发者决定。Kafka consumer其实是双线程，用户主线程和心跳线程。最大的缺陷是获取消息和处理消息分开了，不是同一个线程处理了，因此。而且线程池来消费会加长消费链路，导致位移提交变得困难，可能。完成的，从这个角度是单线程的。
2025-04-01 23:35:11
174
原创 一致性哈希算法
新增节点：仅影响相邻节点之间的数据，需将这部分数据迁移到新节点。比如AC之间新增B节点，那么需要将hash值在B与C之间的数据迁移到B节点。 逻辑连续性：环的顺时针方向保证了数据与节点之间关系的连续性，便于动态调整时局部迁移数据，而非全局重新分配。每个真实节点对应多个虚拟节点（如 node-A-01、node-A-02），通过向真实节点标识符添加后缀编号。唯一性：每个数据在环上的位置唯一，顺时针方向必然存在一个最近的节点（除非环上无节点），避免了定位歧义。真实节点的多个虚拟节点分布在环上的不同位置。
2025-03-31 15:29:48
124
原创 CPU飙高生产事故分析
晚上六点左右CPU告警，从日志量判断是在这段时间进行了大量的业务处理，追踪到是有人触发了订单推送的方法，时间跨度22天，订单量40w左右。
2025-03-24 21:09:50
289
原创 Netty如何解决空轮询BUG
Netty通过重建Selector实现状态重置，核心步骤包括注销旧Channel、创建新Selector、关闭旧Selector，最终使新Selector的selectedKeys()集合为空。这一机制强制下一次轮询必须依赖真实事件，彻底规避了旧Selector因残留Key导致的空轮询问题。
2025-03-22 16:13:57
305
原创 Netty核心类之NioEventLoopGroup
NioEventLoopGroup是一个线程池，负责管理和调度一组NioEventLoop线程。
2025-03-21 16:44:45
315
原创 定制化熔断限流组件
通过每个锁关联一个condition对象实现在队列满或者空的时候主动阻塞或者唤醒。当唤醒的时候，线程对象从condition的等待队列转移到AQS同步队列，等待获取锁。由于系统对接了大量的第三方接口，如果第三方服务不稳定会引发我们服务雪崩。针对不同第三方服务不稳定可能引发的系统雪崩问题，设计一个高可靠的防护组件需要综合熔断、限流、降级、隔离等核心机制，并结合监控与自愈能力。流量流转：请求 → 熔断校验 → 限流校验 → 入队 → 异步处理。第2次熔断 → 30×2=60秒。第1次熔断 → 30秒。
2025-03-13 16:50:56
346
原创 MQTT协议实现三方对接
MQTT5AsyncClient支持自动重连，提供了initialDelay初始重连延迟和maxDelay最大重连间隔参数，有效防止频繁重连服务器过载。
2025-03-10 21:09:12
470
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人