- 博客(17)
- 收藏
- 关注
RSS订阅原创 Day17｜MySQL大数据大表治理的一些经验
【MySQL大表治理实战经验分享】作者结合踩坑经历，总结了千万级大表治理方案：1.按日期分区管理，但需注意分区限制；2.分库分表提升性能，但增改成本高；3.历史表归档平衡新旧数据访问。同时强调索引优化要避免"多多益善"，需分析业务场景。建议控制单表行数、读写分离、冷热数据分离等技巧，指出治理本质是在性能、成本与风险间找平衡点，需根据业务特点选择合适方案。
2025-08-28 11:00:26
1012
原创 Day16｜项目实战：Kafka从部署到Java调用的那些事儿
本文分享了Kafka的实践经验和部署指南。首先介绍了Kafka作为高吞吐分布式消息中间件的适用场景，如系统解耦、异步任务处理等。接着详细说明了在CentOS下使用Docker Compose部署Kafka的步骤，包括Zookeeper配置和关键参数设置。然后演示了Spring Boot项目中集成Kafka的方法，涵盖依赖引入、配置示例以及生产者和消费者的基础代码实现。最后总结了实践中需要注意的常见问题，如IP配置、版本兼容性等，并提供了相关资源的Git仓库地址。全文内容实用，适合需要快速上手Kafka的开发
2025-08-21 15:53:36
358
原创 第十五天-职场一年多来的反思与焦虑
职场心路：从较真到平和的技术人成长 15天来梳理工作与心路历程，技术人逐渐领悟职场之道。高并发优化中提升技能，却也经历职场磨合的阵痛：从测试甩锅的委屈到任务分配不公的愤懑，从股市挫折到CRUD重复工作的迷茫。渐渐明白，与其较真不如平和以对，把精力放在可控的成长上。虽然内心仍有矛盾与不甘，但已学会在技术精进与生活平衡间寻找支点。这段成长启示我们：职场没有绝对公平，成熟在于接纳不完美，在持续进步中找到属于自己的节奏与快乐。
2025-08-18 15:36:17
314
原创 第十四天：高并发场景下的系统故障复盘与性能调优
本文复盘了一场高并发系统调优的完整过程。团队经历了三次压力测试：首次发现前端卡顿问题，优化后第二次暴露后端瓶颈，最终通过链路优化、硬件升级和参数调整（网关连接数从500提至8000，feign-client从500提至3000）解决了微服务间连接数不足导致的"卡脖子"问题。关键收获包括：高并发下参数调优比硬件升级更重要；微服务拆分需权衡性能与复杂度；全链路分析才能发现隐藏瓶颈。这次经历不仅提升了系统性能，也增强了团队协作能力，为后续大规模活动积累了宝贵经验。
2025-08-14 16:06:24
1012
原创 Day13｜高并发极限压测与全链路瓶颈排查：凌晨3点的“打流”实录
摘要：在高并发压力测试中，系统在80并发量时崩溃，远低于预期的160。尽管已对Nginx、RDS和Redis进行优化，但瓶颈依然存在。排查发现Redis连接数配置过低（仅6个），网关最大连接数不足（500），鉴权服务成新瓶颈。通过横向扩展微服务、精简请求、异步化处理和链路压测，最终将并发能力提升至130左右。经验表明，高并发是全链路协同问题，需细致调优配置参数，避免微服务架构中的潜在短板。性能提升需持续排查和优化每一环节。
2025-08-11 18:21:36
433
原创 Day12｜高并发下的真实考验：微服务、IO链路与我的“妥协之路”
《高并发场景下的系统优化实战》 本文记录了直播答题领券功能在高并发场景下暴露的系统性问题及解决方案。主要问题包括：1)前后端防抖缺失导致重复提交；2)券生成链路过长引发数据不一致；3)系统资源耗尽造成服务瘫痪。通过技术复盘发现：微服务拆分不当导致过多网络IO，分布式事务与性能存在矛盾，防抖和幂等设计缺失。 最终采取折中方案：合并微服务减少链路跳转、提升基础设施配置、完善防抖机制。虽然牺牲了架构"优雅性"，但显著提升了系统稳定性和响应速度。该案例表明，高并发系统设计需要在理论完美与实际业务
2025-08-08 21:00:00
330
原创 Day11｜加代码 vs 改代码：风险、权衡与真实案例分析
文章探讨了后端开发中新增代码与修改现有代码的权衡问题。新增代码风险小、回滚容易，但会导致代码臃肿和性能问题；修改代码更优雅高效，但风险较大且测试压力大。作者通过两个案例说明：VIP用户导出功能新增代码导致性能瓶颈，积分查询统一优化引发兼容性问题。建议根据需求紧急性和影响面选择策略——短期需求优先新增代码，长期维护则考虑重构。最后强调要定期review技术债，避免代码质量持续恶化。
2025-08-07 16:13:14
320
原创 Day10｜一次微信群裂变引发的高并发事故复盘：Nginx、接口性能
今天是第十天写博客。这次要分享一次让我印象极其深刻的线上事故。现在回头看，虽然已经能自嘲“这是我离 n+1 最近的一次”，但当时的紧张和无助，真的只有亲历者才能体会。
2025-08-06 12:16:19
665
原创 Day9｜数据库表结构同步的烦恼与Flyway的优雅解法
摘要： 针对数据库表结构不同步导致的生产事故问题，本文介绍了Flyway数据库迁移工具的应用。Flyway通过版本化SQL脚本管理数据库变更，实现自动化同步、历史追溯和团队协作规范。文章以SpringBoot+MySQL为例，详细说明Flyway的配置流程：添加依赖、配置数据源、编写版本化SQL脚本（如V1__init.sql），并展示其自动执行、日志记录和回滚机制。该方案有效解决了多环境表结构差异、变更遗漏等问题，提升数据库管理的可靠性和开发效率。
2025-08-05 11:32:48
865
原创 Day8｜文件名里的“空格变+号”大坑：一次导出下载失败的排查与修复
导出Excel文件时因活动标题含空格导致下载失败的bug分析：当文件名中的空格在URL传输中被转为+号，而服务端未正确处理URL解码时，就会出现文件查找失败问题。解决方案有两种：1）生成文件名时替换空格为下划线；2）在下载接口先进行URL解码再做Base64解码。最佳实践建议文件名避免使用空格和特殊字符，并对URL参数进行严格解码处理。这个案例警示我们需重视Web开发中的编码细节问题。
2025-08-04 15:02:17
486
原创 Day6｜远程办公那些事：内网穿透、frp配置与远程桌面优化实录
《远程办公内网穿透实践：frp部署与优化经验》 本文分享了通过frp实现远程控制公司内网电脑的完整流程。作者基于云服务器（Linux）、公司电脑（Windows）和家用电脑搭建环境，详细记录了服务端与客户端的配置步骤，并针对常见问题提供排查方案，如端口连接失败、远程桌面无法访问等。针对网络卡顿问题，作者通过更换服务器节点、提升带宽、优化远程桌面设置等措施显著改善体验。实践表明，frp方案轻量但依赖网络质量，带宽和物理距离是影响远程办公流畅度的关键因素。文章为远程办公技术选型提供了实用参考。
2025-08-01 14:39:22
1034
原创 Day6｜一次依赖包“自动升级”引发的生产事故排查全记录
摘要： 本文记录了一次因依赖包自动升级引发的生产故障。项目使用+号自动拉取最新依赖版本，导致上线后因基础组件不兼容变更触发NoClassDefFoundError。通过日志分析、依赖树对比和版本回滚，确认问题根源为依赖管理不规范和缺乏变更通知机制。解决方案包括：锁定具体版本号、强化测试环境一致性、建立团队沟通机制。经验表明，依赖管理需严谨，避免盲目升级，同时需加强自动化工具应用和团队协作。
2025-07-31 13:54:33
295
原创 Day5｜从MySQL到BI：数据报表开发的“折中艺术”
摘要： 随着业务数据量激增，传统MySQL直接查询导出报表的方式面临性能瓶颈和安全风险。本文分享了引入BI工具（如CBoard、DataWorks）的实践经验：通过数据同步隔离生产库，利用离线计算提升查询性能，实现可视化分析与权限管控。虽然牺牲了部分实时性，但显著提升了安全性和运维效率。技术选型需权衡业务需求，数据安全是核心原则，BI工具能有效平衡开发成本与分析效率，推动业务可持续发展。（149字）
2025-07-30 11:23:31
941
原创 Day4｜一次MySQL高CPU事故的排查与成长
摘要： 本文复盘了一次由SQL索引设计不当引发的线上MySQL故障。事故源于定时任务违反最左匹配原则的联表查询，导致全表扫描和大事务堆积，最终使CPU飙升至100%、业务崩溃。通过排查网关日志、代码Review锁定问题后，团队采取停任务、拆事务、优化索引等紧急措施，1小时内恢复服务。作者总结出核心教训：生产环境需严格遵循索引设计规范（如最左匹配），警惕测试与生产环境差异，并强调SQL优化对系统稳定性的关键影响。此次实战经历深化了其对线上故障全流程处理的认知。
2025-07-29 10:59:30
771
原创 Day3｜国际化框架中的“时区大坑”——那些年我被时间折磨的日子
【摘要】文章深入剖析了国际化项目中的时区问题，指出时间戳存储、时区转换各环节的常见误区。通过实际案例展示了前端传递时间戳后，因后端偏移处理、环境配置不一致（服务器/JVM/数据库时区不统一）及工具显示差异导致的数据混乱问题。提出解决方案：规范使用UTC时间戳、统一环境时区配置、明确可视化工具设置，并强调时间戳存储应避免偏移处理，仅在展示层进行本地化转换。最后给出关键建议：全链路采用统一时间标准，严格定义接口规范，实现跨时区业务的可靠时间管理。
2025-07-28 11:00:56
765
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人