前言 最近在做大数据回溯相关工作，这里把其中关于 CID 缓存以及 SQL 体积调优的一些经验做一次整理。 这类场景里，随着数据量和回溯范围变大，CID 存储方式、批量读取方式、SQL 体积控制以及查询执行稳定性，都会逐渐成为影响整体性能的关键因素。实际处理过程中，也会涉及缓存成本、查询开销、批次控
回溯相关的一些思考 前言 这次想单独记一下自己对“回溯”这件事的一些理解。 一开始我对回溯的理解其实也比较直白，无非就是把某个对象过去某一天的数据查出来，再往后分析原因。 但后面越想越觉得不对。 如果回溯真的只是查历史数据，那很多问题其实解释不通。比如为什么时间跨度一大，就不能继续逐天查；为什么有些
synchronized 相关思考 前言 最近又重新过了一遍 synchronized，发现自己之前对它的理解其实偏“结论导向”。 比如知道它能保证原子性、可见性、有序性，也知道它背后有锁升级、对象头、Monitor 这些东西，但一旦继续追问“为什么会升级”“对象头里到底放了什么”“自旋和阻塞的边界
Trino、PrestoSQL 和数仓几个概念梳理 前言 最近在补一些大数据基础概念时，发现自己最容易混的不是某一个单独术语，而是这些词总是一起出现：Trino、PrestoSQL、DW、ODS/DWD/DWS/ADS、ETL/ELT、OLTP/OLAP。 单看每个词，好像都能说两句；真要把它们放到
背景 在一次 ZK 突然莫名的出现高负载，导致Provider、Consumer 与 ZK 连接异常，系统一直提示连接异常，但是此时对各个系统Dubbo 服务依旧正常调度，下文继续分析为什么不会影响到服务间调用。但是使得 ZK 高负载的根因是什么呢？ 排查过程 日志记录异常如下： org.apach
在理解扩容器前得先明白HashMap中几个常量的含义 //默认初始容量 ，必须为二的次幂 static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16 //最大容量 static final int MA
用法 参考：https://www.cnblogs.com/wt645631686/p/8454497.html 字段 描述 key 键值 longitude 经度 latitude 纬度
技术排查 初步分析 流量突增？ 监控显示调用量平稳，排除突发流量导致分片激增的可能。 集群负载异常？ DBA核查CPU/内存/磁盘IO指标均正常，排除硬件资源瓶颈。 插入流程深挖 [客户端] │ 单条INSERT操作 ▼ [分布式表] → 哈希计算分片键 → 路由至Shard-2
技术排查 初步分析 流量突增？ 监控显示调用量平稳，排除突发流量激增的可能。 集群负载异常？ DBA核查CPU/内存/磁盘IO指标均正常，排除硬件资源瓶颈。 插入流程深挖 [客户端] │ 单条INSERT操作 ▼ [分布式表] → 哈希计算分片键 → 路由至Shard-2 ▼ [本
ThreadPoolExecutor 参数解析 corePoolSize 核心线程数 即使没有任务执行，核心线程也会一直存活 线程数小于核心线程时，即使有空闲线程，线程沲也会创建新线程执行任务 设置allowCoreThreadTimeout=true时，核心线程会超时关闭 maximumPoolS
