本文主要整理了我对大数据回溯的一些理解。回溯并不只是查询历史数据，而是尽可能还原业务对象在某个历史时点的真实状态，用于解释后续变化、分析根因以及评估策略效果。文章重点讨论了大时间跨度下为什么需要时间归拢、归拢的边界是什么，以及为什么回溯场景里绝不能发生时间穿梭。最终想说明的一点是：回溯真正难的不是查到历史数据，而是守住历史语义，让结果足够可信，能够支撑后续决策。
有更新！

大数据回溯相关的一些思考

主要重新梳理了一遍 synchronized 的底层实现思路，重点不是停留在“它能保证线程安全”这个结论上，而是继续往下追对象头、Mark Word、锁升级、自旋和 Monitor 之间到底是怎么串起来的。文章从几个实际容易混淆的问题切入，依次分析了偏向锁、轻量级锁、重量级锁的适用场景，以及 wait() / notify()、可重入、静态同步方法、锁消除和锁粗化这些常见延伸点，最后把整套机制收束到一条更容易记忆的理解链路上。
有更新！

synchronized 相关思考

问题现象 我司一出口应用突然出现Timeout waiting for connection from pool起初只有一个接口，慢慢的越来越多接口受影响，开始陆续出现大量超时。 技术排查 初步分析 流量突增？ 监控显示调用量平稳，排除突发流量激增的可能。 集群负载异常？ DBA核查CPU/内存/磁盘IO指标均正常，排除硬件资源瓶颈。 插入流程深挖 [客户端] │ 单条INSERT操作 ▼ [分布式表] → 哈希计算分片键 → 路由至Shard-2 ▼ [本地表 t_product_request_log_local] │ 生成临时分片 → 原子化提交为正式分片 ▼ [存储目录] └─ 未分区数据池 ├─ 分片_1_1_0（单次插入产生） ├─ 分片_2_2_0 └─ 分片_3_3_0（持续累积） 关键发现 • 单条插入模式：每次插入生成独立小分片 • 本地表未分区：所有数据堆积在单一逻辑分区 根因定位 分片合并机制失效 ClickHouse通过后台线程合并相邻分片（如202310_1_1_0 + 202310_2_2_0 → 202310_1_2_1），但存在以下瓶颈： ....
有更新！

记一次因网络问题导致 Http 连接池耗尽

ClickHouse TOO_MANY_PARTS 异常分析与优化实践 问题现象 线上服务触发告警 TOO_MANY_PARTS (300)，提示分片合并速度远低于数据插入速度，异常持续数分钟后自动恢复，MQ重试机制保障了最终数据一致性。 技术排查 初步分析 流量突增？ 监控显示调用量平稳，排除突发流量导致分片激增的可能。 集群负载异常？ DBA核查CPU/内存/磁盘IO指标均正常，排除硬件资源瓶颈。 插入流程深挖 [客户端] │ 单条INSERT操作 ▼ [分布式表] → 哈希计算分片键 → 路由至Shard-2 ▼ [本地表 t_product_request_log_local] │ 生成临时分片 → 原子化提交为正式分片 ▼ [存储目录] └─ 未分区数据池 ├─ 分片_1_1_0（单次插入产生） ├─ 分片_2_2_0 └─ 分片_3_3_0（持续累积） 关键发现 • 单条插入模式：每次插入生成独立小分片 • 本地表未分区：所有数据堆积在单一逻辑分区 根因定位 分片合并机制失效 ClickHouse通过后台线程合并相邻分片（如202310_1_1_0 + 20231....

ClickHouse TOO_MANY_PARTS 异常分析与优化实践

前言 最近闲来无事无意间点进 ArrayList#add()中看了下，产生了几个之前未注意到的困惑点，特此记录下解惑的过程。 在 java.util.ArrayList#grow 中有多处判断容量大小，采用的均是newCapacity - MAX_ARRAY_SIZE > 0为何不直接使用newCapacity < MAX_ARRAY_SIZE这种方式呢？这样不是更加简洁明了吗？ java.util.ArrayList#MAX_ARRAY_SIZE 值为何是Integer.MAX_VALUE - 8，直接使用Integer.MAX_VALUE不行吗？ java.util.AbstractList#modCount变量有何作用，为什么每次调用都要进行modCount++;操作？ 正文 直接比较 与 减法比较 若在常规情况下（不存在溢出）二者是一致的，不会有任何问题。 若由于扩容导致newCapacity溢出变为了负数，则情况会有所不同 直接比较 ：newCapacity > MAX_ARRAY_SIZE 当 newCapacity 是负数（如因溢出导致）时，条件为.......

ArrayList 扩容相关思考

背景 在一次数据排查时，无意间发现数据对不齐。结合代码及日志分析发现都没问题，且有插入操作，但是 Clickhouse 却查不到改条记录。匪夷所思.... 排查过程 最后断定大概率是 Clickhouse 的问题，难道 Clickhouse 存在数据丢失的情况？进一步分析丢失数据部分时间分布发现并无任何规律，排除 Clickhouse 可能出现的定时故障问题。 无奈只能找公司 DBA 寻求帮助，得出大概率是 Clickhouse 的 ReplicatedReplacingMergeTree 问题。该业务表结构大致如下 -- auto-generated definition create table t_product_request_log_local ( id String, merchant_id String, product_code String, order_no String, spend_time UInt16, create_time DateTime default toDateTime(now()) ) engine = ReplicatedReplacingM....

记一次 Clickhouse 数据写入成功，但是却无数据问题

背景 使用了腾讯云封装的 Pulsar 作为云消息队列，消费中有大致就是一个异步 MQ 日志落库的逻辑。我们日志库使用的 ClickHouse，那天 CK 出现了一段时间的连接异常导致 MQ 消费一直消费异常，进而 Consumer 没再接收到任何消息，但是我本地主动发起了一笔请求，消息成功消费日志落库，一通迷惑现象！ 排查过程 首先大致梳理一下关键的时间节点如下： 2024-06-26 12:33:00.000 ～ 2024-06-26 13:47:00.000 CK异常持续时间 2024-06-26 12:53:00.000 ～ 2024-06-26 13:11:00.000 异常集中爆发时间 2024-06-26 13:11:00.000 ～ 2024-06-26 14:27:53.000 消息开始积压，无任何消息被消费 2024-06-26 14:27:53.000 ～ 2024-06-26 14:40:00.000 积压消息陆续得到消费 2024-06-26 13:11:00.000 不再向消费者推送消息 2024-06-26 14:27:53.000 服务进行了重启，开始陆....

记一次 MQ 消费失败引发的一系列问题

背景 在一次 ZK 突然莫名的出现高负载，导致Provider、Consumer 与 ZK 连接异常，系统一直提示连接异常，但是此时对各个系统Dubbo 服务依旧正常调度，下文继续分析为什么不会影响到服务间调用。但是使得 ZK 高负载的根因是什么呢？ 排查过程 日志记录异常如下： org.apache.curator.CuratorConnectionLossException: KeeperErrorCode = ConnectionLoss at org.apache.curator.ConnectionState.checkTimeouts(ConnectionState.java:225) at org.apache.curator.ConnectionState.getZooKeeper(ConnectionState.java:94) at org.apache.curator.CuratorZookeeperClient.getZooKeeper(CuratorZookeeperClient.java:117) at org.apache.curator.framewor....

记一次 Zookeeper 高负载引发的一系列问题

背景 在一次Uat 环境测试中，出现主键冲突异常，明明昨天测试都是正常的。多试了几笔发现生成的主键 ID 确实已经重复了，且该 ID 是在今天上午十点生成的，很奇怪。 排查过程 该分布式 ID 生成器是借助 Zookeeper 来实现的，发现Uat 环境 ZK 配置的 Host 与 Prod 环境不同。而Uat 与 Prod 又是共连相同的库表。那这出现主键冲突是几乎不可避免的。 但是为什么之前一直没冲突呢？ 查阅该分布式 ID 源码分析其生成原理可得，如下 由上面逻辑分析，在项目第一次上线后是肯定会出现主键冲突问题。 假设 UAT 服务分配 ID 为：20240807000000001001 开始自增 PROD POD1：20240807000000001001 PROD POD2：20240807000000002001 PROD POD3：20240807000000003001 PROD POD4：20240807000000004001 其中 UAT 与PROD POD1之间生成的主键 ID 是肯定会出现冲突的。那为什么使用过一段时间后就不会冲突呢？因为在随着项目的重新发布.....

记一次分布式 ID 主键冲突问题

前言 近期在使用apifox调试接口时，由于众多测试样例，每次修改参数都需要重新手动去生成一下签名，再回填入参数中，略烦。便着手寻找可自动生成签名并回填方法。查阅官网文档，发现所提供的样例是针对form表单类型可使用动态值{{signature}}进行拼接。但是我司是使用json交互，签名字段在json体内，因此就需自己琢磨方法了。 实现过程 将签名工具类添加到apifox扩展目录 如图按步骤将加签的Jar包（apifox只支持Jar包模式不支持Java文件）添加到对应目录即可（这里必须吐槽下交互！！！原来需要自己将Jar挪到这个目录，笔者还以为这是一个文件上传接口....apifox可帮助挪到对应目录，害我点了好久） 这里介绍下生成Jar的几个需要注意的点：注意指定好main方法所在类，其次就是构建时需将pom中所需依赖也一并构建。构建时采用如下配置即可 <build> <finalName>${project.artifactId}</finalName><!--修改编译出来的jar包名，仅为{artifactId}.jar-->......

巧用Apifox自动生成接口签名

前言 话说前段时间，大毛和二毛两家打的那叫一个热火朝天。大毛将二毛摁在地上反复摩擦之际，鹰酱给二毛发去一项指令：不要送！！！而此条指令被精通特工技术的大毛潜伏人员截获对报文内容进行稍加修饰：不要怂！！！二毛收到指令瞬间就打上鸡血，哐哐就是和大毛死磕到底。二毛：鹰酱都这么说了，肯定能给我不少支持，我可得卖力好好表现一番。然后在鹰酱的一声声猪队友的骂声中，二毛又被摁在地上反复摩擦。由此可见通信安全的重要性。（故事纯属娱乐虚构，切不可当真） 接下来就和大家一起探讨一下如何设计一个安全可靠的加密通讯挽救二毛危在旦夕的性命吧。 正文 相信说到通信安全大家脑海里就会浮现一下几个名词：可逆加密、不可逆加密、对称加密、非对称加密、公钥、私钥、加签、解签、数字签名、数字证书...等等。现在就先回顾一下这些名词都指代什么含义吧。 加密算法的分类 加密算法大类主要可分为：可逆加密和不可逆加密 可逆加密 也称为对称和非对称加密算法的组合，即通过密钥可将密文还原成明文的加密算法 对称加密 指通过一个密钥即可完成报文的加解密的过程。 对称加密算法常用的有： 高级加密标准（AES, Advanced Encry......

一文讲清加解签名、加解密、数字签名、数字证书

背景 在一个DB层本是只有MySQL项目中，后期同时引入了Clickhouse作为日志存储的数据库。在每次项目发布时都会抛出异常unregister mbean error提示注销bean异常，具体报错如下： javax.management.InstanceNotFoundException: com.alibaba.druid:type=DruidDataSource,id=merchantdb at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterM.....

记一次Druid连接池关闭异常问题

背景 在维护公司一个老项目时，出于方便的考虑，准备在项目中引入Mybatis-plus作为持久层，那么这就涉及到新老代码共存的问题。随后由于该项目是一个数据产品相关项目，有一个日志模块会记录用户的调用记录，该日志数据落库在MySQL现已存储8kw+数据，已经不堪重负了，同时产品同学期望完善一下这块的数据统计相关功能，如日流水调用量，调用趋势、商户账单相关功能，因此准备对这块日志存储进行改造，将后续日志请求落库到Clickhouse中。 改造过程 持久层采用Mybatis-plus 在用easy-code生成了mybatisplus模板信息后启动项目抛出异常如下 org.apache.ibatis.binding.BindingException: Invalid bound statement (not found) 这是因为Mybatis-plus未动态生成SQL导致无绑定的statement 解决方案 将XML路径及其实体别名映射实体配置名称修改为适配Mybatis-plus配置 mybatis-plus.type-aliases-package=com.baidu.pojo.......

记一次mybatis与mybatisplus及mysql与cilickhouse共存遇到的问题

在上线代码后，后台日志疯狂抛表不存在异常，经排查发现，新建的该表未在本次上线需求中，还在测试中的需求，第一反应是本次上线分支被合入了另外需求代码所致，然而奇怪的点却是该版本分支确实无那块代码，且检查mster分支也无那块代码。懵....，立马检查打包构建及其docker镜像问题，也都是正常，构建的也都是正确版本的分支无误。 经过后面排查定位，发现，上线版本是在前一天构建好的，然后当天准备上线，而上线当天，有一个公共分支test1环境分支构建，而上线需求分支曾经合入该分支，且此时，test1分支项目版本号为：1.23.0-SNAPSHOT而上线需求项目版本号也为 1.23.0-SNAPSHOT 由于发布系统问题，在后面构建时依赖版本被更新替换了，导致了该问题。 解决： 在构建时锁定所有包版本，最好是将版本设置为RELEASE正式版本，且该版本不可被覆盖 同时在版本上线时，最好是基于master分支版本的基础上进行升级，在还未上线需求无需版本号的升级

记一次上线发布引用包问题

异常日志 The last packet successfully received from the server was 15,788,990 milliseconds ago. The last packet sent successfully to the server was 15,788,991 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem. Communicati.....

记一次生产Druid连接池Communications link failure异常

背景 由于公司出于安全考虑，准备统一收拢对外出口服务器，同时对出口请求进行监控管理，因此tplinker项目孕育而生 项目简介 该项目针对不同场景主要有两种模式 透传模式：主要用于兼容现有业务直接对外请求接口，该模式对于已经开发请求URL配置代理域名，请求先通过Nginx转发到出口服务器中，再经过tplinker出口服务，出入参直接透传。 非透传模式：主要用于对后续新对接出口接口，tplinker对接口涉及的加解签、加解密相关内容完成，因此业务侧只需要关心业务的开发。同时对外接口相关调用进行汇总统计监控。 遇到问题 在开发以及将历史出口URL统一收拢时遇到不少问题，在此和读者分享下，希望有所帮助 通过出口代理后签名错误 通过查看代码签名方式时，发现在进行生成签名的时候会将请求URL也作为参数与其他请求参数进行生成签名，而改方式是通过透传方式，该种方式会将配置的请求URL前加一个固定的例如：outgoing-gateway，NG识别到该域名会代理到目标tplinker服务中去，因此客户端URL是有加outgoing-gateway该值进行签名，而服务端使用约定好的参数进行签名是不....

记公司出口网关建设遇到问题