Junly博客

前言相册工具通常会把照片排成时间线、瀑布流或文件夹列表。这样的方式足够高效，但总觉得少了一点“重新进入那段记忆”的仪式感。 时光星图 Time Atlas 想做的是另一种体验：把本地照片目录变成一片可以探索的 3D 记忆星河。一个文件夹是一座星系，一张照片是一颗星辰，用户可以在星图全貌、焦点航行、星系内部和照片浏览之间层层进入，把一次旅行、一个纪念日、一段日常重新展开。 访问地址：https://junly.top/time-atlas 它解决什么问题时光星图不是为了替代系统相册，也不是为了做云端照片管理。它更像一个专注“沉浸式回看”的本地记忆浏览器。 它适合这些场景： 想把旅行、纪念日、家庭日常等照片按主题重新组织。 想在大屏、投影或触控设备上用更有氛围的方式展示照片。 想体验摄像头手势浏览照片，但又不希望照片上传到服务器。 想把文件夹里的照片快速变成一个可演示、可分享思路的 3D 互动页面。 核心设计原则很简单：照片留在本地，交互变得更有空间感。 核心功能1....

前言在 Web 项目中，接口安全最基础的一层一定是 HTTPS。HTTPS 已经通过 TLS 解决了传输过程中的窃听、篡改和中间人攻击问题。对于大多数普通业务接口来说，HTTPS 加登录态认证已经足够。 但在一些敏感场景中，比如实名认证、银行卡绑定、支付确认、修改手机号、修改密码、隐私资料提交等，仅依赖 HTTPS 有时还不够。原因不是 HTTPS 不安全，而是业务系统里还可能存在日志落盘、代理转发、网关调试、内部链路暴露、前后端错误处理等额外风险。 这时可以在 HTTPS 之外，再对敏感业务数据做一层应用层加密。本文就从算法对比开始，介绍一套比较通用的接口业务数据加密传输方案。 常见加密算法对比在设计接口加密方案之前，先要理解几类常见算法的特点。很多安全方案不是靠某一个算法完成的，而是多种算法各自负责一部分能力。 对称加密算法对称加密的特点是：加密和解密使用同一把密钥。 常见算法有 AES、ChaCha20、SM4、DES、3DES...

前言作为一名基金投资者，你是否也有过这样的困扰：交易日盘中想看看自己持有的基金大概涨了多少，却只能反复刷新各种 App，而且大多数行情软件只展示基金的上一日净值，盘中的实时估值要东找西找。 为了解决这个痛点，我利用业余时间开发了 估值君 —— 一个专注于基金盘中实时估值追踪的 Web 工具。输入基金代码即可添加，盘中自动刷新估算净值，让你对自己的持仓盈亏一目了然。 访问地址：https://junly.top/fund/ 或 https://fund.junly.top/fund/ 功能介绍实时估值追踪估值君的核心功能就是盘中实时估值。在交易日的 9:30-15:00 期间，系统会自动刷新每只基金的估算净值，并记录为时间序列数据，生成盘中走势折线图。收市后，你可以在估值走势图上清晰地看到当天估值的变化轨迹。 添加基金也非常简单，只需要输入基金代码（如...

前言很多线上故障都发生在发布之后。面试官常问：上线后出问题怎么办？怎么判断是不是新版本导致的？什么时候回滚？配置变更、数据库变更和缓存兼容怎么排查？ 典型现象 发布后错误率升高。 只有灰度用户报错。 部分实例异常，部分实例正常。 新老版本同时运行时数据异常。 配置刷新后接口行为变化。 数据库字段变更导致兼容问题。 排查流程flowchart TD A[发布后告警] --> B[确认影响范围] B --> C[对比发布时间] C --> D[查看灰度批次] D --> E{是否新版本相关} E -->|是| F[回滚或关闭开关] E -->|否| G[继续排查依赖和流量] F --> H[数据修复和补偿] G --> H H --> I[复盘和治理] 第一时间看什么 发布批次。 版本号。 灰度范围。 错误率和...

前言数据不一致是业务系统中最敏感的问题。订单支付成功但状态未更新、库存扣了但订单失败、优惠券核销了但订单取消，这些都不是简单的技术异常，而是会影响资金、库存和用户体验。 典型现象 支付成功但订单仍是待支付。 库存扣减成功但订单创建失败。 MQ 消息发送成功但消费失败。 用户积分重复发放。 报表数据和明细数据对不上。 主库和搜索索引数据不一致。 排查流程flowchart TD A[发现数据不一致] --> B[确定业务主记录] B --> C[查看状态流转日志] C --> D[查看本地事务] D --> E[查看MQ消息] E --> F[查看消费和补偿] F --> G[对账确认影响范围] G --> H[修复数据] H --> I[补齐防重和监控] 先找业务主记录排查数据不一致不能先看代码，要先确定主记录： 订单号。 支付流水号。 库存流水号。 优惠券核销记录。 MQ...

前言线程池打满会导致接口慢、任务不执行、队列堆积甚至内存溢出。面试中常问：线程池参数怎么配？队列满了怎么办？为什么不能所有业务共用一个线程池？ 典型现象 异步任务延迟执行。 接口卡在 Future.get。 日志出现 RejectedExecutionException。 队列长度持续增长。 CPU 不高但请求很慢。 某个慢任务拖垮所有异步任务。 线程池执行模型flowchart LR A[提交任务] --> B{核心线程是否满} B -->|否| C[创建核心线程] B -->|是| D{队列是否满} D -->|否| E[进入队列] D -->|是| F{最大线程是否满} F -->|否| G[创建非核心线程] F -->|是|...

前言MQ 让系统解耦，但也会带来消息积压、重复消费、顺序错乱、死信堆积和重试风暴。面试时要讲清楚：积压怎么看，为什么积压，怎么快速恢复，怎么保证业务不重复执行。 典型现象 消费 lag 持续增长。 订单状态延迟更新。 短信、站内信、积分发放延迟。 死信队列消息变多。 消费者日志大量重复异常。 下游服务被重试流量打爆。 排查流程flowchart TD A[消息积压] --> B[确认Topic/Queue] B --> C[看生产速率和消费速率] C --> D{消费是否报错} D -->|是| E[查异常和死信] D -->|否| F[查消费耗时和并发] E --> G[修复数据或代码] F --> H[扩容消费者/提高并发] G --> I[补偿和重放] H -->...

前言Redis 故障经常不是 Redis 挂了，而是访问模式不合理。热 Key、大 Key、缓存击穿、缓存雪崩都会把缓存层和数据库层一起拖慢。面试时要能把缓存问题和业务场景结合起来讲。 典型现象 Redis CPU 飙高。 某个接口 RT 突然变长。 数据库 QPS 突然上升。 Redis 慢查询增加。 应用 Redis 连接池耗尽。 集群中某个分片负载明显高于其他分片。 排查流程flowchart TD A[接口变慢或DB压力升高] --> B[查看缓存命中率] B --> C{命中率是否下降} C -->|是| D[排查穿透/击穿/雪崩] C -->|否| E[排查热Key/大Key/慢查询] D --> F[限流/互斥/空值缓存] E --> G[拆Key/本地缓存/数据结构优化] F --> H[长期治理] G --> H 热 Key热 Key 是大量请求集中访问同一个 Key，比如秒杀商品库存、首页配置、热门商品详情。 排查方式： 查看 Redis 节点 CPU。 看应用访问日志中的 Key...

前言数据库连接池耗尽经常表现为接口超时，但根因可能不在连接池本身。它可能由慢 SQL、大事务、连接泄漏、线程池堆积、数据库锁等待或下游变慢引起。 典型现象 日志出现 Connection is not available、Timeout waiting for idle object。 HikariCP active 连接接近 maximumPoolSize。 接口大量超时。 数据库 QPS 下降但连接数很高。 Tomcat 线程阻塞等待数据库连接。 故障链路flowchart TD A[慢SQL或慢事务] --> B[连接占用时间变长] B --> C[连接池active打满] C --> D[请求线程等待连接] D --> E[Tomcat线程堆积] E --> F[接口整体变慢] F --> G[重试增加] G --> C 排查步骤看连接池指标重点指标： active 连接数。 idle 连接数。 pending 等待线程数。 connection timeout 次数。 连接获取耗时。 如果 active...

前言Full GC 频繁会导致接口抖动、服务卡顿甚至雪崩。面试中常见问题是：怎么判断是 GC 导致接口慢？Full GC 频繁怎么排查？JDK 8、17、21 的 GC 调优有什么区别？ Full GC 的影响Full GC 通常会带来 Stop The World，应用线程暂停。表现为： 接口 P99 周期性升高。 监控出现请求尖刺。 日志时间戳中间出现明显空洞。 CPU 升高但吞吐下降。 老年代回收后很快又涨满。 排查流程flowchart TD A[接口卡顿] --> B[查看GC监控] B --> C[确认Full GC频率和耗时] C --> D[分析GC日志] D --> E[老年代是否持续增长] E -->|是| F[堆Dump分析泄漏] E -->|否| G[对象晋升/大对象/参数不合理] G --> H[调整代码或JVM参数] F --> H GC 日志怎么看重点关注： Young GC 次数和耗时。 Full GC 次数和耗时。 GC...