引言

大家好，我叫立东，一名专注于Java和Vue3技术栈的全栈工程师。在过去的几年里，我不仅在本职工作中积累了丰富的经验，还通过自媒体平台进行知识分享，并成功实现了副业变现。今天，我想分享一下我的这段经历，希望能给同样对自媒体感兴趣的朋友们一些启发和帮助。

1. 起步阶段

第一次尝试

2020年5月2日，我在掘金平台上发布了我的第一篇文章。当时的初衷很简单，就是想记录自己的学习过程和技术心得。刚开始时，确实遇到了不少挑战，比如如何找到合适的选题、如何写出有吸引力的文章等。为了克服这些困难，我采取了以下几个步骤：

• 选题策略：我倾向于选择自己熟悉且受众感兴趣的话题，例如前后端分离、快速开发框架、Java、Vue、Docker、Kubernetes（K8s）以及工作流引擎等。这样不仅能够确保内容的专业性和准确性，还能更好地吸引和满足读者的需求。


• 写作技巧：其实我并没有特别参考他人的写作习惯，更多的是随心所欲地记录自己的想法和心得。因此，我的文笔可能并不完美，但我会尽量用最真诚和直接的方式表达自己。


• 互动反馈：积极回复读者的评论，收集反馈并不断改进。

坚持与成长

坚持了一年左右，我逐渐积累了一些宝贵的经验和粉丝。截至目前，我在掘金平台上的粉丝数虽然不算多，但也达到了700多人，发布了70多篇文章，总阅读量超过了27.2万次。尽管初期增长较为缓慢，但每一次点赞和评论都给了我极大的鼓励和支持。

2. 视频录制

转战B站

2021年8月1日，我决定将内容扩展到视频领域，并在B站上传了我的第一个视频。选择视频形式的原因主要是因为它能够更直观地展示技术细节，同时也能更好地与观众互动。从那时起，我基本上保持每天录制更新一个视频，坚持了一年半的时间。

我的视频主要从架构、提效以及研发管理者的角度进行录制。这类视频在市场上相对较少，因为大多数讲师录制的内容通常集中在实战项目或某个开发框架的使用上。然而，每家公司中能够并且需要搭建这类开发框架和开发脚手架的人并不多。因此，我的视频填补了这一空白，为那些希望提升整体开发效率和管理水平的技术人员提供了宝贵的知识资源。

最初，我的视频以合集的形式连更，每个课时大约四五十分钟。随着时间的推移，我逐渐将视频长度控制在十分钟左右，这样不仅更符合观众的观看习惯，也让我越来越适应这个录制节奏。录制的内容涵盖了前端、后端以及持续集成等多个方面，其中比较有代表性的系列是《SpringBoot+Vue3前后端分离工程化最佳实践(后端篇)》和《SpringBoot+Vue3前后端分离工程化最佳实践(前端篇)》，这些视频与我在掘金上发布的《打造一款适合自己的快速开发框架》系列文章相呼应。

截至目前，这两个合集的总课时数达到了407个，总播放量接近10万次。通过这些视频，我不仅能够更全面地分享我的技术知识，还获得了许多宝贵的反馈和支持。

粉丝增长

2023年3月8日，我的B站粉丝终于突破了1000人。这对我来说是一个重要的里程碑，也给了我继续前进的动力。事实上，我并未采取任何刻意的推广策略来迅速增加粉丝数量或提升他们的活跃度，也未曾深入思索过如何将这份影响力转化为经济收益。我始终秉持着一份纯粹的热爱与坚持，默默耕耘。当然可能是整个过程并未占用我过多的时间，录制视频于我而言，更像是一种轻松愉悦的表达方式，而非沉重的负担，所以才能坚持那么久的用爱发电。

3. 知识付费平台

我知道，一直用爱发电是很难坚持的，所以我开始尝试做突破……

知识星球

对我而言已略显陌生，因为它是我在很久以前就使用知识付费平台的，但遗憾的是，后续并未给予太多的运营关注。主要的原因在于，其配备的文章编辑器功能相对简陋，许多文章的编辑工作变得相当不便，这大大影响了我的使用体验与效率。因此，随着时间的推移，我逐渐减少了对它的管理与投入。

纷传

2023年5月，一个偶然的机会，看到了纷传这个知识付费平台，经过初步试用，我发现它基本上能够满足我对于文章创作与付费阅读功能的需求。然后在纷传创建了一个《立东和他的朋友们》的圈子，在这个圈子上，我不仅分享了一系列关于工作流引擎的专业文章，还提供了与我当前录制的视频课程紧密相关的文档链接及访问密钥。这一方式不仅丰富了我的内容创作生态，还意外地成为了我的一项副业收入来源，为我的月收入增添了亮丽的一笔。

4. 开源项目与爆发

开源项目

2023年12月16日，我上传了一个开源项目《快速开发框架+自研工作流管理系统》。这个项目旨在帮助开发者快速构建企业级应用。为了让更多人了解这个项目，我在掘金上发布了一篇《开源啦！！！轻量级工作流引擎管理系统》的文章，详细介绍了它的功能和使用方法。没想到，这篇文章被【稀土掘金技术社区】官方公众号和几个大V的公众号相继转载。也正因为如此，我开源项目关注量也稳定增长着，现在已经有8.3k的关注量。

5. 付费课程

入驻B站课堂

2023年11月15日，我正式入驻B站课堂，并于12月16日推出了我的第一门付费课程《全栈工程师带你从0~1设计实现轻量级工作流引擎》。这门课程受到了很多学员的好评，也为我带来了不错的收益。

后续课程

随后，我又陆续推出了几门付费课程，涵盖了多个主题：

• 2023年12月29日，《AI神器！阿里通义灵码从零带你开发前端代码生成器》。


• 2024年1月10日，《毕业设计！家庭记账管理系统！快速开发框架！》。


• 2024年5月4日，《AI助手开源引流VuePress站点动态权限控制》。


• 2024年6月25日，《工作流设计器开发最佳实践》。


• 2024年8月3日，《从0~1搭建前端快速开发框架VbenAdmin篇》（未完结）。

我的付费课程远未止步，未来还有更多课程等待我去录制与打磨。在明确的变现路径上，我将秉持初心，持续输出高质量的教学内容，为每一位求知者点亮前行的灯塔。

6. 变现成果

随着课程数量的增加，我的收益也在稳步增长。2024年8月份，我的课程收益首次突破了千元。这不仅是对我努力的认可，也证明了通过自媒体变现是完全可行的。

7. 经验总结与建议

坚持的重要性

持续输出内容，逐步积累粉丝。无论是文章还是视频，都需要持之以恒的努力。只有不断地提供有价值的内容，才能赢得用户的信任和支持。

内容质量

高质量的内容是吸引粉丝和变现的关键。无论是文章还是视频，都要确保内容的专业性和实用性。此外，清晰的表达和良好的视觉效果也是提升用户体验的重要因素。

社区互动

积极与粉丝互动，建立良好的社区氛围。通过回复评论、举办问答活动等方式，增强粉丝的参与感和归属感。这样不仅能提高粉丝的黏性，还能获得宝贵的反馈和建议。

多样化变现

通过多种方式变现，如付费课程、付费圈子等。不同的变现方式可以覆盖不同类型的用户需求，从而最大化收益。例如，付费圈子可以为用户提供更深入的技术支持和交流机会，而付费课程则可以系统地传授知识和技能。

兴趣很重要

兴趣真的很重要，因为兴趣大概率是处在自己的舒适圈，而舒适圈内，你可以坚持得更久，才有机会等到变现的到来。

多平台布局的反思

虽然我在B站上取得了一些成绩，但我也有些后悔没有同时在其他平台（如抖音）上进行内容发布。现在，我的抖音粉丝还没有达到1000人，导致一些功能无法使用。未来，我会考虑在多个平台上同步发布内容，以扩大影响力。同时，也会更加注重多平台的运营策略，以便更好地触达不同的用户群体。

结语

感谢大家一直以来的支持和陪伴。未来，我会继续努力，为大家带来更多有价值的内容。如果你有任何问题或建议，欢迎随时联系我。

附录

• 资源链接：
  
  
  
  • 快速开发框架
  
  
  • B站课程
  
  
  
  

12月今年最后一个月了,相逢的人已走散, Q4的OKR已经定型了, 很平淡无味, 闲的无聊 提前写个年终总结吧。00年, 再过一个月就25岁了，一个人来杭州也已经3年多了 每天有时间写一点 周六了 写到凌晨1点了 看直播/打麻将到凌晨5点才睡。 去年也写了一篇 2023年总结:日渐清醒，得失随意 //TODO DDL 应该是在月中完结吧。

工作

我大概回忆一下 我今年在工作上应该干了这些事情吧

• 自己申请换项目组,日常维护新品App版本迭代 2周一个版本 多个app同时进行


• 完成所有App 苹果服务器接口Storekit2 升级上线


• Google 支付/订阅 SDK 重构原生API调用代码


• RocketMQ优化多数据中心用户数据同步/webhook/推送


• RocketMQ-Exporter 搭建 监控相关性能指标


• SSE+服务器GRPC流式 推送消息


• us机器 内存优化 切换到jemalloc内存分配器


• RocketMQ 单机 升级为Dledger 集群模式 Q4 任务

从22年3月毕业到现在 再度过一个季度 在这家公司呆三年了(3年之约)，整个过程就是升级打怪，看着人来人往 合作的人 离职一个又来一个, 每个季度干着重复的工作,技术框架还是那一套 SpringBoot+GRPC 经过一年熟悉后 就觉得没有新鲜感了, C端产品App 在用户基数不大情况下 基本的重心在客户端的ui/操作体验上 后端嘛就是一个数据存储的地方 存取能有什么难度 大家都会，每个季度任务就是 基本的版本迭代+一些服务器内部的优化，如果你想要拿到高的绩效 那干这点是远远不够的, 基本规则在无告警的版本迭代下 做一些对团队贡献大 有价值的事情 拿A/季度优秀员工，三年期间升了两次小级别 p5-1->p5-2->p5-3 还是一个初级开发 今年估计也悬了 没有两次A的绩效 跨段位升没机会,没有owner过项目, 和旁边人朋友/同学工作/升职对比下 只能说自己像个废物 躺的太平了 每天965的生活 除了偶尔上线 需要加班留下来 大家都不加班 也没有那么多活需要加班来干的活。

• 你说工作上需求迭代的实现难度吧，喂给ChatGPT 技术方案/数据库表都给你生成好了 微改代码就行了，各种数据脚本go/python也是利用AI，主要难点还是在需求评审/需求理解/产品测试开发的沟通上面吧 组内的高级/资深开发 看了下他们的OKR也没有什么特别的 对自己也没有参考价值。CodeReview 去年还是有的 到今年直接提pr和leader讲下 也不会看的直接合进去了 组内其他人也是这样 他们的代码你也可以看 但你看的时候基本都是merged, 还有一个点 组内的信息同步很差 只有你问了xxx 原来xx项目做过。相对于22/23年和客户端那边对接起来很累,身份位置放的很低, 沟通下来都是无效沟通 他不理解你的想法 不想听你的方案，今年换了一个项目组 合作起来比较顺利，你的想法都会被接受 还会给你优化的意见 整体的体验还是不错的。


• 在工作中，除了技术能力，还需要考验为人处事的能力，获取信息和与人打交道的能力, 这点我解决不了 公司没有同龄人 他们基本都有自己的家庭 找个抽烟的人都没有 今年午饭也没有和他们吃过 还是住在旁边小区 公司午休一刻呆不下去,回家坐着都比在公司舒服，我现在基本是只谈工作不谈生活,可能他们都有自己的圈子/群吧, 其实很多时候都不想干了 每天定点上班下班的生活真的很无趣和累，上班成天坐在那里，一句话都憋不出来，是个人都会崩溃的，再看看自己的实力 也很难找到一份比现在965更满意的工作了,💰的话在杭州能活 先🐶着吧 看看base能不能提一下 拿个年终奖。
  
  

  
  

  在Q2/Q3其实是收获最大的 对个人成长的点 (版本迭代真拿不出手)

  
  

  
  
  
  
  • (Q2)RocketMQ业务接入优化 2024 Q2 OKR 完结 RocketMQ优化Webhook处理等业务场景 (已上线)最近需要使用MQ优化相关业务 - 掘金
  
  
  • (Q1/Q2)Apple订阅 storeki2升级 文档阅读/资料收集理解/官方库阅读参与简单的贡献Apple Storekit2 服务器API升级 (Apple开源内购库) (已上线)在今年Q1季度 组内进行服务器新技 - 掘金。
  
  
  • (Q3)内存问题排查 Java服务 堆内-> 堆外-> Glibc内存 异常排查 最佳实践, 形成自己的方法论💥-线上环境临时解决方案: 先重 - 掘金
  
  
  • (Q2)Google支付订阅 跨境支付 Google Pay(购买/订阅) SDK优化重构 原生API-V1/V2代码 (已上线)最近转新品组了,没有 - 掘金
  
  
  
  

生活

去年立的flag 也是一腔鸡血

• 软考 系统架构师 +软著 拿到杭州E类人才


• 健身/减肥


• 骑车 vlog (杭州景点全部骑完 影石360 ace pro)


• 摄影佳能rp/视频剪辑学习


• 日语/英语学习


• leetcode 上Knight


• 考D驾-照 骑防赛


• 日麻线下雀庄体验 参加各种线上日麻比赛


• ClickHouse hangzhou 线下沙龙


• 掘金bolg 更新 技术日常


• 千岛湖


• 抽烟+喝酒


• B站 直播 日麻

软考 系统架构师+软著 拿到杭州E类人才

• 系统架构师 运气挺好的 去年第一次考没过 今年5月份第二次考 压着分数线通过 (52/46/45) E类通过之后 把应届生租房补贴5000/半年 改为2500/月 相当于每个月的租房不要钱了,共有产权房子不考虑 没有在杭州落户的想法, 具体的就不多说 看这篇blog总结都有了 想了解流程可以私聊我解答 (杭州e类人才) 软考-系统架构师 (52/46/45)—浙江树人学院/浙江工业大学2024/05/25 软考-系统架构 - 掘金

骑车 vlog (杭州景点全部骑完 影石360 ace pro)

• 一个人走走停停 骑过很多地方, 最多的还是钱塘江到彭浦大桥->复兴大桥路线 不知道骑了多少遍，西湖/湘湖/九溪这些地方都去过了，车子是青春款只在线上售卖 后期毛病很多 链条蹭盘/刹车无效 自己不知道维修了多少次，最近这两个月很少骑了，放在地下室发霉 后续准备卖掉了这车 还买了那么多骑行装备，买的insta 360 ace pro 3000多降价到2k左右 当时在大疆和insta中选择了好久 最后还是踩坑了 实体店体验了大疆action 画质比insta360好太多了，有必要考虑再买一台大疆action5了, 一个人的骑行之路也该结束了 开始新的玩具 仿赛摩托车 芜湖起飞。

健身/减肥

• 怎么说呢 三天打鱼两天晒网的行动 体脂没什么变化,饮食更不会控制 每天外卖外卖外卖, Q1/Q2两个季度挺积极的 基本工作日晚上有时间就去健身房 周末白天也去, 在健身房的时间也能让自身感受到轻松, 这个小区有个百姓健身房在地下室 24小时 刷脸进去 设备齐全 没什么人 每个季度的话300块RMB, 我主要后面可能没有看到短期效果+活着很累 有一段时间没有去了, 偶尔下楼抽烟去逛逛, 最后得到的只是自己的一个心里安慰，没有合理的计划和坚持下去的心 我现在已经懒连手表都不戴了。

摄影佳能rp/视频剪辑学习

• 怎么说呢 周末放假就是宅 已经吃灰了 除了9月1号 拿到免费的门票 杭州植物园专门去了一趟拍彼岸花，其他时间不出手。视频剪辑也是一坨屎 目前就用剪映弄一些雀魂麻将抽角色的视频，后续还是想学一下专业的剪辑工具 这个也看需求吧。

考D驾-照 骑防赛

• 为什么要去骑摩托车，主要是中秋节回家一趟，隔壁邻居已经买了一辆机车, 当时他让我试试 我没试 后面就一直关注摩托车这个事 抖音一直给我推视频。才有了考D驾-照驾-照,周末练半天,工作日考试半天就好了,4科联考 比C1驾-照周期短 速度快，驾-照到手后面周末直接找附近最近的租车平台试试水，萧山那边的之江路/美女坝路险,本田500 手震麻了 1个小时 干了100公里, 最后一个半小时就还车了 跑了150km，整体的体验感是非常好的，无论是去骑车的路上 还是过程中 都能够忘记生活/工作上的烦心事，最尴尬的是红绿灯起步熄火了，后续周末继续出行租车，找个有缘人一起。

日麻线上比赛/线下雀庄体验

• 每天下班就是点外卖 开始打麻将，水各种日麻群 打友人赛/团队赛，每天晚上达到2 3点 菜就爱多玩 和群友打比赛 对个人的实力也是有了认知 学习别人的打法 从野猪冲击 也慢慢在意铳率了，前一天打完线上比赛, 这个月周日也是马上跟着一个大哥去杭州线下的湖滨牌浪屋体验完线下日麻，今年干的最多的事情就是打麻将，下班除了打麻将还是打麻将。

leetcode 上Knight

• 基本上是原地没动，比赛一场没打，为什么要刷？为了什么？能带给自己什么收益？呆在舒适圈里久了 不想出去，算法也是提不上一点兴趣了 估计只有到时候找工作之前才会接触到了 其实也制定了计划 刷灵神的清单 还是自己懒吧 动不起来，最后一个月 要不开始发力？算了 打麻将吧。

其他

• 今年参加了ClickHouse hangzhou 线下沙龙, 虽然没有使用过clickhouse这款db,去听听别人公司的落地方案,去阿里园区转了转。


• 掘金bolg 更新 技术日常 主要是参加创作者训练营吧 锻炼一点自己的文本输出能力，总结的过程中也能知道问题的本质是什么，解决的过程/方式以及别人是怎么解决的，收获还是有的。


• 和同学五一去了千岛湖一趟 结局不是很好 过程体验不错。


• 在日语/英语学习上面投入的时间 ，无论是日常工作上英语的使用 还是各种文档阅读能力，在逛各种项目/看论文的时候 就能体现出来, 日语兴趣的话 纯粹是打日麻和旁边的日麻群友影响/看番剧而来的 每天用多邻国完成任务,买了4本书《标准日语》+《大家的日语》,在B站上看圆圆姐的视频教程【京大博士带你学日语】新标日初级上册全新课程！必能学会！超详细讲解！轻松搞定日语学习！（课本内容完结！）哔哩哔哩bilibili。


• 抽烟+喝酒已经是家常便饭一样的事情了 上半年是沉迷于喝酒消愁 下半年就抽烟打发时间，每天下班又不知道干什么 找点打发时间的乐趣，天天熬夜看直播 打麻将 2点3点睡觉已经是常态了,每天晚上看陈伯/刘刘江直播 带来的乐趣, 工作日每天基本8点50的闹钟吵醒，拖着尸体去上班，周末基本睡到自然醒中午/下午 除了楼上楼下装修 直接被震醒了。


• 这样一回想2024年还是干了很多无意义的事。

虽然只有15篇文章 文章的阅读数也有3w 其实数据对我来说也是无所谓的，主要还是方便以后回忆吧,分享出去 可能有人和你遇到相同问题,带给解决思路 明年要不要继续写？还是把时间投入在别的地方？都是未知

个人技术学习

• AI 知识点拓展学习


• 部门分享


• 推荐系统&&RAG


• 前端


• 第三方支付订阅


• 分布式论文学习总结


• 《计算机网络-自顶向下方法第七版》


• 《CSAPP 深入理解计算机系统(第3版)》


• 《设计数据密集型应用》


• 技术拓展/深挖(RocketMq源码/go-redis源码/Netty源码/Mycat2源码)

看个锤子 没心思学习 下半年天天打麻将

• AI的话主要是身边环境影响，自己的项目组一直在利用AI做业务，从2023年开始 公司一直对接的是openai 提供的chat 能力，公司内部举行了ai相关的比赛，业务想要搭建自己的知识库和RAG搜索 主要是用AWS上的Redrock封装好的知识库 ，项目组一些APP一直在使用微软的TTS进行语言转音频的操作，部门,组内和项目组 大家一直在内部分享和ai相关的知识点，产品会使用cursor提前将需求写完 自己进部署上线。


• 跟着项目组业务走，最近在支付方面的功能进行了改动，对于web网页上的购买消耗型商品/续费型商品的购买，主要对接的平台是Stripe信用卡visa支付 和paypal支付。appstore 支付的话 最近负责组内storekit2 服务器接口升级重构代码 用的官方开源库 github.com/apple/app-s…。Alipay 支付宝和Wechat 对于中国环境的用户提供的一种支付方式, 代码很粗糙 很久没有相关需求迭代了。Google 支付 来的两年时间接触的业务还是比较少，整个支付逻辑和appstore是一致的，有时间把代码逻辑和官方文档进行学习总结一下。


• 现在只会个后端远远不够了，替代性太强了，除非是中大厂那样细分工作岗位/业务内容，如果你有自己的想法 后续做一些自己的产品/独立开发者 一人一公司 全栈只能是无敌路。我这边对前端也是零零散散的学习 没有整个的大项目使用，github.com/lobehub/lob… 前端React开源项目学习 TSX+TS 认知冲击 原来前端已经进化到这个地步了，没有html+css全部被封装了，我们内部的数据平台还是原生html+django搭建的，每次加新功能ai生成的代码 能跑就行。

在下半年 觉得基础知识很重要 技术跟着业务走 没必要太追求新技术 就往计算机基础知识+算法+基础论文投入时间

• 中间一段也是将《计算机网络-自顶向下方法第七版》 计算机网络-自顶向下方法第七版 · 语雀和《CSAPP 深入理解计算机系统(第3版)》CSAPP 深入理解计算机系统(第3版) · 语雀 细看了一遍 , 书籍买了很多 都是吃灰的 没有去年那个干劲了。


• 看论文 可以学习技术理论的基础 还有重要一点是学英语, 主要是看一个up在学习这方面的知识点 就跟着看了一段时间，谷歌三大剑客 GFS/MapReduce/BigTable 看论文不看分布式论文 就像四大名著不读红楼梦，唐诗不读李杜，吃泡面不加调料包 Raft/Paxos 那一块真的一看就是几天 深陷进去 每次看硬核课堂的文章 Raft -论文导读 与 ETCD源码解读。


• 参与开源项目任务也没有达成 往里面投入的时间太少了，最后下班/上班有时间 也没深入去学习业务上用到的组件源码, 最近的话 负责RocketMQ集群Dledger搭建/MQ优化业务 ,RocketMQ-exporter+herzbeat+prometheus监控指标, 遇到的异常信息太多 每次都是网上找案例解决，上班利用ai 深入在看看RocketMQ源码吧github.com/apache/rock… 边看边总结RocketMQ 源码 5.2.0 - 生产者 Producer

杂学杂记

• 中间又去了解了下机器学习/深度学习相关的内容，又看了大数据开发Spark/Flink等等组件，前端看了React+TS相关知识点/demo/Flutter开源项目, 背单词的时候发现墨墨背单词是node+ts写的,有个软考刷题的app是Flutter写的 作者是独立开发者 最近公司客户端也在用flutter开发新品app 代码我这边也是有权限的, 也去了解了一下技术栈，中间又有一段时间去了解了下亚马逊运营的工作，也看了AIGC/agent/图像/音频/向量数据库milvus等相关的方向 RAG 知识库增强式搜索，在推荐系统领域 推荐 广告 搜索 也花了一段时间去了解/学习 因为我们这边没有算法工程师 推荐功能很粗糙 没有用户画像的概念,有一段时间被cloudwego社区的kitex/hertz吸引 当时想去上海站的线下沙龙 可惜正好那周软考考试, 因为有个麻将牌谱工具是rust写的 github.com/Equim-chan/… 所以又去了解了一下rust，我记得有段时间投入在系统设计/业务场景思考方向(IM/Feed流/本地消息表/分布式限流等等), 都是一点毛皮，Q2服务器服务的内存问题 每天上班想下班想 把互联网的文章都翻烂了 从堆内到堆外到Glibc 询问各种技术大佬场景异常 组内成员给不了你任何帮助 全靠自己，所有的东西没有实质性的收获 也没有在项目中使用到 过了一段时间基本全忘了(不做笔记/总结) 。

现在往回看 在技术学习的时长投入的太少了 对技术没有追求 什么都知道一点 什么都不精通 啥也没学会 离开了Java/Spring 我还能干什么，我能干的 找个会使用AI的人来都能干，天天熬夜 不知道熬的是什么 碌碌无为。最近一年 代码写的很少了 基本靠ai生成 微改/设计一下 写的自己也看不懂了。生活/工作迷茫 现在都是活一天是一天, 想回家。

后续规划 待定

• 英语/日语


• 独立开发者

打麻将去咯 一起玩雀魂的可以加我

在 MySQL 中，limit X,Y 的查询中，X 值越大，那么查询速度也就越慢，例如以下示例：

• limit 0,10：查询时间大概在 20 毫秒左右。


• limit 1000000,10：查询时间可能是 15 秒左右（1秒等于 1000 毫秒），甚至更长时间。

所以，可以看出，limit 中 X 值越大，那么查询速度都越慢。

这个问题呢其实就是 MySQL 中典型的深度分页问题。那问题来了，为什么 limit 越往后查询越慢？如何优化查询速度呢？

为什么limit越来越慢？

在数据库查询中，当使用 LIMIT x, y 分页查询时，如果 x 值越大，查询速度可能会变慢。这主要是因为数据库需要扫描和跳过 x 条记录才能返回 y 条结果。随着 x 的增加，需要扫描和跳过的记录数也增加，从而导致性能下降。

例如 limit 1000000,10 需要扫描 1000010 行数据，然后丢掉前面的 1000000 行记录，所以查询速度就会很慢。

优化手段

对于 MySQL 深度分页比较典型的优化手段有以下两种：

1.起始ID定位法

起始 ID 定位法指的是 limit 查询时，指定起始 ID。而这个起始 ID 是上一次查询的最后一条 ID。例如上一次查询的最后一条数据的 ID 为 6800000，那我们就从 6800001 开始扫描表，直接跳过前面的 6800000 条数据，这样查询的效率就高了，具体实现 SQL 如下：

select name, age, gender

from person

where id > 6800000 -- 核心实现 SQL

order by id limit 10;

其中 id 字段为表的主键字段。

为什么起始ID查询效率高呢？

因此这种查询是以上一次查询的最后 ID 作为起始 ID 进行查询的，而上次的 ID 已经定位到具体的位置了，所以只需要遍历 B+ 树叶子节点的双向链表（主键索引的底层数据结构）就可以查询到后面的数据了，所以查询效率就比较高，如下图所示：

如果上次查询结果为 9，之后再查询时，只需要从 9 之后再遍历 N 条数据就能查询出结果了，所以效率就很高。

优缺点分析

这种查询方式，只适合一页一页的数据查询，例如手机 APP 中刷新闻时那种瀑布流方式。

但如果用户是跳着分页的，例如查询完第 1 页之后，直接查询第 250 页，那么这种实现方式就不行了。

2.索引覆盖+子查询

此时我们为了查询效率，可以使用索引覆盖加子查询的方式，具体实现如下。

假设，我们未优化前的 SQL 如下：

select name, age, gender

from person

order by createtime desc 

limit 1000000,10;

在以上 SQL 中，createtime 字段创建了索引，但查询效率依然很慢，因为它要取出 100w 完整的数据，并需要读取大量的索引页，和进行频繁的回表查询，所以执行效率会很低。

此时，我们可以做以下优化：

SELECT p1.name, p1.age, p1.gender

FROM person p1

JOIN (

    SELECT id FROM person ORDER BY createtime desc LIMIT 1000000, 10

) AS p2 ON p1.id = p2.id;

相比于优化前的 SQL，优化后的 SQL 将不需要频繁回表查询了，因为子查询中只查询主键 ID，这时可以使用索引覆盖来实现。那么子查询就可以先查询出一小部分主键 ID，再进行查询，这样就可以大大提升查询的效率了。

索引覆盖（Index Coverage）是一种数据库查询优化技术，它指的是在执行查询时，数据库引擎可以直接从索引中获取所有需要的数据，而不需要再回表（访问主键索引或者表中的实际数据行）来获取额外的信息。这种方式可以减少磁盘 I/O 操作，从而提高查询性能。

课后思考

你还知道哪些深度分页的优化手段呢？欢迎评论区留下你的答案。

本文已收录到我的面试小站 http://www.javacn.site，其中包含的内容有：Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。

故事背景

在八股文中，说到如何进行数据库的优化，除了基本的索引优化，经常会提到分库分表，说是如果业务量剧增，数据库性能会到达瓶颈，如果单表数据超过两千万，数据查询效率就会变低，就要引入分库分表巴拉巴拉。我同事也问我，我们数据表有些是上亿数据的，为什么不用分库分表，如果我没接触过分库分表我也会觉得大数据表就要分库分表呀，这是八股文一直以来教导的东西。但是我就跟他说，分库分表很坑爹，最近才让我遇到一个BUG......

系统复杂度upup

业务中有个设备表数据量很大，到现在为止已经有5、6亿数据了。在4年前，前人们已经尝试了分库分表技术，分了4个库，5个表，我只是负责维护这个业务发现他们用了分库分表。但是在查询表数据的时候看到是查询ES的，我就问为什么要用ES？同事回答查询分库分表一定要带分片才能走到路由，否则会查询全部库和全部表，意思是不查分片字段，单表只用一个SQL，但是分库分表要用20个SQL.....所以引入了ES进行数据查询。但是引入ES之后又引入一个新的问题，就是ES和数据库的数据同步问题。他们使用了logstash做数据同步，但不是实时的，在logstash设置了每20秒同步一次。

因为要使用分库分表，引入了shardingjdbc，因为查询方便引入了es，因为要处理数据同步问题引入了logstash......所以系统复杂度不是高了一点半点，之前发现有个字段长度设置小了，还要改20张表。

分页问题

最近遇到一个奇怪的bug，在一个设备的单表查询翻页失败，怎么翻都只显示第一页的数据，一开始我以为是分页代码有问题，看了半天跟其他表是一样的，其他表分页没问题，见鬼了。后面再细看发现这个单表的数据源是设备数据源，用的是shardingjdbc的配置。

之前就看过shardingjdbc有一些sql是不支持的，怀疑就是这个原因，百度了一下果然是有bug。

想了一下有两个解决办法，第一个是升级shardingjdbc的版本，据说是4.1之后修复了该问题，但是还没有尝试。

第二个办法是把分库分表业务的数据源跟单表区分开，单表业务使用普通的数据源后分页数据正常显示。

关于数据库优化

一般来说数据库优化，可以从几个角度进行优化：

1、硬件优化

(1) 提升存储性能

• 使用SSD：替换传统机械硬盘（HDD），SSD能提供更快的随机读写速度。


• 增加存储带宽：采用RAID（推荐RAID 10）提高数据存储的读写速度和冗余。


• 内存扩展：尽量让数据库缓存更多的数据，减少IO操作。

(2) 增强CPU性能

• 使用多核高频率CPU，支持更高并发。


• 分析数据库对CPU的利用情况，确保不被CPU性能瓶颈限制。

(3) 提高网络带宽

• 优化服务器与客户端之间的网络延迟和带宽，尤其是分布式数据库的场景中。


• 使用高速网络接口（如10GbE网卡）。

2、软件层面优化

(1) 数据库配置

• 调整数据库缓冲池（Buffer Pool）的大小，确保能缓存大部分热数据。


• 优化日志文件的写入（如MySQL中调整innodb_log_buffer_size）。


• 使用内存数据库或缓存技术（如Redis、Memcached）加速访问速度。

(2) 分布式架构

• 对于高并发需求，采用分布式数据库（如TiDB、MongoDB）进行读写分离或数据分片。

(3) 数据库索引

• 选择合适的索引类型：如B+树索引、哈希索引等，根据查询特点选择适配的索引。


• 避免冗余索引，定期清理无用索引。

(4) 数据库版本升级

• 保持数据库版本为最新的稳定版本，利用最新的优化特性和Bug修复。

3. SQL层面优化

(1) 查询优化

• 减少不必要的字段：只查询需要的列，避免使用SELECT *。


• 加速排序和分组：在ORDER BY和GR0UP BY字段上建立索引。


• 拆分复杂查询：将复杂的SQL分解为多个简单查询或视图。


• 分页查询优化：如避免大OFFSET分页，可以使用索引条件替代（如WHERE id > last_seen_id）。

(2) 合理使用索引

• 对频繁用于WHERE、JOIN、GR0UP BY等的字段建立索引。


• 避免在索引列上使用函数或隐式转换。

(3) 减少锁定

• 尽量使用小事务，减少锁定范围。


• 使用合适的事务隔离级别，避免不必要的资源等待。

(4) SQL调优工具

• 使用数据库自带的分析工具（如MySQL的EXPLAIN、SQL Server的性能监控工具）来分析查询计划并优化执行路径。

4. 综合优化

• 定期进行性能分析：定期查看慢查询日志，优化慢查询。


• 清理历史数据：对于不再使用的历史数据，可存储到冷数据仓库，减少主数据库的负载。


• 使用连接池：通过数据库连接池（如HikariCP）管理和复用连接，降低创建和销毁连接的开销。

tips:

现网的数据库是64核128G内存，测试环境是32核64G，加上现网数据库配置的优化，现网数据库查询大表的速度是测试环境的3倍！所以服务器硬件配置和数据库配置都很重要。下面是数据库的配置文件，仅供参考

[universe]

bakupdir = /data/mysql/backup/7360

iops = 0

mem_limit_mb = 0

cpu_quota_percentage = 0

quota_limit_mb = 0

scsi_pr_level = 0

mycnf = /opt/mysql/etc/7360/my.cnf

run_user = actiontech-mysql

umask_dir = 0750

umask = 0640

id = mysql-mt1cbg

group_id = mysql-test



[mysql]

no-auto-rehash

prompt = '\\u@\\h:\\p\\R:\\m:\\s[\\d]> '

#default-character-set = utf8mb4

#tee = /data/mysql_tmp/mysql_operation.log



[mysqld]

super_read_only = 1

# DO NOT MODIFY, Universe will generate this part

port = 7360

server_id = 123

basedir = /opt/mysql/base/5.7.40

datadir = /data/mysql/data/7360

log_bin = /opt/mysql/log/binlog/7360/mysql-bin

tmpdir = /opt/mysql/tmp/7360

relay_log = /opt/mysql/log/relaylog/7360/mysql-relay

innodb_log_group_home_dir = /opt/mysql/log/redolog/7360

log_error = /data/mysql/data/7360/mysql-error.log

# 数据库ip

report_host = xxx



# BINLOG

binlog_error_action = ABORT_SERVER

binlog_format = row

binlog_rows_query_log_events = 1

log_slave_updates = 1

master_info_repository = TABLE

max_binlog_size = 250M

relay_log_info_repository = TABLE

relay_log_recovery = 1

sync_binlog = 1



# GTID #

gtid_mode = ON

enforce_gtid_consistency = 1

binlog_gtid_simple_recovery = 1



# ENGINE

default_storage_engine = InnoDB

innodb_buffer_pool_size = 64G

innodb_data_file_path = ibdata1:1G:autoextend

innodb_file_per_table = 1

innodb_flush_log_at_trx_commit = 1

innodb_flush_method = O_DIRECT

innodb_io_capacity = 1000

innodb_log_buffer_size = 64M

innodb_log_file_size = 2G

innodb_log_files_in_group = 2

innodb_max_dirty_pages_pct = 60

innodb_print_all_deadlocks = 1

#innodb_stats_on_metadata = 0

innodb_strict_mode = 1

#innodb_undo_logs = 128                 #Deprecated In 5.7.19

#innodb_undo_tablespaces=3          #Deprecated In 5.7.21

innodb_max_undo_log_size = 4G

innodb_undo_log_truncate = 1

innodb_read_io_threads = 8

innodb_write_io_threads = 8

innodb_purge_threads = 4

innodb_buffer_pool_load_at_startup = 1

innodb_buffer_pool_dump_at_shutdown = 1

innodb_buffer_pool_dump_pct = 25

innodb_sort_buffer_size = 8M

#innodb_page_cleaners = 8

innodb_buffer_pool_instances = 8

innodb_lock_wait_timeout = 10

innodb_io_capacity_max = 2000

innodb_flush_neighbors = 1

#innodb_large_prefix = 1

innodb_thread_concurrency = 64

innodb_stats_persistent_sample_pages = 64

innodb_autoinc_lock_mode = 2

innodb_online_alter_log_max_size = 1G

innodb_open_files = 4096

innodb_temp_data_file_path = ibtmp1:12M:autoextend:max:50G

innodb_rollback_segments = 128

#innodb_numa_interleave = 1



# CACHE

key_buffer_size = 16M

tmp_table_size = 64M

max_heap_table_size = 64M

table_open_cache = 2000

query_cache_type = 0

query_cache_size = 0

max_connections = 3000

thread_cache_size = 200

open_files_limit = 65535

binlog_cache_size = 1M

join_buffer_size = 8M

sort_buffer_size = 2M

read_buffer_size = 8M

read_rnd_buffer_size = 8M

table_definition_cache = 2000

table_open_cache_instances = 8





# SLOW LOG

slow_query_log = 1

slow_query_log_file = /data/mysql/data/7360/mysql-slow.log

log_slow_admin_statements = 1

log_slow_slave_statements = 1

long_query_time = 1



# SEMISYNC #

plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"

rpl_semi_sync_master_enabled = 1

rpl_semi_sync_slave_enabled = 0

rpl_semi_sync_master_wait_for_slave_count = 1

rpl_semi_sync_master_wait_no_slave = 0

rpl_semi_sync_master_timeout = 30000



# CLIENT_DEPRECATE_EOF

session_track_schema = 1

session_track_state_change = 1

session_track_system_variables = '*'



# MISC

log_timestamps = SYSTEM

lower_case_table_names = 1

max_allowed_packet = 64M

read_only = 1

skip_external_locking = 1

skip_name_resolve = 1

skip_slave_start = 1

socket = /data/mysql/data/7360/mysqld.sock

pid_file = /data/mysql/data/7360/mysqld.pid

disabled_storage_engines = ARCHIVE,BLACKHOLE,EXAMPLE,FEDERATED,MEMORY,MERGE,NDB

log-output = TABLE,FILE

character_set_server = utf8mb4

secure_file_priv = ""

performance-schema-instrument = 'wait/lock/metadata/sql/mdl=ON'

performance-schema-instrument = 'memory/% = COUNTED'

expire_logs_days = 7

max_connect_errors = 1000000

interactive_timeout = 1800

wait_timeout = 1800

log_bin_trust_function_creators = 1



# MTS

slave-parallel-type = LOGICAL_CLOCK

slave_parallel_workers = 16

slave_preserve_commit_order = ON

slave_rows_search_algorithms = 'INDEX_SCAN,HASH_SCAN'



##BaseConfig

collation_server = utf8mb4_bin

explicit_defaults_for_timestamp = 1

transaction_isolation = READ-COMMITTED



##Unused

#plugin-load-add = validate_password.so

#validate_password_policy = MEDIUM

总结

如果我没用过分库分表，面试官问我数据库优化，我可能也会回答分库分表。但是踩过几个坑之后可能会推荐其他的方式。

1、按业务分表，比如用户表放在用户库，订单表放在订单库，用微服务的思想切割数据库减少数据库压力。

2、如果数据量超过10E，可以考虑上分布式数据库，融合了OLAP和OLTP的优点，毕竟mysql其实不适合做大数据量的查询统计。评论区也可以推荐一下有哪些好的数据库。

3、按时间归档数据表，每天或者每个月把历史数据存入历史数据表，适用于大数据量且历史数据查询较少的业务。

每个技术都有它的利弊，比如微服务、分库分表、分布式数据库等。按需选择技术类型，切勿过度设计！

今天前端一直在群里说，服务是不是又挂了？一直返回 503。我一听这不对劲，赶紧看了一眼 K8S 的 pod 状态，居然重启了4次。测试环境只有一个副本，所以赶紧把副本数给上调到了3个。

堵住前端的嘴，免得破坏我在老板心目中的形象，我害怕下次加薪名单没有我，而优化名单有我。

暂时安抚好前端之后我得立马看看哪里出问题了，先看看 K8S 为什么让这个容器领盒饭了。

Last State: Terminated 

Reason: OOMKilled

看起来是 JVM 胃口太大，被 K8S 嫌弃从而被赶走了。看看最近谁提交部署了，把人拉过来拷问一番。

代码摆出来分析，发现这小子每次使用http调用都会 new 一个连接池对象。一次业务请求使用了 6 次 http 调用，也就是会 new 6 个连接池对象。有可能是这里的问题，抓紧改了发上去测试看看。

不出意外的话又出意外了，上去之后也没缓解，那就不是这个问题了。要找到具体的原因还是不能瞎猜，得有专业的工具来进行分析才行。之前为了省点镜像空间，所以使用了 jre 的基础镜像。

总所周知，jre 只有一个运行环境，是没有开发工具的。所以我们得使用 jdk。你说我为省那点空间干什么？都想抽自己了。我们应该以 "让打靶老板花钱"为荣，以 "为打靶老板省钱"为耻。

把JDK准备好之后，就要开始我的第一次了。开始之前总是需要洗白白的，把一些影响心情的东西全部处理掉，就像这个 Skywalking，之前一直跟着我。但现在影响到我了，我得暂时把它放一边。不然他会在进行的过程中一直蹦出来烦人。

使用 Skywalking 需要设置此环境变量，每一次执行Java相关的命令都会执行 Skywalking 的一些操作，可以使用 unset 命令把环境变量临时置空。因为等我做完还是需要他来继续给我工作的。

unset JAVA_TOOL_OPTIONS

琐碎事处理完了之后，就得挑个技师才行。这行命令一把梭就会打印出所有 java 进程信息，这主要是为了获取到 vmid，也就是技师的编号。

jps -lv

root@xxx-ext-6464577d8-vvz2n:/app# jps -lv

608 sun.tools.jps.Jps -Denv.class.path=.:/usr/local/java/lib/rt.jar:/usr/local/java/lib/dt.jar:/usr/local/java/lib/tools.jar -Dapplication.home=/usr/local/openjdk-8 -Xms8m

7 /root/app/xxx-ext.jar -javaagent:/skywalking/agent/skywalking-agent.jar -Dfile.encoding=UTF-8 -Xms1024m -Xmx2048m

568 sun.tools.jstat.Jstat -javaagent:/skywalking/agent/skywalking-agent.jar -Denv.class.path=.:/usr/local/java/lib/rt.jar:/usr/local/java/lib/dt.jar:/usr/local/java/lib/tools.jar -Dapplication.home=/usr/local/openjdk-8 -Xms8m

这里总共查到3个Java进程，608 jps、7 xxx-ext 和 568 jstat。中间这个 7 号技师 xxx-ext 就是我相中的，我将会把第一次交给他。

选完技师就正式开始了，过程中要时刻关心对方的身体状态。隔几秒钟就问一下状态怎么样？为了方便时刻了解对方的身体状态，可以用这个命令每隔5s就问一下。如果你对自己的能力有信心可以把间隔设置短一些。

# jstat -gcutil {vmid} {间隔毫秒}

jstat -gcutil 7 5000

root@xxx-ext-6464577d8-vvz2n:/app# jstat -gcutil 7 5000

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT

 99.96   0.00 100.00 100.00  95.85  94.74    178    8.047     8    3.966   12.012

 99.97   0.00 100.00 100.00  95.50  94.33    178    8.047    11    8.072   16.118

 99.99   0.00 100.00 100.00  95.51  94.33    178    8.047    14   12.408   20.455

100.00   0.00 100.00 100.00  95.48  94.30    178    8.047    18   17.140   25.187

100.00   0.00 100.00 100.00  95.48  94.30    178    8.047    23   22.730   30.776

100.00   0.00 100.00 100.00  95.48  94.30    178    8.047    27   27.035   35.082

100.00   0.00 100.00 100.00  95.49  94.30    178    8.047    32   32.614   40.661

虽然是第一次，但对方给回来的信息务必要了然于胸。知己知彼胜券在握，所以要把下面的心法记住。这会影响我们下一步的动作。

S0/S1 是Survivor区空间使用率

E 是新生代空间使用率

O 是老年代空间使用率

YGC 是 Young GC 次数

YGCT 是 Young GC 总耗时

FGC 是 Full GC 次数

FGCT 是 Full GC 总耗时

当对方的状态到达一个关键点的时候，一般是老年代满，或者是新生代满，这就表示对方快溢出来了。像我提供的这个示例，E 和 O 的使用率都是100，就说明对方不仅满了，还快噶了。我们得赶紧把这个关键时刻详细探究一下，看看是哪个对象让对方感觉到满的。

用这个命令查询对方体内对象占用排名，不用贪多，前10个就绰绰有余了。你能把前10个全部弄清楚就够牛了。

jmap -histo:live 7 | head -n 10

root@xxx-ext-6464577d8-vvz2n:/app# jmap -histo:live 7 | head -n 10



 num     #instances         #bytes  class name

----------------------------------------------

   1:        454962     1852234368  [C

   2:       1773671       56757472  java.util.HashMap$Node

   3:        881987       30188352  [B

   4:         55036       19781352  [Ljava.util.HashMap$Node;

   5:        857235       13715760  java.lang.Integer

   6:        852094       13633504  com.knuddels.jtokkit.ByteArrayWrapper

   7:        454195       10900680  java.lang.String

   8:        104386        6436624  [Ljava.lang.Object;

   9:        191593        6130976  java.util.concurrent.ConcurrentHashMap$Node

  10:         63278        5568464  java.lang.reflect.Method

可以看到对方已经在边缘了，我们要抓紧分析了。我提供的这个示例，排名前三分别是 [C、java.util.HashMap$Node 和 [B，[C 表示字符数组，[B 表示字节数组。看来对方偏爱 [C，占用差不多1.7G，需要重点分析它。

这一步就到了十字路口，关键点在于我们能不能从这里分析得到对方偏爱的对象，从而定位到代码中的问题点。一旦我们定位到代码中的问题点，那就证明对方已经被我们拿捏了，流程结束。

那就开始分析吧，先看看最近哪个瘪犊子提交了代码，把他拉过来。然后看最近改动的代码哪里和 [C 相关，一般是 List<String>、StringBuffer 这类对象。

我没想到小丑竟是我自己🤡，有一个接口入参是一个 List<ID>，当这个 list 传了空的时候，就会把库里的所有数据都查出来。

破案了，这次把对方完全拿捏了，流程结束。

如果上一步无法拿捏，那就不要讲武德了。把对方的一举一动dump下来，最终导出成堆快照来分析。

dump 时间取决于数据量

jmap -dump:live,format=b,file=heap.hprof 7

root@xxx-ext-6464577d8-vvz2n:/app# jmap -dump:live,format=b,file=heap.hprof 7

Dumping heap to /app/heap.hprof ...

Heap dump file created

将dump文件从pod中复制出来

kubectl cp <ns>/<pod>:/app/heap.hprof ./heap.hprof

kubectl cp test/xxx-ext-6464577d8-vvz2n:/app/heap.hprof ./heap.hprof

我摊牌了，这一步我压根没做。

当我想从pod中把对快照复制出来的时候磁盘空间不够，然后pod就被 K8S 这个暴脾气干了，只剩下我颤抖的手无力地放在键盘上。

Ref

juejin.cn/post/700622…

发生什么事了

某天，我正在愉快的摸鱼，然后我看到测试给我发了条消息，说我们这个系统在UC浏览器中有问题，没办法操作，点了经常没反应（测试用得iPhone14，是一个h5的项目）。我直接懵了，这不是都测了好久了吗，虽然不是在uc上测得，chrome、safari、自带浏览器等，都没这个问题，代码应该是没问题的，uc上为啥会没有反应呢？难道是有什么隐藏的bug，需要一定的操作顺序才能触发？我就去找了测试，让他重新操作一下，看看是啥样的没反应。结果就是，正常进入列表页（首页），正常点某一项，正常进入详情页，然后点左上角返回，没反应。我上手试了下，确实，打开vconsole看了下，也没有报错。在uc上看起来还是必现的，我都麻了，这能是啥引起的啊。

找问题

在其他浏览器上都是好好的，uc上也不报错，完全看不出来代码有啥bug，完全没有头绪啊！那怎么办，刷新看看：遇事不决，先刷新,还不行就清空缓存刷新。刷新了之后，哎，好了！虽然不知道是什么问题，但现在已经好了，就当作遇到了灵异事件，我就去做其他事了。

过了一会，测试来找我了，说又出现了，不止是详情页，进其他页面也返回不了。这就难受住了呀，说明肯定是有问题的，只是还没找到原因。我就只好打开vconsole，一遍一遍的进入详情页点返回；刷新再进；清掉缓存，再进。

然后，我就发现，network中，出现了一个没有见过的请求

根据track、collect这些单词来判断，这应该是uc在跟踪、记录某些操作，requestType还是个ping；我就在想，难道是这个请求的问题？但是请求为啥会导致，我页面跳转产生问题？然后我又看到了intercept(拦截)、pushState(history添加记录)，拦截了pushState?

这个项目确实使用的是history路由，问题也确实出在路由跳转的时候；而且出现问题的时候，路由跳转，浏览器地址栏中的地址是没有变化的，返回就g了(看起来是后退没有反应，实际是前进时G了)。这样看，uc确实拦截了pushState的操作。那它是咋做到的？

原来如此

然后，我想起来，前段时间在掘金上看到了一篇，讲某些第三方cdn投毒的事情，那么uc是不是在我们不知情的情况下，改了我们的代码。然后我切到了vconsole的element，展开head，发现了一个不属于我们项目的script，外链引入了一段js，就挂在head的最顶上。通过阅读，发现它在window的history上加了点料，覆写了forward和pushState(forward和pushState是继承来的方法)

正常的history应该是这样：

复写的类似这样：

当然，有些系统或框架，为了实现某些功能，比如实现触发popstate的效果，也会复写

但uc是纯纯的为了记录你的操作，它这玩意主要还有bug，会导致路由跳转出问题，真是闹麻了

如何做

删掉就好了，只要删掉uc添加的，当我们调用相关方法时，history就会去继承里找

// 判断是否是uc浏览器

if (navigator.userAgent.indexOf('UCBrowser') > -1) {

    if (history.hasOwnProperty('pushState')) {

        delete window.history.forward

        delete window.history.pushState

    }

    // 找到注入的script

    const ucScript = document.querySelector('script[src*="ucbrowser_script"]')

    if (ucScript) {

        document.head.removeChild(ucScript)}

    }

}

吐槽

你说你一个搞浏览器的，就不能在底层去记录用户行为吗，还不容易被发现。主要是你这玩意它有bug呀，这不是更容易被发现吗。（这是23年11月份遇到的问题，当时产品要求在qq/百度/uc这些浏览器上也都测一下才发现的，现在记录一下，希望能帮助到其他同学）

文件上传功能几乎是每个 Web 应用不可或缺的一部分。无论是个人博客中的图片上传，还是企业级应用中的文档管理，文件上传都扮演着至关重要的角色。今天，松哥和大家来聊聊文件上传中的几个高级玩法——秒传、断点续传和分片上传。

一 文件上传的常见场景

在日常开发中，文件上传的场景多种多样。比如，在线教育平台上的视频资源上传，社交平台上的图片分享，以及企业内部的知识文档管理等。这些场景对文件上传的要求也各不相同，有的追求速度，有的注重稳定性，还有的需要考虑文件大小和安全性。因此，针对不同需求，我们有了秒传、断点续传和分片上传等解决方案。

二 秒传、断点上传与分片上传

秒传

秒传，顾名思义，就是几乎瞬间完成文件上传的过程。其实现原理是通过计算文件的哈希值（如 MD5 或 SHA-1），然后将这个唯一的标识符发送给服务器。如果服务器上已经存在相同的文件，则直接返回成功信息，避免了重复上传。这种方式不仅节省了带宽，也大大提高了用户体验。

断点续传

断点续传是指在网络不稳定或者用户主动中断上传后，能够从上次中断的地方继续上传，而不需要重新开始整个过程。这对于大文件上传尤为重要，因为它可以有效防止因网络问题导致的上传失败，同时也能节约用户的流量和时间。

分片上传

分片上传则是将一个大文件分割成多个小块分别上传，最后再由服务器合并成完整的文件。这种做法的好处是可以并行处理多个小文件，提高上传效率；同时，如果某一部分上传失败，只需要重传这一部分，不影响其他部分。

三 秒传实战

后端实现

在 SpringBoot 项目中，我们可以使用 MessageDigest 类来计算文件的 MD5 值，然后检查数据库中是否存在该文件。

@RestController

@RequestMapping("/file")

public class FileController {

    @Autowired

    FileService fileService;



    @PostMapping("/upload1")

    public ResponseEntity<String> secondUpload(@RequestParam(value = "file",required = false) MultipartFile file,@RequestParam(required = false,value = "md5") String md5) {

        try {

            // 检查数据库中是否已存在该文件

            if (fileService.existsByMd5(md5)) {

                return ResponseEntity.ok("文件已存在");

            }

            // 保存文件到服务器

            file.transferTo(new File("/path/to/save/" + file.getOriginalFilename()));

            // 保存文件信息到数据库

            fileService.save(new FileInfo(file.getOriginalFilename(), DigestUtils.md5DigestAsHex(file.getInputStream())));

            return ResponseEntity.ok("上传成功");

        } catch (Exception e) {

            return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("上传失败");

        }

    }

}

前端调用

前端可以通过 JavaScript 的 FileReader API 读取文件内容，通过 spark-md5 计算 MD5 值，然后发送给后端进行校验。

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>秒传</title>

    <script src="spark-md5.js"></script>

</head>

<body>

<input type="file" id="fileInput" />

<button onclick="startUpload()">开始上传</button>

<hr>

<script>

    async function startUpload() {

        const fileInput = document.getElementById('fileInput');

        const file = fileInput.files[0];

        if (!file) {

            alert("请选择文件");

            return;

        }



        const md5 = await calculateMd5(file);

        const formData = new FormData();

        formData.append('md5', md5);



        const response = await fetch('/file/upload1', {

            method: 'POST',

            body: formData

        });



        const result = await response.text();

        if (response.ok) {

            if (result != "文件已存在") {

                // 开始上传文件

            }

        } else {

            console.error("上传失败: " + result);

        }

    }



    function calculateMd5(file) {

        return new Promise((resolve, reject) => {

            const reader = new FileReader();

            reader.onloadend = () => {

                const spark = new SparkMD5.ArrayBuffer();

                spark.append(reader.result);

                resolve(spark.end());

            };

            reader.onerror = () => reject(reader.error);

            reader.readAsArrayBuffer(file);

        });

    }

</script>

</body>

</html>

前端分为两个步骤：

四 分片上传实战

分片上传关键是在前端对文件切片，比如一个 10MB 的文件切为 10 份，每份 1MB。每次上传的时候，需要多一个参数记录当前上传的文件切片的起始位置。

比如一个 10MB 的文件，切为 10 份，每份 1MB，那么：

• 第 0 片，从 0 开始，一共是 1024*1024 个字节。


• 第 1 片，从 1024*1024 开始，一共是 1024*1024 个字节。


• 第 2 片...

把这个搞懂，后面的代码就好理解了。

后端实现

private static final String UPLOAD_DIR = System.getProperty("user.home") + "/uploads/";

/**

 * 上传文件到指定位置

 *

 * @param file 上传的文件

 * @param start 文件开始上传的位置

 * @return ResponseEntity<String> 上传结果

 */

@PostMapping("/upload2")

public ResponseEntity<String> resumeUpload(@RequestParam("file") MultipartFile file, @RequestParam("start") long start,@RequestParam("fileName") String fileName) {

    try {

        File directory = new File(UPLOAD_DIR);

        if (!directory.exists()) {

            directory.mkdirs();

        }

        File targetFile = new File(UPLOAD_DIR + fileName);

        RandomAccessFile randomAccessFile = new RandomAccessFile(targetFile, "rw");

        FileChannel channel = randomAccessFile.getChannel();

        channel.position(start);

        channel.transferFrom(file.getResource().readableChannel(), start, file.getSize());

        channel.close();

        randomAccessFile.close();

        return ResponseEntity.ok("上传成功");

    } catch (Exception e) {

        System.out.println("上传失败: "+e.getMessage());

        return ResponseEntity.status(500).body("上传失败");

    }

}

后端每次处理的时候，需要先设置文件的起始位置。

前端调用

前端需要将文件切分成多个小块，然后依次上传。

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>分片示例</title>

</head>

<body>

    <input type="file" id="fileInput" />

    <button onclick="startUpload()">开始上传</button>



    <script>

        async function startUpload() {

            const fileInput = document.getElementById('fileInput');

            const file = fileInput.files[0];

            if (!file) {

                alert("请选择文件");

                return;

            }



            const filename = file.name;

            let start = 0;



            uploadFile(file, start);

        }



        async function uploadFile(file, start) {

            const chunkSize = 1024 * 1024; // 每个分片1MB

            const total = Math.ceil(file.size / chunkSize);



            for (let i = 0; i < total; i++) {

                const chunkStart = start + i * chunkSize;

                const chunkEnd = Math.min(chunkStart + chunkSize, file.size);

                const chunk = file.slice(chunkStart, chunkEnd);



                const formData = new FormData();

                formData.append('file', chunk);

                formData.append('start', chunkStart);

                formData.append('fileName', file.name);



                const response = await fetch('/file/upload2', {

                    method: 'POST',

                    body: formData

                });



                const result = await response.text();

                if (response.ok) {

                    console.log(`分片 ${i + 1}/${total} 上传成功`);

                } else {

                    console.error(`分片 ${i + 1}/${total} 上传失败: ${result}`);

                    break;

                }

            }

        }

    </script>

</body>

</html>

五 断点续传实战

断点续传的技术原理类似于分片上传。

当文件已经上传了一部分之后，断了需要重新开始上传。

那么我们的思路是这样的：

后端案例

先来看后端检查的接口，如下：

@GetMapping("/check")

public ResponseEntity<Long> checkFile(@RequestParam("filename") String filename) {

    File file = new File(UPLOAD_DIR + filename);

    if (file.exists()) {

        return ResponseEntity.ok(file.length());

    } else {

        return ResponseEntity.ok(0L);

    }

}

如果文件存在，则返回已经存在的文件大小。

如果文件不存在，则返回 0，表示前端从头开始上传该文件。

前端调用

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>断点续传示例</title>

</head>

<body>

<input type="file" id="fileInput"/>

<button onclick="startUpload()">开始上传</button>



<script>

    async function startUpload() {

        const fileInput = document.getElementById('fileInput');

        const file = fileInput.files[0];

        if (!file) {

            alert("请选择文件");

            return;

        }



        const filename = file.name;

        let start = await checkFile(filename);



        uploadFile(file, start);

    }



    async function checkFile(filename) {

        const response = await fetch(`/file/check?filename=${filename}`);

        const start = await response.json();

        return start;

    }



    async function uploadFile(file, start) {

        const chunkSize = 1024 * 1024; // 每个分片1MB

        const total = Math.ceil((file.size - start) / chunkSize);



        for (let i = 0; i < total; i++) {

            const chunkStart = start + i * chunkSize;

            const chunkEnd = Math.min(chunkStart + chunkSize, file.size);

            const chunk = file.slice(chunkStart, chunkEnd);



            const formData = new FormData();

            formData.append('file', chunk);

            formData.append('start', chunkStart);

            formData.append('fileName', file.name);



            const response = await fetch('/file/upload2', {

                method: 'POST',

                body: formData

            });



            const result = await response.text();

            if (response.ok) {

                console.log(`分片 ${i + 1}/${total} 上传成功`);

            } else {

                console.error(`分片 ${i + 1}/${total} 上传失败: ${result}`);

                break;

            }

        }

    }

</script>

</body>

</html>

这个案例实际上是一个断点续传+分片上传的案例，相关知识点并不难，小伙伴们可以自行体会下。

六 总结

好了，以上就是关于文件上传中秒传、断点续传和分片上传的实战分享。通过这些技术的应用，我们可以极大地提升文件上传的效率和稳定性，改善用户体验。希望各位小伙伴在自己的项目中也能灵活运用这些技巧，解决实际问题。

本文完整案例：github.com/lenve/sprin…

本文首发于公众号：托尼学长，立个写 1024 篇原创技术面试文章的flag，欢迎过来视察监督~

最近有好几个同学跟我说，他在技术面试过程中被问到这个问题了，让我找时间系统地讲解一下。

其实从某种意义上来说，这并不是一个严谨的面试题，接下来 show me the SQL，我们一起来看一下。

如下图所示，一张有 3000多万行记录的 user 表，执行全表 count 操作需要 14.8 秒的时间。

接下来我们稍作调整再试一次，神奇的一幕出现了，执行全表 count 操作竟然连 1 毫秒的时间都用不上。

这是为什么呢？

其实原因很简单，第一次执行全表 count 操作的时候，我用的是 MySQL InnoDB 存储引擎，而第二次则是用的 MySQL MyISAM 存储引擎。

这两者的差别在于，前者在执行 count(*)  操作的时候，需要将表中每行数据读取出来进行累加计数，而后者已经将表的总行数存储下来了，只需要直接返回即可。

当然，InnoDB 存储引擎对 count(*)  操作也进行了一些优化，如果该表创建了二级索引，其会通过全索引扫描的方式来代替全表扫描进行累加计数，

毕竟，二级索引值只存储了索引列和主键列两个字段，遍历计数肯定比存储所有字段的数据表的 IO 次数少很多，也就意味着其执行效率更高。

而且，MySQL 的优化器会选择最小的那个二级索引的索引文件进行遍历计数。

所以，这个技术面试题严谨的问法应该是 —— MySQL InnoDB 存储引擎单表过亿数据，如何优化 count(*) 全表的操作？

下面我们就来列举几个常见的技术解决方案，如下图所示：

（1）Redis 累加计数

这是一种最主流且简单直接的实现方式。

由于我们基本上不会对数据表执行 delete 操作，所以当有新的数据被写入表的时候，通过 Redis 的 incr 或 incrby 命令进行累加计数，并在用户查询汇总数据的时候直接返回结果即可。

如下图所示：

该实现方式在查询性能和数据准确性上两者兼得，Redis 需要同时负责累加计数和返回查询结果操作，缺点在于会引入缓存和数据库间的数据一致性的问题。

（2）MySQL 累加计数表 + 事务

这种实现方式跟“Redis 累加计数”大同小异，唯一的区别就是将计数的存储介质从 Redis 换成了 MySQL。

如下图所示：

但这么一换，就可以将写入表操作和累加计数操作放在一个数据库事务中，也就解决了缓存和数据库间的数据一致性的问题。

该实现方式在查询性能和数据准确性上两者兼得，但不如“Redis 累加计数”方式的性能高，在高并发场景下数据库会成为性能瓶颈。

（3）MySQL 累加计数表 + 触发器

这种实现方式跟“MySQL 累加计数表 + 事务”的表结构是一样的，如下图所示：

****

唯一的区别就是增加一个触发器，不用在工程代码中通过事务进行实现了。

CREATE TRIGGER `user_count_trigger` AFTER INSERT ON `user` FOR EACH ROW BEGIN    UPDATE user_count SET count = count + 1 WHERE id = NEW.id;END

该实现方式在查询性能和数据准确性上两者兼得，与“MySQL 累加计数表 + 事务”方式相比，最大的好处就是不用污染工程代码了。

（4）MySQL 增加并行线程

在 MySQL 8.014 版本中，总算增加了并行查询的新特性，其通过参数 innodb_parallel_read_threads 进行设定，默认值为 4。

下面我们做个实验，将这个参数值调得大一些：

set local innodb_parallel_read_threads = 16;

然后，我们再来执行一次上文中那个 3000 多万行记录 user 表的全表 count 操作，结果如下所示：

参数调整后，执行全表 count 操作的时间由之前的 14.8 秒，降低至现在的 6.1 秒，是可以看到效果的。

接下来，我们继续将参数值调整得大一些，看看是否还有优化空间：

set local innodb_parallel_read_threads = 32;

然后，我们再来执行一次上文中那个 3000 多万行记录 user 表的全表 count 操作，结果如下所示：

参数调整后，执行全表 count 操作的时间竟然变长了，从原来的 6.1 秒变成了 6.8 秒，看样子优化空间已经达到上限了，再多增加执行线程数量只会适得其反。

该实现方式一样可以保证数据准确性，在查询性能上有所提升但相对有限，其最大优势是只需要调整一个数据库参数，在工程代码上不会有任何改动。

不过，如果数据库此时的负载和 IOPS 已经很高了，那开启并行线程或者将并行线程数量调大，会加速消耗数据库资源。

（5）MySQL 增加二级索引

还记得我们在上文中说的内容吗？

InnoDB 存储引擎对 count()  操作也进行了一些优化，如果该表创建了二级索引，其会通过全索引扫描的方式来代替全表扫描进行累加计数，*

毕竟，二级索引值只存储了索引列和主键列两个字段，遍历计数肯定比存储所有字段的数据表的IO次数少很多，也就意味着执行效率更高。

而且，MySQL 的优化器会选择最小的那个二级索引的索引文件进行遍历计数。

为了验证这个说法，我们给 user 表中最小的 sex 字段加一个二级索引，然后通过 EXPLAIN 命令看一下 SQL 语句的执行计划：

果然，这个 SQL 语句的执行计划会使用新建的 sex 索引，接下来我们执行一次看看时长：

果不其然，执行全表 count 操作走了 sex 二级索引后，SQL 执行时间由之前的 14.8 秒降低至现在的 10.6 秒，还是可以看到效果的。

btw：大家可能会觉得效果并不明显，这是因为我们用来测试的 user 表中算上主键 ID 只有七个字段，而且没有一个大字段。

反之，user 表中的字段数量越多，且包含的大字段越多，其优化效果就会越明显。

该实现方式一样可以保证数据准确性，在查询性能上有所提升但相对有限，其最大优势是只需要创建一个二级索引，在工程代码上不会有任何改动。

（6）SHOW TABLE STATUS

如下图所示，通过 SHOW TABLE STATUS 命令也可以查出来全表的行数：

我们常用于查看执行计划的 EXPLAIN 命令也能实现：

只不过，通过这两个命令得出来的表记录数是估算出来的，都不太准确。那到底有多不准确呢，我们来计算一下。

公式为：33554432 / 33216098 = 1.01

就这个 case 而言，误差率大概在百分之一左右。

该实现方式一样可以保证查询性能，无论表中有多大量级的数据都能毫秒级返回结果，且在工程代码方面不会有任何改动，但数据准确性上相差较多，只能用作大概估算。

大家好，我是苏三，又跟大家见面了。

前言

在电商、外卖、票务等系统中，订单超时未支付自动取消是一个常见的需求。

这个功能乍一看很简单，甚至很多初学者会觉得："不就是加个定时器么？" 但真到了实际工作中，细节的复杂程度往往会超乎预期。

这里我们从基础到高级，逐步分析各种实现方案，最后分享一些在生产中常见的优化技巧，希望对你会有所帮助。

苏三最近开源了一个基于 SpringBoot+Vue+uniapp 的商城项目，欢迎访问和star。

1. 使用延时队列（DelayQueue）

适用场景： 订单数量较少，系统并发量不高。

延时队列是Java并发包（java.util.concurrent）中的一个数据结构，专门用于处理延时任务。

订单在创建时，将其放入延时队列，并设置超时时间。

延时时间到了以后，队列会触发消费逻辑，执行取消操作。

示例代码：

import java.util.concurrent.*;



public class OrderCancelService {

    private static final DelayQueue delayQueue = new DelayQueue<>();



    public static void main(String[] args) throws InterruptedException {

        // 启动消费者线程

        new Thread(() -> {

            while (true) {

                try {

                    OrderTask task = delayQueue.take(); // 获取到期任务

                    System.out.println("取消订单：" + task.getOrderId());

                } catch (InterruptedException e) {

                    Thread.currentThread().interrupt();

                }

            }

        }).start();



        // 模拟订单创建

        for (int i = 1; i <= 5; i++) {

            delayQueue.put(new OrderTask(i, System.currentTimeMillis() + 5000)); // 5秒后取消

            System.out.println("订单" + i + "已创建");

        }

    }



    static class OrderTask implements Delayed {

        private final long expireTime;

        private final int orderId;



        public OrderTask(int orderId, long expireTime) {

            this.orderId = orderId;

            this.expireTime = expireTime;

        }



        public int getOrderId() {

            return orderId;

        }



        @Override

        public long getDelay(TimeUnit unit) {

            return unit.convert(expireTime - System.currentTimeMillis(), TimeUnit.MILLISECONDS);

        }



        @Override

        public int compareTo(Delayed o) {

            return Long.compare(this.expireTime, ((OrderTask) o).expireTime);

        }

    }

}

优点：

• 实现简单，逻辑清晰。

缺点：

• 依赖内存，系统重启会丢失任务。
• 随着订单量增加，内存占用会显著上升。

2. 基于数据库轮询

适用场景： 订单数量较多，但系统对实时性要求不高。

轮询是最容易想到的方案：定期扫描数据库，将超时的订单状态更新为“已取消”。

示例代码：

public void cancelExpiredOrders() {

    String sql = "UPDATE orders SET status = 'CANCELLED' WHERE status = 'PENDING' AND create_time < ?";

    try (Connection conn = dataSource.getConnection();

         PreparedStatement ps = conn.prepareStatement(sql)) {

        ps.setTimestamp(1, new Timestamp(System.currentTimeMillis() - 30 * 60 * 1000)); // 30分钟未支付取消

        int affectedRows = ps.executeUpdate();

        System.out.println("取消订单数量：" + affectedRows);

    } catch (SQLException e) {

        e.printStackTrace();

    }

}

优点：

• 数据可靠性强，不依赖内存。
• 实现成本低，无需引入第三方组件。

缺点：

• 频繁扫描数据库，会带来较大的性能开销。
• 实时性较差（通常定时任务间隔为分钟级别）。

优化建议：

• 为相关字段加索引，避免全表扫描。
• 结合分表分库策略，减少单表压力。

3. 基于Redis队列

适用场景： 适合对实时性有要求的中小型项目。

Redis 的 List 或 Sorted Set 数据结构非常适合用作延时任务队列。

我们可以把订单的超时时间作为 Score，订单 ID 作为 Value 存到 Redis 的 ZSet 中，定时去取出到期的订单进行取消。

例子：

public void addOrderToQueue(String orderId, long expireTime) {

    jedis.zadd("order_delay_queue", expireTime, orderId);

}



public void processExpiredOrders() {

    long now = System.currentTimeMillis();

    Set<String> expiredOrders = jedis.zrangeByScore("order_delay_queue", 0, now);

    for (String orderId : expiredOrders) {

        System.out.println("取消订单：" + orderId);

        jedis.zrem("order_delay_queue", orderId); // 删除已处理的订单

    }

}

优点：

1. 实时性高。
2. Redis 的性能优秀，延迟小。

缺点：

1. Redis 容量有限，适合中小规模任务。
2. 需要额外处理 Redis 宕机或数据丢失的问题。

4. Redis Key 过期回调

适用场景： 对超时事件实时性要求高，并且希望依赖 Redis 本身的特性实现简单的任务调度。

Redis 提供了 Key 的过期功能，结合 keyevent 事件通知机制，可以实现订单的自动取消逻辑。

当订单设置超时时间后，Redis 会在 Key 过期时发送通知，我们只需要订阅这个事件并进行相应的处理。

例子：

1. 设置订单的过期时间：

public void setOrderWithExpiration(String orderId, long expireSeconds) {

    jedis.setex("order:" + orderId, expireSeconds, "PENDING");

}

2. 订阅 Redis 的过期事件：

public void subscribeToExpirationEvents() {

    Jedis jedis = new Jedis("localhost");

    jedis.psubscribe(new JedisPubSub() {

        @Override

        public void onPMessage(String pattern, String channel, String message) {

            if (channel.equals("__keyevent@0__:expired")) {

                System.out.println("接收到过期事件，取消订单：" + message);

                // 执行取消订单的业务逻辑

            }

        }

    }, "__keyevent@0__:expired"); // 订阅过期事件

}

优点：

1. 实现简单，直接利用 Redis 的过期机制。
2. 实时性高，过期事件触发后立即响应。

缺点：

1. 依赖 Redis 的事件通知功能，需要开启 notify-keyspace-events 配置。
2. 如果 Redis 中大量使用过期 Key，可能导致性能问题。

注意事项： 要使用 Key 过期事件，需要确保 Redis 配置文件中 notify-keyspace-events 的值包含 Ex。比如：

notify-keyspace-events Ex

最近就业形势比较困难，为了感谢各位小伙伴对苏三一直以来的支持，我特地创建了一些工作内推群， 看看能不能帮助到大家。

你可以在群里发布招聘信息，也可以内推工作，也可以在群里投递简历找工作，也可以在群里交流面试或者工作的话题。

添加苏三的私人微信：su_san_java，备注：掘金+所在城市，即可加入。

5. 基于消息队列（如RabbitMQ）

适用场景： 高并发系统，实时性要求高。

订单创建时，将订单消息发送到延迟队列（如RabbitMQ 的 x-delayed-message 插件）。

延迟时间到了以后，消息会重新投递到消费者，消费者执行取消操作。

示例代码（以RabbitMQ为例）：

public void sendOrderToDelayQueue(String orderId, long delay) {

    Map<String, Object> args = new HashMap<>();

    args.put("x-delayed-type", "direct");

    ConnectionFactory factory = new ConnectionFactory();

    try (Connection connection = factory.newConnection();

         Channel channel = connection.createChannel()) {

        channel.exchangeDeclare("delayed_exchange", "x-delayed-message", true, false, args);

        channel.queueDeclare("delay_queue", true, false, false, null);

        channel.queueBind("delay_queue", "delayed_exchange", "order.cancel");



        AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()

                .headers(Map.of("x-delay", delay)) // 延迟时间

                .build();

        channel.basicPublish("delayed_exchange", "order.cancel", props, orderId.getBytes());

    } catch (Exception e) {

        e.printStackTrace();

    }

}

优点：

1. 消息队列支持分布式，高并发下表现优秀。
2. 数据可靠性高，不容易丢消息。

缺点：

1. 引入消息队列增加了系统复杂性。
2. 需要处理队列堆积的问题。

6. 使用定时任务框架

适用场景： 订单取消操作复杂，需要分布式支持。

定时任务框架，比如：Quartz、Elastic-Job，能够高效地管理任务调度，适合处理批量任务。

比如 Quartz 可以通过配置 Cron 表达式，定时执行订单取消逻辑。

示例代码：

@Scheduled(cron = "0 */5 * * * ?")

public void scanAndCancelOrders() {

    System.out.println("开始扫描并取消过期订单");

    // 这里调用数据库更新逻辑

}

优点：

1. 成熟的调度框架支持复杂任务调度。
2. 灵活性高，支持分布式扩展。

缺点：

1. 对实时性支持有限。
2. 框架本身较复杂。

7. 基于触发式事件流处理

适用场景： 需要处理实时性较高的订单取消，同时结合复杂业务逻辑，例如根据用户行为动态调整超时时间。

可以借助事件流处理框架（如 Apache Flink 或 Spark Streaming），实时地处理订单状态，并触发超时事件。

每个订单生成后，可以作为事件流的一部分，订单未支付时通过流计算触发超时取消逻辑。

示例代码（以 Apache Flink 为例）：

DataStream orderStream = env.fromCollection(orderEvents);



orderStream

    .keyBy(OrderEvent::getOrderId)

    .process(new KeyedProcessFunction() {

        @Override

        public void processElement(OrderEvent event, Context ctx, Collector out) throws Exception {

            // 注册一个定时器

            ctx.timerService().registerProcessingTimeTimer(event.getTimestamp() + 30000); // 30秒超时

        }



        @Override

        public void onTimer(long timestamp, OnTimerContext ctx, Collector out) throws Exception {

            // 定时器触发，执行订单取消逻辑

            System.out.println("订单超时取消，订单ID：" + ctx.getCurrentKey());

        }

    });

优点：

1. 实时性高，支持复杂事件处理逻辑。
2. 适合动态调整超时时间，满足灵活的业务需求。

缺点：

1. 引入了流计算框架，系统复杂度增加。
2. 对运维要求较高。

总结

每种方案都有自己的适用场景，大家在选择的时候，记得结合业务需求、订单量、并发量来综合考虑。

如果你的项目规模较小，可以直接用延时队列或 Redis；而在大型高并发系统中，消息队列和事件流处理往往是首选。

当然，代码实现只是第一步，更重要的是在实际部署和运行中进行性能调优，保证系统的稳定性。

作者：苏三说技术
来源：juejin.cn/post/7451018774743269391

这段时间面了几家公司，也跟不同的面试官切磋了一些面试题，有的没啥难度，有的则是问到了我的知识盲区，没办法，Android能问的东西太多了，要全覆盖到太难了，既然没法全覆盖，那么只好亡羊补牢，将这些没答上来的题目做下记录，让自己如果下次遇到了可以答上来

TCP与UDP有哪些差异

这道题回答的不全，仅仅只是将两个协议的概念说了一下，但是真正的差异却没有真正答上来，后来查询了一下资料，两者的差异如下

• TCP是传输控制协议，是面向连接的协议，发送数据前需要建立连接，TCP传输的数据不会丢失，不会重复，会按照顺序到达


• 与TCP相对的，UDP是无连接的协议，发送数据前不需要建立连接，数据没有可靠性


• TCP的通信类似于打电话，需要确认身份后才可以通话，而UDP更像是广播，不关心对方是不是接收，只需要播报出去即可


• TCP支持点对点通信，而UDP支持一对一，一对多，多对一，多对多


• TCP传输的是字节流，而UDP传输的是报文


• TCP首部开销为20个字节，而UDP首部开销是8个字节


• UDP主机不需要维持复杂的连接状态表

TCP的三次握手

这道题以及下面那道虽然说上来了，但是也没有说的很对，仅仅只是说了下每次握手或者挥手的目的，中间的过程没有说出来，以下是三次握手以及四次挥手的详细过程

• 第一次握手：客户端将SYN置为1，随机生成一个初始序列号seq发送给服务端，客户端进入SYN_SENT状态


• 第二次握手：服务端收到客户端的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK置1，产生一个ack=seq+1，并随机产生一个自己的初始序列号，发送给客户端，服务端进入SYN_RCVD状态


• 第三次握手：客户端检查ack是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个ack=服务器的seq+1，发送给服务器；进入ESTABLISHED状态；服务器检查ACK为1和ack为序列号+1之后，也进入ESTABLISHED状态；完成三次握手，连接建立

TCP的四次挥手

• 第一次挥手：客户端将FIN设置为1，发送一个序列号seq给服务端，客户端进入FIN_WAIT_1状态


• 第二次挥手：服务端收到FIN之后，发送一个ACK为1，ack为收到的序列号加一，服务端进入CLOSE_WAIT状态，这个时候客户端已经不会再向服务端发送数据了


• 第三次挥手：服务端将FIN置1，发送一个序列号给客户端，服务端进入LAST_ACK状态


• 第四次挥手：客户端收到服务器的FIN后，进入TIME_WAIT状态，接着将ACK置1，发送一个ack=序列号+1给服务器，服务器收到后，确认ack后，变为CLOSED状态，不再向客户端发送数据。客户端等待2* MSL（报文段最长寿命）时间后，也进入CLOSED状态。完成四次挥手

从浏览器输入地址到最终显示页面的整个过程

这个真的知识盲区了，谁会平时没事在用浏览器的时候去思考这个问题呢，结果一查居然还是某大厂的面试题，算了也了解下吧

为什么Zygote进程使用socket通信而不是binder

应用层选手遇到偏底层问题就头疼了，但是这个问题还是要知道的，毕竟跟我们app的启动流程相关

使用Binder的好处有哪些

上面那个问题问好了紧接着就是这道题，我嗯嗯啊啊的零碎说了几个，肯定也是不过关的，回头查了下资料，使用Binder的优势如下

• 从效率上来讲，Binder比较高效，相比较于其他几种进程的通信方式(管道，消息队列，Socket,共享内存),Binder只需要拷贝一次内存就好了，而除了共享内存，其余都都要拷贝两次内存，共享内存虽然不需要拷贝，但是实现方式复杂，所以综合考虑Binder占优势


• 使用的是更加便于理解，更简单的面向对象的IPC通信方式


• Binder既支持同步调用，也支持异步调用


• Binder使用UID和PID来验证请求的来源，这样可以确保每个Binder事务可以精确到发起者，为进程间的通信提供了保障


• Binder是基于c/s架构，架构清晰明确，Server端与Client端相对独立


• Binder有一套易于使用的API供进程间通信，将复杂的内部实现隐藏起来

如果一个线程连续调用两次start,会怎样？

会怎样？谁知道呀，正常人谁会没事去调用两次start呢？但是这个还真有人问了，我只能说没遇到过，后来回去自己试了下才知道

如上述代码所示，有一个线程，然后连续调用了两次start方法，当我们运行一下这段代码后，得到的结果如下

可以发现线程有正常运行，但同时也因为多调了一次start而抛出了异常，这个异常在start方法里面就能看到

有一个状态为started，正常第一次启动线程时候，started为false，所以是不会抛出异常的，started为true的地方是在下面这个位置

调用了native方法nativeCreated后，started状态位才变成true,这个时候如果再去调用start方法，那么必然会抛出异常

如何处理协程并发的数据安全

之前遇到过这么个问题，并发处理的协程之间是否可以保证数据安全，这个由于之前有实验过，所以想都没想就说可以保证数据安全，但面试官只是呵呵了一下，我捉摸着难道不对吗，后来回去试了一下才发现，不一定就能保证数据安全，看下面这段代码

这段代码里面在runBlocking中创建了1000个协程，每一个协程都对变量count做自增操作，最后把结果打印出来，我们预期的是打印出的结果就是1000，实际结果如下

看到的确就是1000，没啥毛病，多试几次也是一样的，但是如果换一种写法试试看呢

原本都是runBlocking里面的子协程，现在将这些协程变成非runBlocking的子协程，结果是不是还是1000呢，看下结果

明显不是了，所以并发处理的协程，并不能保证数据安全，那么如何可以让数据安全呢，有以下几个办法

原子类

这个好理解，同处理线程安全差不多

channel

receive函数只有等到阻塞队列里面有数据的时候才会执行，没有数据的时候会一直等待，所以这就能保证这些协程可以并发执行，不过要注意的是这里的Channel一定要设置队列大小，不然程序会一直阻塞，receive一直在等待队列里面有数据

mutex

使用互斥锁的方式，withLock函数内部执行了获取锁跟释放锁逻辑，将变量count保护起来，实现数据安全，除此之外，还可以使用lock与unLock函数来实现，代码如下

总结

总的来讲自己在系统层面，偏底层的那些问题上，还是掌握的不多，这个也跟自己多年徘徊在应用层开发有关，底层知识用到的不多，自然也就忽略了，但是如果面试的话，就算是面的应用层，也是需要知道一些底层方面的知识，不然面试官随便问几个，你不会，别人会，岗位不就被别人拿走了吗

妙用MyBatisPlus，12个实战技巧解锁新知识

前言

说起数据库ORM，我忽然想起了小时候外婆做的那锅鲜美的羊肉汤。平常人家做的羊肉汤无非是几块肉、几片姜，味道寡淡得很，喝了和喝白开水差不多。但外婆的汤，那是另一回事儿 —— 一锅汤，香气四溢，肉质软烂，汤头浓郁得能让人连碗都想舔干净。

写代码何尝不是如此？以前写Mybatis，就像是在煮一锅没有灵魂的羊肉汤：原料都在，但就是不够鲜美。代码繁琐，每写一个查询都像是在不断调味，却怎么也调不出那种令人惊艳的味道。直到遇见MyBatisPlus，一切都变了 —— 这就像是从普通的羊肉汤，突然升级到了外婆秘制的顶级羊肉汤！

MyBatisPlus就像一位精通厨艺的帮厨，它帮你处理了所有繁琐的准备工作。想要一个复杂的查询？不用自己一刀一刀地切肉、一勺一勺地调味，框架已经帮你准备好了。你只需要轻轻地指挥，代码就像汤汁一样顺滑流畅，性能更是鲜美可口。

在接下来的篇幅里，我将与你分享12个MyBatisPlus优化的"秘制配方"。相信看完这些，你写的每一行代码，都会像外婆的羊肉汤一样，让人回味无穷。

耐心看完，你一定有所收获。

避免使用isNull判断

// ❌ 不推荐

LambdaQueryWrapper<User> wrapper1 = new LambdaQueryWrapper<>();

wrapper1.isNull(User::getStatus);



// ✅ 推荐：使用具体的默认值

LambdaQueryWrapper<User> wrapper2 = new LambdaQueryWrapper<>();

wrapper2.eq(User::getStatus, UserStatusEnum.INACTIVE.getCode());

• 📝 原因:
  
  
  
  • 使用具体的默认值可以提高代码的可读性和维护性
  
  
  • NULL值会使索引失效，导致MySQL无法使用索引进行查询优化
  
  
  • NULL值的比较需要特殊的处理逻辑，增加了CPU开销
  
  
  • NULL值会占用额外的存储空间，影响数据压缩效率
  
  
  
  

明确Select字段

// ❌ 不推荐

// 默认select 所有字段

List<User> users1 = userMapper.selectList(null);  



// ✅ 推荐：指定需要的字段

LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();

wrapper.select(User::getId, User::getName, User::getAge);

List<User> users2 = userMapper.selectList(wrapper);

• 📝 原因:
  
  
  
  • 避免大量无用字段的网络传输开销
  
  
  • 可以利用索引覆盖，避免回表查询
  
  
  • 减少数据库解析和序列化的负担
  
  
  • 降低内存占用，特别是在大量数据查询时
  
  
  
  

批量操作方法替代循环

// ❌ 不推荐

for (User user : userList) {

    userMapper.insert(user);

}



// ✅ 推荐

userService.saveBatch(userList, 100);  // 每批次处理100条数据



// ✅ 更优写法：自定义批次大小

userService.saveBatch(userList, BatchConstants.BATCH_SIZE);

• 📝 原因:
  
  
  
  • 减少数据库连接的创建和销毁开销
  
  
  • 批量操作可以在一个事务中完成，提高数据一致性
  
  
  • 数据库可以优化批量操作的执行计划
  
  
  • 显著减少网络往返次数，提升吞吐量
  
  
  
  

Exists方法子查询

// ❌ 不推荐

wrapper.inSql("user_id", "select user_id from order where amount > 1000");



// ✅ 推荐

wrapper.exists("select 1 from order where order.user_id = user.id and amount > 1000");



// ✅ 更优写法：使用LambdaQueryWrapper

wrapper.exists(orderService.lambdaQuery()

    .gt(Order::getAmount, 1000)

    .apply("order.user_id = user.id"));

• 📝 原因:
  
  
  
  • EXISTS是基于索引的快速查询，可以使用到索引
  
  
  • EXISTS在找到第一个匹配项就会停止扫描
  
  
  • IN子查询需要加载所有数据到内存后再比较
  
  
  • 当外表数据量大时，EXISTS的性能优势更明显
  
  
  
  

使用orderBy代替last

// ❌ 不推荐：SQL注入风险

wrapper.last("ORDER BY " + sortField + " " + sortOrder);



// ❌ 不推荐：直接字符串拼接

wrapper.last("ORDER BY FIELD(status, 'active', 'pending', 'inactive')");



// ✅ 推荐：使用 Lambda 安全排序

wrapper.orderBy(true, true, User::getStatus);



// ✅ 推荐：多字段排序示例

wrapper.orderByAsc(User::getStatus)

       .orderByDesc(User::getCreateTime);

• 📝 原因:
  
  
  
  • 直接拼接SQL容易导致SQL注入攻击
  
  
  • 动态SQL可能破坏SQL语义完整性
  
  
  • 影响SQL语句的可维护性和可读性
  
  
  • last会绕过MyBatis-Plus的安全检查机制
  
  
  
  

使用LambdaQuery确保类型安全

// ❌ 不推荐：字段变更后可能遗漏

QueryWrapper<User> wrapper1 = new QueryWrapper<>();

wrapper1.eq("name", "张三").gt("age", 18);



// ✅ 推荐

LambdaQueryWrapper<User> wrapper2 = new LambdaQueryWrapper<>();

wrapper2.eq(User::getName, "张三")

        .gt(User::getAge, 18);



// ✅ 更优写法：使用链式调用

userService.lambdaQuery()

    .eq(User::getName, "张三")

    .gt(User::getAge, 18)

    .list();

• 📝 原因:
  
  
  
  • 编译期类型检查，避免字段名拼写错误
  
  
  • IDE可以提供更好的代码补全支持
  
  
  • 重构时能自动更新字段引用
  
  
  • 提高代码的可维护性和可读性
  
  
  
  

用between代替ge和le

// ❌ 不推荐

wrapper.ge(User::getAge, 18)

       .le(User::getAge, 30);



// ✅ 推荐

wrapper.between(User::getAge, 18, 30);



// ✅ 更优写法：条件动态判断

wrapper.between(ageStart != null && ageEnd != null,

               User::getAge, ageStart, ageEnd);

• 📝 原因:
  
  
  
  • 生成的SQL更简洁，减少解析开销
  
  
  • 数据库优化器可以更好地处理范围查询
  
  
  • 代码更易读，语义更清晰
  
  
  • 减少重复编写字段名的机会
  
  
  
  

排序字段注意索引

// ❌ 不推荐

// 假设lastLoginTime无索引

wrapper.orderByDesc(User::getLastLoginTime);  



// ✅ 推荐

// 主键排序

wrapper.orderByDesc(User::getId);  



// ✅ 更优写法：组合索引排序

wrapper.orderByDesc(User::getStatus)  // status建立了索引

       .orderByDesc(User::getId);     // 主键排序

• 📝 原因:
  
  
  
  • 索引天然具有排序特性，可以避免额外的排序操作
  
  
  • 无索引排序会导致文件排序，极大影响性能
  
  
  • 当数据量大时，内存排序可能导致溢出
  
  
  • 利用索引排序可以实现流式读取
  
  
  
  

分页参数设置

// ❌ 不推荐

wrapper.last("limit 1000");  // 一次查询过多数据



// ✅ 推荐

Page<User> page = new Page<>(1, 10);

userService.page(page, wrapper);



// ✅ 更优写法：带条件的分页查询

Page<User> result = userService.lambdaQuery()

    .eq(User::getStatus, "active")

    .page(new Page<>(1, 10));

• 📝 原因:
  
  
  
  • 控制单次查询的数据量，避免内存溢出
  
  
  • 提高首屏加载速度，优化用户体验
  
  
  • 减少网络传输压力
  
  
  • 数据库资源利用更合理
  
  
  
  

条件构造处理Null值