- 博客(46)
- 收藏
- 关注
RSS订阅原创 2024年年终总结与2025年展望
这些宝贵的知识将为我提供坚实的基础，使我在2025年参与B端服务的重构工作中，能够提出切实可行且具有前瞻性的建议，为项目的顺利进行和成功贡献更多的力量。在新的一年里，我将继续努力，不断提升自己的技术能力、业务能力以及综合素质，为团队项目成功贡献更多的力量，为公司创造更大的价值。这些书籍不仅为我提供了深入的技术知识，还激发了我对系统设计和数据管理的新思考。在这一年中，我经历了个人成长和职业发展的双重飞跃，感受到了前所未有的充实与满足。
2025-01-04 16:06:39
901
原创 MySQL千万表归档实践
随着项目数据量的急剧增长，为了优化性能提升产品体验感，我们决定对数据进行归档处理。归档策略为实时数据仅保留6个月，超过期限的数据将被归档至历史表中，在此过程中，我们遇到了数据库主从延迟的问题，下面将进行分析去解决暂停策略是一个临时解决方案，但它在一定程度上缓解了主从延迟问题，保证了归档操作的顺利进行。我们将继续监控数据库性能，并寻求更长期的解决方案，以确保数据的一致性和归档操作的效率。
2024-12-26 19:31:55
1413
原创 MySQL数据库报“You are not owner of thread”错误的解决方法
MySQL数据库报“You are not owner of thread”错误的解决方法
2024-12-12 16:08:45
929
2
原创 Kafka异常重试方案小记
此外，我们增加了一个Web端的手动重推功能，以便于在需要时手动触发消息的重新处理，若后续异常消息多时可以考虑自动的定时调度。为了进一步增强异常处理能力，我们可以通过自行编码，在消费异常时将相关信息写入日志，或者在消费后立即写入消息，待后续消费成功后再更新其状态。为了解决重平衡期间可能出现的消息丢失问题，我们计划引入JVM钩子，在发版时对当前工作线程池中的消息进行快照，并在后续重新推送这些消息。而在kafka中原本并无死信队列的概念，所以当需要自行封装这一层概念的时候，就可以脱离既定思维的约束，
2024-10-20 17:30:28
1684
原创 MySQL五千万大表查询优化分析实战
对于一个SQL的优化我感触比较深的是：不能仅从SQL本身去进行优化，而需要结合具体的业务进行权衡从而选择一个合适的方案进行优化，目前项目也到高速上升期，出现了很多大表，未来系统将会有更多的问题，当然这即是问题也是挑战，加油！！！
2024-10-09 13:43:29
806
1
原创 MySQL删除重复记录并且只保留最新一条
在开发过程中，因为某些问题可能会导致同一条数据在表中重复出现，此时我们需要申请权限走SQL去修复，下面介绍下具体修复流程。
2024-08-07 14:51:18
1837
原创 使用Mybatis批量插入大量数据的实践
在项目开发过程中，我们经常会有批量插入的需求，例如：定时统计任务但是受限于MySQL中参数限制，5.7版本默认值为4M，这显然不太符合我们的需求，当然我们也可以通过修改此值来适应我们业务，今天分享在不修改此值的情况下，如何在客户端优雅的处理此场景现在整个世界都变优雅了！
2024-07-05 14:24:32
4210
原创 Mybatis-Plus多种批量插入方案对比
这里先留下一张saveBatch的SQL日志截图，这里的日志是一个insert into语句，下面带了一千条数据(MP默认一千条一个批次)，使用Mybatis Log插件查看还是单条的SQL。再来看看此时控制台的SQL，与方案二的SQL有着明显的区别，这里是将批次插入的数据拼接在同一条SQL中，对于MySQL处理来说，这是真的批量新增。因很早就听闻过mybatis-plus的[伪]批量新增的问题，很快锁定问题并进行修复，下面细节描述多种批量新增方案的具体性能表现。方案一：传统for循环。
2024-06-15 22:37:22
2070
原创 MySQL树形表查询优化
这种方案挺常见，在数据量少的时候可以采用，但是量一旦大了以后呢，性能变差 且 通过Mybatis拼接完SQL以后可能会超长（而通过多线程分批后聚合编码又较为复杂）因为其他方案本质都是通过 IN 来查询数据，虽然还可以进一步对 IN 方案进行优化(例如：业务上多线程分批IN，EXISTS等)，但还是略逊一筹。但这种方式也有个弊端，那就是有的项目上还没用上MySQL8.0，那该如何处理呢？请接着看第四个通用方案。一个代理可以有很多子代理，然后子代理又有子代理，业务要求父代理能看到所有子代理的数据。
2024-05-12 23:27:37
885
1
原创 日报表定时任务优化历程
报表是一个很常见的需求，在项目中后期往往会需要加多种维度的一些统计信息，今天就来谈谈上线近10个月后的一次报表优化优化之路（从一天报表跑需要五分钟，优化至秒级）思考：报表任务里都是一些MySQL查询 以及 内存循环对比，且门店统计那块是嵌套循环查询，订单的查询时间也有点长。以上流程跑当日耗时大约在4-5分钟，乍一看其实并不慢，但此时距离上线已有九月有余，乍一算这个任务得跑20+小时。心好累，心好累，执行超时，立马查看mysql连接 以及 德鲁伊连接池 的超时参数，果然…不管了，能跑就行，先上线再优化。
2024-05-11 21:02:25
1171
原创 德鲁伊Druid参数踩坑之路
2024/04/16日，业务反馈某个定时统计的数据未出来，大清早排查定位是其统计任务跑批失败，下面给一段伪代码。心好累，心好累，执行超时，立马查看mysql连接 以及 德鲁伊连接池 的超时参数，果然......因此业务是历史遗留的，本着解决问题的思路先将此参数修改大一下，赶紧搞定就下班回家洗洗睡了。其实在这段排查过程中，踩了好几个坑，也被好几个坑给阻碍排查的进度，下面列举下。到这真相大白，赶紧将testOnBorrow改回true，先将问题解决。修改后打补丁继续执行，又又又失败了..........
2024-04-19 14:55:21
629
1
原创 高并发场景下底层账务优化方案
在秒杀等场景中，经常会需要对库存、商家冻结资金做一些修改，而并发一旦上来后会导致这个修改动作频繁超时及失败，下面将以问答形式分享解决方案
2024-01-14 06:15:00
803
原创 关于订单超时后用户却已支付的解决方案
一般我们下的一些订单，比如电商平台、外卖平台的都是有超时时间的，默认一般15或者30分钟，那么超时未支付订单会被自动取消，那么如果刚好有人在关闭订单的时候去支付成功了，或者说支付平台延迟了一下，你取消了订单，这时候支付成功的回调通知过来了，那怎么办呢?但是也有的三方支付的快捷支付，不支持绝对超时时间，以具体银行超时时间为准，不予配置，这个场景在关闭业务系统超时订单时，可以手动调用一次关单接口，根据关单结果再去决定是否关闭业务系统的订单。取消了都能去支付成功再把订单状态翻转回来的话，那就太恐怖了。
2024-01-09 06:15:00
2812
3
原创 支付回调场景方案
在现有支付体系下，项目想使用支付功能，都需要对接类似于支付宝 微信 聚合支付这种第三方公司，那我们系统如何知道用户是否真的付款了呢？
2024-01-08 06:15:00
2763
原创 @Async正确使用姿势
@Async注解可以使被修饰的方法成为异步方法，简单且方便，这篇文章将教你正确去使用它，避免默认线程池所引发的生产事故
2024-01-07 06:15:00
1474
1
原创 码农第三定律-时间总是不够的【三】
正因为各种不完美的存在，人不完美，环境不完美，所以项目进度一定会被各种因为干扰，时间不够是大概率的事件，是常规现象，时间够用才是特殊情况。接受时间和资源的矛盾，从项目已开始就要有充分的准备，赶早不敢晚，为后续各种不完美预留好缓冲空间。
2024-01-03 06:15:00
1040
1
原创 码农第一定律-需求总是会变的【一】
无论是抱怨还是指责，都不利于事情的解决。接受现实，互相理解，需求不是需求人员自己的事情，而是项目组一起的事，是项目成败的关键，积极学习和了解业务知识，项目组成员一起完善需求，对需求的理解和认识达成一致。对于需求中的假设条件，优先顺序，版本范围，预期效果等，是经大家一起确认的，如果后续有变化，不再是某个人的原因，而是项目组需要共同面对的
2024-01-01 06:15:00
850
原创 Spring嵌套事务异常记录
Spring事务嵌套引发的事故---Transaction rolled back because it has been marked as rollback-only
2023-12-30 06:15:00
605
1
原创 数据库优化【一】
数据库最大连接数，各应用最大的连接数，cpu和io的消耗 数据块的指标 需要统一，团队所有开发都需要清楚认识并落实。目前生产几百张表，有的表数据量达到了千万，导致数据库压力非常大，一些查询非常慢。团队人数较多，目前未对SQL有统一的规范，故开启了这次讨论会，谈谈大家的看法。7、定期检查数据的增量 查询访问量，对数据过大的表进行分区分表或PG库改造。15、对于一些需要实时查看的数据，可以先缓存，然后通过通知更新数据。17、查询数据比较大的时候，可以先做统计使用大数据和es进行查询。
2023-12-28 06:30:00
546
1
原创 2023-飞速成长的一年
在这短短的一年里，我的成长飞速迸发，深感行业前辈们经典著作的引领与时常交流的小伙伴们的启发对我的发展产生了积极的推动作用。感激这段时光里得到的指引与支持，让我更加坚定地走在成长的道路上。
2023-12-27 13:51:58
579
1
原创 记一次Feign使用问题
然而现在对方要求的是 application/x-www-form-urlencoded, 但是我们习惯使然，这里还是会使用对象传输，最终会去找到springencode这个类去进行编码(这是在feign拦截器之前的动作)平常我们使用post一般都是如下，而这编码器就会按json去编码，请求头为application/json，如果对面也是需要接受json，这是没问题的。前言：调第三方使用post，要求 Content-Type配置为 application/x-www-form-urlencoded。
2023-12-27 06:15:00
836
1
原创 百万数据导出
而当数据较多时，导出又会时常出现OOM，甚至引发雪崩连锁效应，不巧的是我们前段时间正在生产经历这种问题：单月百万左右订单，微服务架构，导出订单这个功能正巧落在订单服务，然后因此次导出导致OOM，继而出现雪崩，依赖的服务相继“跪下”了，现场情况大致如下。一般建议将应用服务器和文件服务器分开，应用服务器需要更多的内存资源或者CPU资源，而文件服务器需要更多的磁盘资源。可以采用分页，也可以采用 断点续传，本质都是可以减少内存占用（mysql占用内存 加载到jvm中占用特别大）5. 如果是异步，用户怎么拿到数据。
2023-12-26 01:45:00
804
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人