
业务解决方案
文章平均质量分 59
懒虫虫~
无论人生上到哪一层台阶,阶下有人在仰望你,阶上亦有人在俯视你。你抬头自卑,低头自得,唯有平视,才能看见真实的自己!
展开
专栏收录文章
- 默认排序
- 最新发布
- 最早发布
- 最多阅读
- 最少阅读
-
Redis大Key问题
在sit环境中,测试批量上传500个网元进行批量激活,突然发现激活任务执行失败,而且系统其他功能接口响应缓慢,系统几乎卡死,服务器OOM。原创 2025-07-27 20:44:58 · 335 阅读 · 0 评论 -
Metaspace耗尽导致OOM问题
生产检测到两台服务器内存仅剩50%,且CPU飙升到60%,产生告警。现网用户反映系统响应缓慢。原创 2025-07-25 22:39:22 · 162 阅读 · 0 评论 -
大数据量查询计算引发数据库CPU告警问题复盘
采用空间换时间方式,优化了大表关联查询性能,也是一种不错的方案。原创 2025-07-22 23:20:30 · 288 阅读 · 0 评论 -
【未限制消息消费导致数据库CPU告警问题排查及解决方案】
某天下午,上游系统同一时间突然下了三个大合同数据,平均每个合同数据实例在6万以上的量级,短短几分钟内瞬间有20万左右的流量涌入系统。而在正常情况下,系统1天处理的流量也不过2千量级,当时数据库指标监控告警,数据库会话直线上升,CPU毛刺增多,达到了80%。原创 2025-07-21 22:52:31 · 155 阅读 · 0 评论 -
【记某次线上消息积压问题排查及解决方案】
某版本需求,代码处理逻辑错误,导致配置新增服务范围扩大,造成消息成百倍增长,突增的消息通道部分拥堵。新增的服务会不断重试并重推消息,造成更严重的任务拥堵,无法及时消费,数据库压力增大,SQL执行变慢,导致核心业务受阻。原创 2025-07-20 22:07:06 · 203 阅读 · 0 评论 -
项目中大表治理方案实践
目前生产库数据库服务器数据存储达到了13T,其中license_spart表数据量达到了200亿,占用7.5T,空间占用率达到54%。而且这张表每年数据增长量达到30亿。其中有效VALID数据占20亿,无效数据INVALID占180亿。由于业务上有些场景,需要查询无效数据,所以不能直接删除。随着license_spart表规模持续扩大,会带来严重的性能问题、存储成本增加、备份与恢复困难、数据一致性问题(生产4台服务器)等等。原创 2025-07-04 23:38:21 · 864 阅读 · 0 评论 -
利用事务钩子函数解决业务异步发送问题
在某项业务中,需要在事务完成后,写入日志到某数据库中。需要要么都成功,要么都失败,而且需要异步实现。在不考虑分布式事务框架下,如何实现这个业务功能呢?可以利用事务钩子函数实现异步发送,保证同时成功和失败。注册事务钩子,在事务提交或回滚后执行。前提需要启动kafka_2.12-3.9.1内置的zookeeper和kafka。LogService注册钩子函数,异步发送。在kafka创建好topic。原创 2025-06-29 17:23:15 · 292 阅读 · 0 评论 -
基于SpringBoot利用死信队列解决RabbitMQ业务队列故障重试无效场景问题
Slf4j// 声明业务交换机@Bean// 声明死信交换机@Bean// 声明业务队列@Bean// 设置业务队列的死信交换机// 声明死信队列@Bean// 将业务队列绑定到业务交换机@Bean// 将死信队列绑定到死信交换机@Bean。原创 2025-06-08 18:10:24 · 1072 阅读 · 0 评论 -
基于SpringBoot解决RabbitMQ消息丢失问题
RabbitMQ提供了消息确认机制,即生产者在发送消息后,可以等待RabbitMQ服务器返回确认信息,以确保消息已经被正确地接收和处理。在发布消息时,可以设置消息的持久化标志,这样消息就会被写入磁盘中,而不是仅仅保存在内存中。可以通过设置重试次数和重试时间间隔来控制消息重试的行为。综上所述,RabbitMQ通过持久化、确认、事务和重试等机制来保证消息的可靠性,从而解决消息丢失的问题。可以看到由于接口中第1,4,5条消息会正常发送,所以在consumer已经进行了正常消费,并且针对第5条进行了业务重试。原创 2025-06-07 09:00:08 · 705 阅读 · 0 评论 -
多任务并发锁优化
最近在我们项目中,出现了数据库死锁问题,这里简单记录下分析和解决的过程。原创 2025-05-11 07:29:47 · 176 阅读 · 0 评论 -
利用无事务方式插入数据库解决并发插入问题
由于项目中同一个网元,可能会被多个不同用户操作,而且操作大部分都是以异步子任务形式进行执行,这样就会带来并发写数据问题,本文通过利用无事务方式插入数据库解决并发插入问题,算是解决问题的一种思路,算是抛砖引玉吧。原创 2025-05-01 22:20:35 · 650 阅读 · 0 评论 -
定时任务分批删除大表数据策略
随着时间的积累,数据量越来越大,其中最大的一个表数据量达到了22亿,因此需要对这些临时表进行定时清理,节省数据库存储空间和提升查询效率。分批执行的最大时间不超过默认配置时间2h,若在2h内还没有执行完成,则终止删除,等下次调度时间再重新发起执行删除操作。(1)新建相同表结构的数据表,新表补充creation_date的索引,利用同步工具同步最新15天的数据到新表。需要保留最近15天的数据且数据量太大,不能直接delete,所以采用定时任务分批进行删除策略。每次删除的最大数量按照10000条进行限制。原创 2025-04-19 10:09:26 · 390 阅读 · 0 评论 -
记录一次利用条件索引优化接口性能的实践
某表数据量达到4000w,需要每天定时任务处理20w条。前2周内SQL执行无任何问题,非常快,效率比较高。随着处理完的数据量变大,处理完数据状态设置为1,SQL执行效率越来越差,已经达到了惊人的4.6秒。SQL如下:其中表A的expired_date是有索引的。原创 2025-03-06 22:14:54 · 261 阅读 · 0 评论 -
使用CAS解决项目中高并发时数据一致性问题
最近项目中需要对退网资源进行扣减,由于项目中并没有分布式锁也没有引入Seta等一系列原因,所以采用CAS乐观锁解决高并发资源扣业务问题。原创 2024-12-01 08:04:15 · 218 阅读 · 0 评论