jike11231的博客

Slf4j// 声明业务交换机@Bean// 声明死信交换机@Bean// 声明业务队列@Bean// 设置业务队列的死信交换机// 声明死信队列@Bean// 将业务队列绑定到业务交换机@Bean// 将死信队列绑定到死信交换机@Bean。

RabbitMQ提供了消息确认机制，即生产者在发送消息后，可以等待RabbitMQ服务器返回确认信息，以确保消息已经被正确地接收和处理。在发布消息时，可以设置消息的持久化标志，这样消息就会被写入磁盘中，而不是仅仅保存在内存中。可以通过设置重试次数和重试时间间隔来控制消息重试的行为。综上所述，RabbitMQ通过持久化、确认、事务和重试等机制来保证消息的可靠性，从而解决消息丢失的问题。可以看到由于接口中第1，4，5条消息会正常发送，所以在consumer已经进行了正常消费，并且针对第5条进行了业务重试。

最近在我们项目中，出现了数据库死锁问题，这里简单记录下分析和解决的过程。

由于项目中同一个网元，可能会被多个不同用户操作，而且操作大部分都是以异步子任务形式进行执行，这样就会带来并发写数据问题，本文通过利用无事务方式插入数据库解决并发插入问题，算是解决问题的一种思路，算是抛砖引玉吧。

随着时间的积累，数据量越来越大，其中最大的一个表数据量达到了22亿，因此需要对这些临时表进行定时清理，节省数据库存储空间和提升查询效率。分批执行的最大时间不超过默认配置时间2h，若在2h内还没有执行完成，则终止删除，等下次调度时间再重新发起执行删除操作。(1)新建相同表结构的数据表，新表补充creation_date的索引，利用同步工具同步最新15天的数据到新表。需要保留最近15天的数据且数据量太大，不能直接delete，所以采用定时任务分批进行删除策略。每次删除的最大数量按照10000条进行限制。

某表数据量达到4000w，需要每天定时任务处理20w条。前2周内SQL执行无任何问题，非常快，效率比较高。随着处理完的数据量变大，处理完数据状态设置为1，SQL执行效率越来越差，已经达到了惊人的4.6秒。SQL如下：其中表A的expired_date是有索引的。

最近项目中需要对退网资源进行扣减，由于项目中并没有分布式锁也没有引入Seta等一系列原因，所以采用CAS乐观锁解决高并发资源扣业务问题。