0128.最长连续序列

0128.最长连续序列看到这个题目的第一眼想到的自然是排序算法，直接排序遍历，但是复杂度达到了o(nlogn)，不符合题目所要求的o(n)。 对于n复杂度的算法，我第一个想到的是使用哈希map，直接遍历一遍数组，对于每个数字，查找当前数字的「前驱连续长度」（即num-1 所在序列的长度）和后继长度。 如果当前数字未被计算过（这是由于可能出现重复数字），那么就可以合并前后续列长度，并且更新左右边界长
#leetcode #数据结构与算法 #算法

一次 5,200 并发压测暴露的秒杀一致性问题：从“Redis 已扣减但 DB 未落库”到可复现修复

一次 5,200 并发压测暴露的秒杀一致性问题：从“Redis 已扣减但 DB 未落库”到可复现修复背景这次排查不是从线上报警开始，而是从一次标准化压测开始。链路是典型的秒杀实现：请求先走 Redis Lua 脚本做资格校验与扣减，再把订单事件写入 Redis Stream，最后由异步消费线程落 MySQL。目标很明确：验证在高并发下是否满足不超卖、一人一单，以及 Redis 与 DB 的最终一致
#后端 #并发 #秒杀

理论更优的 O (nk) 反而更慢？我在 LeetCode 上发现的一个反常识真相

理论更优的 O (nk) 反而更慢？我在 LeetCode 上发现的一个反常识真相刷字母异位词分组这道题时，很多人都会遇到一个特别反直觉的现象： 书本上明明白白写着，计数法时间复杂度 O(nk)，严格优于排序法 O(nk log k)。可一上 LeetCode 提交，排序版代码跑得反而更快。 我一开始也以为是自己写得不够好，反复对比、优化之后才明白：这不是代码问题，是理论复杂度和真实运行环境之间的
#leetcode #数据结构与算法 #算法

分片上传流程全面技术分析报告

分片上传流程全面技术分析报告目录 概述 分片上传流程设计原理与技术架构 分片上传的必要性与优势分析 不采用分片上传的风险与影响评估 针对性优化方案 技术挑战与潜在问题预测 设计思路与技术选型追溯 总结与建议 概述本文档对PaiSmart项目中分片上传流程进行全面深入的技术分析。分片上传是处理大文件上传的核心技术方案，通过将大文件切分为多个小块（分片）进行独立上传，从根本上解决了传统整体上传方式
技术报告
#后端 #分片上传