知识库

消息队列#

• 画出新需求的大致流程图，但是PRD还没有出来
• 看了下消息队列 Mafka ，扩充了些对于消息队列方面的了解，Rebalance、at least once，虚拟分区等等，
• 当业务不能接受消息丢失时，设置副本与ack确认次数（-1为初始，1为完成，每消费一次就+1），代价是系统的速率会降低，并且需要消费者做好幂等；
• 当业务需要延迟队列但要保证高速率（消息保持）时，可以添加一个KV(我的理解是外部的数据库或者日志记录等），通过定时任务将某时间段内的消息发送给消费者，代价是系统中多一套定时任务，能力会下降无法深入事务消息没看懂（太菜了）
• 在git上找了几个redis的项目想再深入些，击穿，穿透的解决方法落地，关键数据一致性问题，本地缓存与Redis的取舍，redis的集群等等等都是我想关注的试着去落地一次，后面如果PRD不出就研究下再
• 对于消息队列，缓存都只有最基础的概念与想法。争取后面自己动手在项目中真正的用一用，
• 对于今天下午群里DDD的思想的理解有些了，但是吧感觉得再多想想

​

mq有没有自动判断消费成功的能力：RabbitMQ开启自动ack，消息到达消费者后mq会直接删消息不管成功没Kafka 在消费者拉取消息后，定时自动offset，如果offset后出现问题没有兜底所以，他两只能自动消除用过的消息，成不成功，不知道

对于消费者处理消息有了一点理解：将重试次数final写死，消费方法要做好异常抛出和抓取

Redis#

​ ○ 复习了一下黑马点评中redis的击穿（逻辑过期）、穿透（缓存空值）的解决办法的实现，点赞排行榜Zset/Set，关注动态的信息流推送。并接入了MQ做秒杀优惠券的后续数据库操作。

​ ○ 用户鉴权与当前请求的用户数据“从哪里来”<用户在登录系统之后>，后端通过 拦截器 获取前端请求 中 的token,并反转成用户对象，再将它保存在ThreadLocal的 线程级本地存储 中, 目的是，在 一个请求调用的过程中，传递数据，避免层层传参.这个“缓存”的 生命周期 会随着 请求的结束而结束，但要注意的是 需要在请求响应结束后，主动清除“缓存”

​ ○ 水群看到了限流，熔断，兜底。梳理了下流程应该是： 用户请求 - 限流 - 【线程池隔离】放在哪个池 - 调用下游 - 如果失败 - 触发 【熔断】 还要不要继续重试 - 【补偿】 能不能通过某些操作抢救一下 - 【兜底】 用户最终看到的是什么 - 【补漏】 根据日志对账；然后重新翻了一下自己写的线程池的文档，对于 并行调外部接口 获取数据做汇总后再做业务这一块中，现在公司是 通过countDownLatch.await(5, TimeUnit.SECONDS);做的等待，如果超时就 熔断 后续其他线程返回的结果直接丢弃, 补偿为 打个日志标记一下 ，然后兜底方式 是 先展示当前结果，即使数据可能存在偏差也先展示，不影响用户的整体使用感受

​ ○ 继续看redis缓存框架的学习项目

​ ○ 看能不能研究一下用户鉴权的实现方法

○ https://zq99299.github.io/note-book/cache-pdp/redis缓存框架的相关文档，非常的详细，感觉挺全的。

https://github.com/zq99299/cache-pdp这是对应的git项目

看redis集群架构

看了AOF与RDB，主从模式中的同步流程，以及宕机或脑裂如果回复与预防

数据库#

○ 看了一下「活动专属贴纸」

​ ○ 数据库中锁粒度的层次与对于的性能与开销：库级锁-并发最低-开销小-场景：数据库备份,迁移,主从切换表级锁-并发到表-开销一般-场景<批量导入大量数据行级锁-并发到行-开销较大-场景>：商品秒杀，仓库出货入货列级锁-并发极差-开销极大-场景：长事务进行多表聚合查询 年终售卖数据分析

​ ○ OLAP与OLTP,MVCC的实现与作用

OLTP

​ ■ 要求事务处理速度要快，保证DB对请求的吞吐量

​ ■ 读锁不阻塞写锁，写锁不阻塞读锁

​ ■ 常见场景：电商秒杀下单、仓库货物扣减、银行支付转账等

OLAP

​ ■ 要求进行大量的数据检索，千万或者亿级数据查询或清洗、或者是大量的表进行join链接

​ ■ 列式，复杂聚合查询的读取速度快，但是修改时需要拆列，性能低

​ ■ 常见场景：年终售卖数据分析，大V粉丝标签统计，股票长线数据分析

对定时删除业务场景做了分析，数据库中添加时间字段并加索引，引索的目的是查询过期数据时防止全面遍历、表锁（但要注意内容sql的最左前缀问题，避免其他索引失效）。

业务#

业务场景设计，30分钟自动订单过期的写法，业务边界在过期最后时刻支付发生在 过期的前后，可以将两个update数据库的语句条件写为一个，让数据库行锁来决定谁成功

1
 -- 关单任务执行
2

3
UPDATE `order` SET status = 'CLOSED', close_time = NOW()
4

5
 WHERE order_no = ? AND status = 'PENDING_PAY';
6

7
-- 支付回调执行
8

9
UPDATE `order` SET status = 'PAID', paid_time = NOW()
10

11
 WHERE order_no = ? AND status = 'PENDING_PAY'；

这个方法要做一个退款的兜底

业务思考：如果一个订单，支持微信与支付宝进行支付，在高并发的情况下如何避免，同一笔订单被微信与支付宝同时完成支付？想法：前端做渠道互斥，后端上互斥锁保证支付动作只有一个进程能够拿到，极端网络情况兜底，定时对账与自动退款

需求一#

○ 需求：调整用友客户数据的客户编号，牵涉了 middleware、customer 服务和 customer-api 契约，客户编号格式K0500。customer 负责实现分配和 upsert 接口，middleware服务 通过shb-customer-api包 调用shb-customer服务的接口。

首次只在jenkins打包构建了middleware，没有更新shb-customer-api的版本号以及deploy发布到nexus仓库，导致middleware在旧的shb-customer-api找不到新增的接口启动失败，随后排查并且解决这个问题。第二是middleware 调用 deleteAll 时先遇到抢锁失败（删除和新增共用一把redission锁，此时测试环境正在同步新数据），之后拿到锁又因同事将customer服务搞挂了测试发布被拖延。最后在nacos将同步数据改为false，同步数据的接口关闭，避免删除旧的测试数据时，新增和删除同时抢锁，好在赶在下班前调整好了。

总结：尽量改动在有一个服务内，不到万不得已时不要跨服务新增接口，调试起来真的很麻烦，为此我还去找了一个skill叫ponytail，下一次试试看好不好用。

​ ● 卡点：整个开发->发布->测试流程相对繁琐，涉及到多模块联调、jenkins选择环境再选分支构建，另外jenkins的启动成功并不一定真的成功，还要排查构建日志+nacos是否监听服务确定服务是否启动，最后是接口测试时看日志基本上使用kibana，但是极端情况（服务启动失败）需要去测试服务器下查看日志文件。说实话，放在自己本地开发的话，真用不到这么麻烦的测试流程 ，但谁叫这是合作开发，测试环境要一起用，谁搞炸了马上就钉钉diss…

​ ○ bug修改，客户在门户查看知识库时因内存超过设置的上限100MB，导致预览页面加载超时报错。这个涉及的前端模块有2.8G，打包构建时又要等很长时间。

​ ○ 接着投简历，希望这星期能有个面试拷打我下，没有失败挫折打击，还挺难坚持的。

需求二#

​ ○ 需求：安装小工具的隔离日期需求。点击“取消隔离”后清空隔离日期，并在详情页隐藏该字段；再次隔离时，日期仍会正常显示。

很简答的需求，但费工夫的是测试环境的发布链路。这个私有化环境从 2025 年 9 月起就没再使用，和当前测试分支差距较大，页面也和正式环境不太一样。因此需要以私有化 release 分支为基础开发，再合入测试分支，通过 Jenkins 打包，按构建日志更新服务器上的镜像版本，重启后再到页面验收。后端涉及的模块20多个，前端还要统一打成静态资源交给 Nginx 挂载，整个流程比需求本身长得多。

花了一早上把这套流程整理成了 elekta-test-release skill，后续可以照着走，少一些反复摸索。本次需求也已在测试环境完成验收：取消隔离后日期清空并隐藏，再次隔离后日期正常显示。

BUG修改：知识库上传了大文件（112MB），在门户预览时加载超时，浏览器OOM无法查看。

将上限改为150MB，然后把pdfh5从1.4.2升级到3.0.0，在知识库预览中启用分段加载，最后设置兜底，超过预览上限，要求下载到本地查看。

过程就是和codex 美美battle就行了，完成修改 -> 合并 -> 发布 -> 验证。

需求三#

​ ○ 修Bug：TCL云仓出库调用MQ，下游消费者因出库类型未命中导致未消费。

​ ○ **根因：**测试环境里的“tcl-收货仓故障品调拨出库”拥有一个独立的出库类型 ID，而 Middleware 当前没有把这个 ID 配到任何启用的 TCL 出库类型分支中。因此消息虽然到达并被监听器处理，却在出库类型分流处落空，导致未消费。

​ ○ **后续修复方向：**先确认测试租户这类故障品调拨出库的实际类型 ID，再明确把它映射到正确的 TCL 处理分支；同时检查创建时的库存统计消息是否应该进入 TCL 出库路由，避免缺少类型 ID 的消息造成误判。

生命周期#

在spring的生命周期中初始化那一块的Postconstruct，InitializingBean，init-method三个概念不大清楚

• 实际上都是第五点，都是初始化的方法，
• 区别是
• Postconstruct是注解方式，适合自己写的类。
• InitializingBean是Spring 接口，方法名固定 afterPropertiesSet，代码耦合 Spring
• init-method配置式，方法名自定义，无侵入，适合 XML 或第三方类

需求一#

先是把项目的心跳逻辑改了，原本是一个长事务要把所有数据都遍历一遍所以把整个库都锁了。我优化把其改成短事务，将每个目标数据锁起来。减少锁冲突发生的概率

​ ○ 然后是测了下一个新的域名接口能不能用，找不到是前端问题还是后端问题，后面发现是服务器问题

​ ○ 下午：+1要求新增一个自动删除存在满72小时的数据。我的操作实现是，每天北京时间凌晨 00<00> 扫描。仅选择满足闭环条件的且生产任务均成功满 72 小时的订单。采用批量处理，每批 100 条、逐订单短事务；锁被占用就跳过，次日重试。预演结果写入“日志中心 → 操作日志”。保留永久哈希墓碑，阻止旧数据重建订单。清理后的上报任务标记为“已清理（历史只读）”，前后端均禁止再次操作。资料重新补齐并重新上报后，72 小时重新计时。单条删除失败整单回滚。

我比较好奇这种自动删除的任务，我要咋测试这种任务。而且隐患这些我要怎么排查。有没有懂哥看到这条回复我一下

​ 学了一下xxl-job，感觉还不赖。也是一个中间件，对于需要定时删除的任务加一个注解，在xxl-job上注册这个注解，实现定时任务和单次任务的调度。

看了下cannl实现mysql和ES的同步，说实话关于ES感觉不懂的蛮多还

​ 目前在看微信支付的回调B端和C端的强一致性怎么搞

skill#

claude做的benchmark的skill，可以看看，简历上有写agent评测的可以参考他这个思路。工程思想

https://claude.dev/blog/automating-eval-design-and-hillclimbing/

• 一个会员权益的接口。上游传用户id、店铺id、商品id，我们这边判断用户拥有哪些店铺、商品的权益。然后由于有3个上游，交易、购物车、商品，平时会有大促的行为，今天做了下压测看了看接口qps的上限，然后在一些地方加了缓存。以及针对这三个上游的应用标识加了下限流。
• 做了下新需求评审、测试用例评审

ES#

Es本质上是因为传统mysq的Oltp，模糊复杂多参数查询，性能太慢

由于mysq|在模糊查询场景下性能不佳，引入ES,解决在用户数量多时SQL查询速度慢的问题。 MySQL多条件模糊检索性能不足，引入ES，依托倒排索引+IK分词器承接商品搜 索，解决慢查问题，然后你引入es还要解决数据一致性吧 MySQL多条件模糊检索性能不足，引入ES，依托倒排索引+IK分词器承接商品搜 索，通过双写+消息队列保障数据一致性，解决线上慢查询超时问题。

真正有价值的是工程思想兜底设计这些你可以看看 重点是什么场景什么问题如何解决

业务#

场景#

具体场景：

假设现在需要导出 10 万条数据。在向 Excel 写入的过程中，部分数据包含超长内容或 Excel 不支持的内容，导致写入异常。你考虑过这种情况吗？

面试被问到这个问题，还有包括查询数据库时出现的异常，怎么处理

Agent#

https://mp.weixin.qq.com/s/-7LmtflPn2xyTlwhqI2szw看了这篇OpenViking 整体是上下文管理系统，包括记忆、文件组织和检索。通篇体现渐进式披露思想。

记忆系统不太完全消化，将记忆抽取为事件和实体；通过会话提取记忆，清洗会话，记忆衰减；读取修改记忆，精排、最小替换（就是这里看不懂）。

除了渐进式披露，其他感觉和codex的文件，两阶段提取，根据使用次数、最近使用时间和索引更新的记忆系统不太一样。

​ ○ 看了一个benchmark

​ ○ 喜欢这个glossary ，agent如何判断向用户询问：可查证的事实**/无法从代码推导的偏好

● 明天打算做什么：

​ ○ https://x.com/huangtongxueh/status/2108577165306687938看看AI开发工作流

​ ○ 看看skill ops

​ ○ 记得复盘，继续看bm和

https://github.com/anthropics/skills/tree/main/skills/claude-api/shared/evals

消息队列#

Mafka和Kafka，说实话没看懂，我现在理解的概念关于Kafka有partition，消费者组，offset这些。mafka差不多，但有其他区别

消息队列#

​ ○ 比如原本有个交易场景，就是简单的扣除金额即可（这里直接同步正常做即可），后续发现这个扣除金额需要发送各种消息，消息很多写在一起同步的话，如果消息发送失败同理金额也要回滚（发现发消息没那么重要并且接受慢一点），于是这里可以异步并且解耦方法，首先确保金额交易正常，再异步调用发消息内容，后续如果有新内容比如消费新增积分，返现等等都可以异步解耦，但是异步存在一个问题，你怎么确保异步执行的方法能够不丢失，如果中途宕机重启怎么办，这里就可以使用消息队列作为一个中间件，金额交易正常之后发送消息并保存在Broker中随后消费（这里就是保证消息不丢失的八股），后续发现系统的并发大，如果一次性把全部消息推给消费者，消费者扛不住压力，于是这里推拉就可以使用，根据并发程度自己选择（说的比较简单可能有些问题没考虑

数据库#

​ 理简历产出之前功能用到mongoDB，去了解了一下业务场景，商家打印自定义模版的店铺配置通过类似json保存在🥭中，后续自主配置打印字段，直接覆盖，感觉比mysql灵活一点

自定义模版模块，针对mysql的数据结构不灵活和redis的检索慢问题，对比发现🥭的索引和较为自由的数据结构实现成本较低，ds带着我从业务到技术选型到场景拆分到边界，跳出自己的scope放在全局看业务，

业务#

今天和前端对接出了点小矛盾，·一个更新子账号接口，原余额字段传的是当前分配的余额数，现需求是做增量，让用户直接在原余额上增加或减少，我的想法是保持原接口余额字段语义不变，让前端做一次计算，公式和上下界也给他文档了，他说看不懂文档，就是不做，说计算就是后端的事情，我们的+1看到我们在吵，也帮他辩解，说要把金额的计算放后端，我寻思传的字段还是原来的，只是值需要新增一次计算，后端早就对这个余额的值做好了校验，我觉得前端改就行了，不必再动后端逻辑，而且这个前端非常清闲，我做个破后端天天要忙，就是看不惯，我就是心里不平衡。我的+1是个十年老程序员，但是月薪不过万并且今年3月被前公司裁掉了，他原来写安卓的，但是我觉得他纯水货，他不是科班出身，最近还被我们合作的公司技术科普了get请求和post请求的区别，不知道git以及操作…就开个codex然后对AI许愿，最近不忙天天摸鱼，估计这么长的工作生涯都是这么过来的。我看到+1也劝，我不再争辩，没意义，很简单的需求，花点时间新加余额变化量字段解决。以后对接前端就保持最小变更与0信任防御编程，哈哈前端要做的事又会变少

博客https://www.2025521.xyz/2026/10/13/frontend-series-1/

代理模式#

设计模式的代理模式。不直接访问对象，而是通过代理访问，就像找明星谈事情不会直接找明星本人而是找ta的经纪人。Java中的aop就是代理模式的典型实现。把公共的逻辑（日志、鉴权、事务）抽取出来统一实现，调用放。我找了项目中的通用日志的实现，通过定义的一个OperateLogAspect接口实现给方法加注解-》@Around代理此方法-》通过反射+Threadlocal拿上下文信息-》填充日志表字段-》异步落库。