没有后端项目经历可写？这些后端项目经历应该适合你！

有兴趣的可以关注本人公众号和小红书（程序员Knox），后续会继续更新。

（1）图书管理系统还能使用AI？

💡项目背景

用户在使用图书管理系统时，常常只知道自己想要找哪一类的知识，但是不知道哪一些书适合自己，在这一背景下，我们尝试接入LLM的能力来处理这一问题。

✅ 解决方案

通过MCP提供数据源工具，使LLM能够获取图书馆中的图书信息、位置信息等数据，在此基础上，为LLM提供网页搜索功能，帮助其更好地解析图书数据。最终，达到只需要用户输入某一类知识，即可达到智能推荐的效果。

（ps：其实还可以在此基础上引入标签体系、案例库等内容，提高LLM智能推荐的准确性）

（2）线程池也有死锁问题？

💡项目背景

有一天我们发现线上出现预警，大量接口报连接超时错误。 排查后发现，竟然是由于线程池中执行的任务使用了异步调用，导致线程池资源耗尽，最终出现死锁问题。

🔍问题复现

我们使用线程池处理入库操作。某次处理一个企业件，包裹数量约 2 万单。 而在具体的入库流程中，会通过异步方式调用其他领域的数据。但异步任务和入库主任务使用的是同一个线程池。

在这种情况下，出现了一个极端场景：线程池的所有线程都被主任务占用，异步任务只能堆积在阻塞队列中，迟迟得不到执行，最终导致线程池死锁。

✅ 解决方案

问题发生后，我们做了如下调整：提升了入库任务所用线程池的线程数，并为异步操作提供独立的线程池处理。

（3）货物抽检占用大量内存怎么优化？

💡项目背景

在日常抽鉴业务中，我们需要对大量货物进行状态标记，例如判断某个货物是否命中某一抽鉴规则。最初的实现采用普通数据结构存储，随着业务扩展，抽鉴批次不断增加，系统逐渐面临内存飙升与存储效率低下的问题。

尤其是每一批次的抽鉴都需要一份完整的货物命中标记集合，导致内存占用呈线性增长，系统压力急剧上升。

🔍问题复现

我们对每个抽鉴批次的货物 ID 进行布尔标记，用于表示该货物是否命中。

最初的做法是为每个批次都维护一套全量的 BitMap 位图。但在高峰期，抽鉴批次可达数百个，按每批几十万货物计算，哪怕单个位占1 bit，累积下来依然会带来数百 MB 的内存开销，甚至导致 Redis OOM。

✅ 解决方案

我们采用 BitMap + 尾号抽样 + Redis Key 精简设计 的组合方式，有效降低存储压力：

BitMap 位标记：继续使用 BitMap 标记货物命中状态，保持查询效率与空间压缩特性。

尾号抽样机制：并非所有货物都进行抽鉴，而是仅抽取 特定 ID 尾号 的货物（如以“37”结尾的 ID），大幅压缩位图密度。

Redis Key 精简映射：每个抽鉴批次 + 尾号对应一个精简的 Redis Key，例如“抽鉴 : 批次ID : 尾号”，避免创建庞大的全量位图集合。

通过上述方式，通过牺牲一定的随机性，使得系统在保留 BitMap 高效查找特性的同时，将 Redis 的内存开销控制在可接受范围内，最终实现抽鉴准确性与资源利用率的双平衡。

（4）冷热分离思想解决Reids大Key问题

💡项目背景

在生产环境中，我们遇到了一个典型的大Key问题：“操作人员-货物统计”缓存结构过大，直接影响 Redis 的缓存命中率，命中率长期低于 80%，导致接口响应效率低下。

这是一个典型的性能瓶颈问题，如果继续使用无分片的大Key结构，Redis 容易因 Key 太大而阻塞；但若盲目分片，又会导致命中率下降、数据分散、缓存效益打折。

🔍问题复现

业务中需要统计每个操作人员在各仓库中操作过的货物信息，初始方案中采用以「人员ID」为维度构建缓存，保存其操作过的所有货物ID集合。

随着数据积累，部分操作人员的货物数突破数万，形成大Key风险，且频繁的写入也加重了 Redis 压力。

为规避大Key风险，我们尝试按货物ID进行分片缓存，但由于访问集中在热点数据，命中率明显下降，不仅未解决问题，反而造成接口性能波动更大。

✅ 解决方案

我们基于「数据冷热分离 + 精细化缓存策略」重新设计了缓存架构，最终实现性能与稳定性的平衡：以仓为单位设计缓存 Key：从「人员 → 仓 → 货物」角度设计缓存结构，缩小单个 Key 的数据体积，天然分散写入压力。

冷热分离策略：

1. 对于短时间内频繁访问的热门数据，继续存入 Redis 缓存；
2. 对于货物记录数超阈值（如 500 条）或长期未访问的冷数据，跳过缓存，直接写入 MySQL 持久化，降低缓存压力。
3. 时间 + 数量维度的淘汰机制：缓存数据设置过期时间，并结合访问频率定期清理，避免历史数据堆积形成新的大Key。