某队列积压问题分析、解决

最新推荐文章于 2024-11-18 11:19:03 发布
最新推荐文章于 2024-11-18 11:19:03 发布
阅读量266 收藏
点赞数
文章标签： 数据库 php
原文链接：http://www.cnblogs.com/sealake/p/8118568.html
版权

07.29 最高到了115w积压， 07.30也有持续几分钟上万的走势

分析

对update_betting_offer的处理包括2部分，Handler_Filter和Handler_Trigger， 性能问题发生在Handler_Filter阶段

Handler_Filter各个子阶段在07.29日大于1s的个数如下：

阶段名大于1s个数
odds_source_save12233
odds_match_map423910
odds_get_event4798
odds_source_filter12513
odds_cache_save179

 

08.11 开始新的统计各阶段大于1s次数

阶段名08.1108.1208.13
odds_source_save922188518326141
odds_match_map45237245608566
odds_get_event795468363825125
odds_source_filter12556412413535280
odds_cache_save9681960687
odds_risk_control11327511190233028

主要问题点：

odds_match_map  将赔率源的比赛转化为内部的比赛信息

gearman同步调用，发送赔率信息到某队列
1.1 结构问题： 同一个时刻会收到大量同一场比赛的赔率信息， 这些相同比赛的赔率都会进行findMatch处理（其实没必要），只要该比赛的处理慢，那都会慢，导致队列堆积

      加锁 锁名称 : lock:update_betting_offer:match_map:赔率源:源sport_id:源match_id      缓存名称: update_betting_offer:match_map:赔率源:源sport_id:源match_id ,   存储匹配后的match_id, 值为0表示无法匹配。 过期时间 3分钟
1.2 程序问题：

  • 在findMatch最后，不管匹配数据是否发生变化，都会向map_soccer_match更新数据，再加上并发问题，导致大量无谓的更新操作。下图中的count表示数据更新的次数。 （对数据进行了判断，数据变化的时候才去更新）

  • 当模糊匹配时，需要匹配的比赛多是，性能下降。 经测试，SQL框架比直接连接mysql查询要慢。 277场比赛慢2s，框架2.6s，直连0.6s
  • addMapMatchLog函数中sql没有索引，影响大。表是map_sort_match_log，可以对ms_id加索引，同时因为并发问题，导致很多重复数据   （08.07添加的索引）. 并改成异步写
  • findMatchByTeamId函数中sql语句优化， 里面有联表查询
odds_source_save  保存赔率源数据
  • 将saveOdds函数中想mongo写数据的操作改成异步
  • saveOdds对mysql 跟上面的写mongo一起做成异步 

  • $sql = "SELECT last_updated FROM `{$tbl}` WHERE `match_id` = '{$data['match_id']}' AND `provider_id` = '{$data['provider_id']}' AND `betting_type_id` = '{$data['betting_type_id']}' AND `boundary` = '{$data['boundary']}' LIMIT 1";    这条语句时不时超过1s。 
    1: where后面的字段都是整型， 变量都赋成了字符串。 要让数据库减少这种类型转换
    2: where后面的字段被设置成了 PRIMARY KEY (`match_id`,`provider_id`,`betting_type_id`,`boundary`),   而offer表 插入更新是非常频繁的，这4个字段的主键会造成过大的主键索引和IO操作。 需要新增一个自增字段作为主键，  为match_id`,`provider_id`,`betting_type_id`,`boundary`创建唯一联合索引

    主键的选择：
主键递增，数据行写入可以提高插入性能，可以避免page分裂，减少表碎片提升空间和内存的使用
主键要选择较短的数据类型， Innodb引擎普通索引都会保存主键的值，较短的数据类型可以有效的减少索引的磁盘空间，提高索引的缓存效率
http://blog.youkuaiyun.com/jhgdike/article/details/60579883

    3. offer表定期清理数据，根据last_updated保留近半个月数据。半个月大概400w条
    4. 分表数据分布不均衡，目前写操作集中到了同一张表，修改分表算法
    5. 改成读从库

odds_check_league 检查联赛是否有效

    加锁 锁名称 : lock:update_betting_offer:check_league:match_id      缓存名称: update_betting_offer:check_league:match_id ,  存储匹配后的联赛id以及是否有效，格式（1有效，0无效）： league_id:1，  过期时间 60分钟      

odds_get_providerid 获取赔率公司id
  •  大量并发查询相同公司id， 如果查不到还会大量插入更新。 加分布式锁（赔率源名称+provider_id）只查一次。
      加锁 锁名称 : lock:update_betting_offer:get_provider_id:赔率源:provider_id      缓存名称: update_betting_offer:get_providerid:赔率源:provider_id ,  存储匹配后的provider_id, 值为0表示无法匹配，  过期时间 60分钟
  •  可以将这一步检测提前到程序开始处，查不到的就直接返回了
  •  写 表map_soccer_provider的操作改成异步
odds_get_event 获取eventid
odds_source_filter 
odds_risk_control  赔率风控

  • 调用http接口获取99家平均赔率时间长

    2017-08-18 23:55:07  2600723 1.0097689628601 msg=
2017-08-18 23:55:09  2602205 3.0126769542694 msg=
2017-08-18 23:55:09  2601298 3.0131931304932 msg=
2017-08-18 23:55:11  2601881 1.0082378387451 msg=
2017-08-18 23:55:11  2601235 1.0080330371857 msg=
2017-08-18 23:55:11  2601259 1.0102519989014 msg=
2017-08-18 23:55:12  2602482 1.0055501461029 msg=
2017-08-18 23:55:12  2601226 1.0132040977478 msg=
2017-08-18 23:55:14  2600658 1.0105800628662 msg=
2017-08-18 23:55:14  2599056 1.0061559677124 msg=
2017-08-18 23:55:14  2601298 1.0084340572357 msg=
2017-08-18 23:55:15  2601300 1.0130741596222 msg=
2017-08-18 23:55:23  2602194 1.0079371929169 msg=
2017-08-18 23:55:26  2601221 1.0092370510101 msg=
2017-08-18 23:55:28  2600658 1.0096790790558 msg=
2017-08-18 23:55:28  2600575 1.0079090595245 msg=
2017-08-18 23:55:31  2600710 1.012079000473 msg=
2017-08-18 23:55:34  2599398 1.0108640193939 msg=
2017-08-18 23:55:39  2601414 1.0104100704193 msg=
2017-08-18 23:55:39  2600723 1.0120589733124 msg=
2017-08-18 23:55:39  2601519 1.0102570056915 msg=
2017-08-18 23:55:46  2602127 3.0110030174255 msg=
2017-08-18 23:55:52  2601759 1.0077710151672 msg=
2017-08-18 23:55:52  2601060 1.0113618373871 msg=
2017-08-18 23:55:55  2600575 1.0087251663208 msg=
2017-08-18 23:55:55  2601414 1.016450881958 msg=
2017-08-18 23:55:57  2602255 1.0063278675079 msg=
2017-08-18 23:56:00  2599400 1.0102560520172 msg=
2017-08-18 23:56:00  2600574 1.010486125946 msg=
2017-08-18 23:56:00  2601304 1.0060698986053 msg=

     

  • 99家平均由http调用改成直接读取数据库。 （只有一台http机器调用超时严重）17.11.30

  • 调用gearman报错

    [18-Aug-2017 13:19:50 Asia/Shanghai] PHP Warning:  GearmanClient::doNormal(): _client_do(GEARMAN_NO_ACTIVE_FDS) occured during gearman_client_run_tasks()

[18-Aug-2017 13:19:51 Asia/Shanghai] PHP Warning:  GearmanClient::doNormal(): _client_do(GEARMAN_TIMEOUT) occured during gearman_client_run_tasks() -> libg

     

关于锁的操作

  1.  redislock 的lock函数增加参数 cache_key， 判断是否lock成功根据wait_time和cache_key一起，  当wait_time时间未到但cache_key存在时返回 [ 'cache_key' => cache_key, 'cache_value' => cache_key对应的值 ];
  2. 调用lock函数设置锁的expire_time要比wait_time长，  当超时返回lock失败后， 调用对应接口
  3. 当lock成功后， 要设置缓存以及过期时间，最后释放锁
  4. 当返回的是[ 'cache_key' => cache_key, 'cache_value' => cache_key对应的值 ];  按正常流程处理即可

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

通过上面优化的结果：高峰期的队列无积压。

这里面最主要问题：开发人员没有性能意识，自己给自己挖坑，人为增加系统压力

1. 大量无谓的重复查询

2. 大量无谓的写操作以及没有分散写

3. 主次不分， 让边缘功能影响了核心功能

4. 并发冲突，系统无法横向扩展

转载于:https://www.cnblogs.com/sealake/p/8118568.html

如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，如何解决？
悟已往之不谏，知来者之可追
04-19 861
问题 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？ 分析 你看这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了；或者消费的速度极其慢。接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？或者是这整个就积压了几个小时，你这个时候怎么办？或者是你积压的时间太长了，导致比如 RabbitMQ 设置了消息过期时间后就没了怎么办？ 所以就这事儿，其实线上挺常见的，一般不出，一出就是大 case。一般常见于
如何解决消息队列的延时以及过期失效问题？
黎明就要到来
05-24 1017
，共同构成了我们的应用程序。当进行一个业务时不可避免就会存在多个服务之间调用，假如一个服务 A 要访问在另一台服务器部署的服务 B，那么前提是服务 A 要知道服务 B 所在机器的 IP 地址和服务对应的端口，最简单的方式就是让服务 A 自己去维护一份服务 B 的配置（包含 IP 地址和端口等信息），但是这种方式有几个明显的缺点：随着我们调用服务数量的增加，配置文件该如何维护；注册中心提供了服务注册接口，用于当有新的服务启动后进行调用来实现服务注册，或者心跳检测到服务状态异常时，变更对应服务的状态。
消息队列堆积太多，下游处理不过来怎么办呢？
m0_69860228的博客
05-10 617
作为后端程序员日常工作中难免会遇到要跟消息队列打交道的时候，而且在当下微服务的场景下，很多服务的性能不是我们自己能控制的。 这不阿粉最近就遇到了一个场景，由于上游服务流量增加，发送到消息队列的消息增多，阿粉在处理消息的时候需要依赖下游的一个服务，可是谁想到下游的服务效率太差，消息太多处理不过来，CPU 居高不下。 看过我们昨天文章的小伙伴应该都知道，这个时候我们就需要进行限流了，为了避免将下游的服务打垮，我们来进行单机限流操作。这里我们来模拟一下操作过程，首先我们通过一段伪代码来模拟大流量，然后通过配置
三招！解决消息队列的数据积压问题
码猿技术专栏
05-14 1537
点击上方☝码猿技术专栏轻松关注，设为星标！及时获取有趣有料的技术今天，就讲讲解决消息队列的数据积压的三个方案。1 概述最近生产环境的消息通知队列发生了大量的数据积压问题，从而影响到整个平...
解决消息队列的数据积压问题
qq_24692021的博客
12-07 781
今天，就讲讲解决消息队列的数据积压的三个方案。 1 概述 最近生产环境的消息通知队列发生了大量的数据积压问题，从而影响到整个平台商户的交易无法正常进行，最后只能通过临时关闭交易量较大的商户来缓解消息队列积压的问题，经线上数据分析，我们的消息队列在面对交易突发洪峰的情况下无法快速的消费并处理队列中的数据，考虑到后续还会出现各种交易量突发状况，以下为针对消息队列（ActiveMQ）的优化过程。 2 消息队列通信图 3 问题定位与分析 3.1 消息通知数据为什么会被积压？ 分析：平台中每个交易的发生
rabbitmq 消息队列堆积问题
qq_36202485的博客
08-09 4420
项目遇到mongo数据恢复的问题，首先我从原项目中将数据导出，然后恢复到指定的服务器，以为就好了。 但是遇到一个 问题，就是rabbitmq的消息队列出现了消息堆积，刚开始我以为是rabbitmq服务的问题，但是消息队列偶尔又会出现一两次被消费的情况。 这时我查看系统的cup的使用率，发现mongo这个进程的使用率很高，内存使用率也很高，这时，我使用命令db.currentOp()查看Mong...
如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？
zengqingfa123的博客
10-17 963
某些业务流程如果支持批量方式消费，则可以很大程度上提高消费吞吐量，例如订单扣款类应用，一次处理一个订单耗时 1 s，一次处理 10 个订单可能也只耗时 2 s，这样即可大幅度提高消费的吞吐量，通过设置 consumer 的 consumeMessageBatchMaxSize 返个参数，默认是 1，即一次只消费一条消息，例如设置为 N，那么每次消费的消息数小于等于 N。关于这个事儿，我们一个一个来梳理吧，先假设一个场景，我们现在消费端出故障了，然后大量消息在 mq 里积压，现在出事故了，慌了。
消息队列拉模式下的订阅关系不一致问题及解决方法
在途中
05-26 1125
在Java行业的分布式系统中，消息队列拉模式下的订阅关系不一致问题是一个常见且影响深远的问题。通过本文的详细介绍，读者可以清晰地理解这一问题的定义、影响及其解决方法。无论是通过确保订阅关系的一致性、一致性哈希算法，还是消息过滤机制，都可以有效解决订阅关系不一致问题，提升系统的稳定性和可靠性。希望本文能帮助读者更好地理解和应对消息队列拉模式下的订阅关系不一致问题，提升系统的性能和稳定性。如果您有任何疑问或建议，欢迎在评论区留言，我们将竭诚为您解答。
春招面试复习：消息队列（五）- 消息积压解决方案
Viper的程序员修炼手册
01-14 1430
1 消息积压问题追溯 系统某部分出现性能问题，来不及处理上游发的消息，导致消息积压。 消息积压是正常现象，积压越来越多就需要处理了。 就像一个水库，日常蓄水是正常的，但下游泄洪能力太差，导致水库水位一直不停的上涨，这个就不正常了。 2 积压的开发警示 防范于未然，平时使用MQ时，如何优化代码才能避免消息积压？ 若线上已出现积压，如何处理最好？ 3 性能优化 性能的优化主要在生产者和消费者这俩业务逻辑。 MQ自身性能，作为API使用者，无需过于关注。 因大多MQ业务，MQ本身处理能力远大于业务系统。主流MQ的
[Postfix]按照队列的错误信息删除postfix挤压队列工具
隔壁-老阳
02-03 666
#!/usr/bin/perl -w use strict; my $LISTQ = "postqueue -p"; my $POSTSUPER = "postsuper -d"; my $FILE="outfile"; my $info = ""; my $i; if ( @ARGV != 1 ) { die "Usage: $0 [\"error info\"] \n";
【RabbitMQ】RabbitMQ 消息的堆积问题 —— 使用惰性队列解决消息的堆积问题
qq_61635026的博客
11-04 4615
消息的堆积问题是指在消息队列系统中，当生产者以较快的速度发送消息，而消费者处理消息的速度较慢，导致消息在队列中积累并达到队列的存储上限。在这种情况下，最早被发送的消息可能会在队列中滞留较长时间，直到超过队列的容量上限。当队列已满且没有更多的可用空间来存储新消息时，新的消息可能无法进入队列，从而导致消息丢失。这种情况下的消息通常被称为死信，因为它们无法被正常消费。
消息队列常见问题之消息发生大量堆积应该怎么处理
qq_38480786的博客
04-22 7374
线上故障了，怎么处理 消息堆积了10小时，有几千万条消息待处理，现在怎么办? 修复consumer, 然后慢慢消费？也需要几小时才可以消费完成，新的消息怎么办？ 核心思想：紧急临时扩容，更快的速度去消费数据 - 修复Consumer不消费问题，使其恢复正常消费，根据业务需要看是否要暂停 - 临时topic队列扩容，并提高消费者能力，但是如果增加Consumer数量，但是...
消息队列中如何解决消息堆积问题？
weixin_52136521的博客
11-18 746
如字面意思，太多的请求消息堆积在队列里面迟迟得不到解决。话题里面一般有四个队列，一般某个队列堆积的消息超过10w就算消息堆积了。
RabbitMQ（四） | 惰性队列 - 解决消息堆积问题
慌途L
06-24 3025
接上一篇：RabbitMQ（三） | 死信交换机、死信队列、TTL、延迟队列（安装DelayExchange插件）当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，直到队列存储消息达到上限。之后发送的消息就会成为死信，可能会被丢弃，这就是消息堆积问题。 解决消息堆积有两种思路：要提升队列容积，把消息保存在内存中显然是不行的。从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。惰性队列的特征如下：而要设置一个队列为惰性队列，只需要在声明队列时
记一次惊心的网站 TCP 队列问题排查经历
weixin_37478507的博客
05-15 1844
作者：刘晓明，五矿电商（（www.wuage.com））运维技术负责人，拥有10年的互联网开发和运维经验。一直致力于运维工具的开发和运维专家服务的推进，赋能开发，提高效能。广告时间：最后给自己代个盐~~欢迎大家有空时翻下我牌子(知乎号：布道 )，看看“开发运维”专栏的文章，希望多些关注和点赞是给作者最好的鼓励 ！1   问题描述监控系统发现电商网站主页及其它页面间歇性的无法访问；查看安全防护和网络...
gearman 任务失败_Gearman简介-PHP中的多任务
culi3118的博客
08-16 311
gearman 任务失败How many times have you developed a web application that had some functionality which would benefit from running an external program or even forking a separate process? This is not somethi...
【消息中间件】详解mq消息积压
BugMan的博客
09-19 2912
详解mq消息积压的表现、原因、解决办法。
Java卡队列，怎么让队列重新执行
最新发布
04-17
<think>嗯，用户的问题是Java队列卡住了，需要让队列重新执行任务。我得先理解队列卡住的原因。根据引用中的信息，队列可能因为任务堆积或者线程池配置不当导致任务无法及时处理。比如，引用[1]提到，任务调度和执行依赖于队列，如果队列中有很多未被处理的任务对象，就会导致卡顿。这时候需要用jmap检查队列中的任务数量。 接下来，线程池的配置也很重要。引用[2]和[3]讨论了线程池的大小设置，特别是CPU密集型和IO密集型任务的配置。如果线程池的线程数不足，任务就会积压在队列里。比如，用户可能用了默认的单线程执行器，导致任务排队等待。这时候需要调整线程池的大小，或者使用合适的队列类型，比如有界队列，避免无限制堆积。 另外，任务本身的执行是否阻塞了线程？比如，如果任务中有同步阻塞操作，而线程池的所有线程都在等待，就会导致队列卡住。这时候可能需要检查任务代码是否有死锁或者长时间阻塞的情况，或者使用异步处理来释放线程。 还有可能任务执行失败后没有正确的重试机制，导致任务被丢弃。需要添加重试逻辑，确保失败的任务能够重新入队执行。引用[3]提到，需要保证同一实例的任务顺序执行，但线程池的线程数要足够处理任务量。 最后，监控队列状态也很重要，比如实时监控队列大小和线程池状态，及时发现问题。可能还需要优雅的重启机制，先停止新任务，处理完队列中的任务后再重启服务，避免数据丢失。 综合这些方面，解决方案应该包括检查队列堆积情况、优化线程池配置、处理任务异常、添加重试机制、异步处理和监控队列状态。需要一步步排查原因，然后针对性地调整配置和代码。</think>### 分步解决方案：Java队列卡住问题排查与恢复执行 #### 1. 确认队列卡死的根本原因 - **检查队列堆积状态** 通过命令`jmap -histo <PID> | grep "TriggerParam"`检查队列中未处理的任务对象数量[^1]。若发现大量积压，说明任务消费速度低于生产速度。 - **线程池状态分析** 使用`jstack <PID>`导出线程堆栈，观察线程池中的工作线程是否： - 全部处于`BLOCKED`或`WAITING`状态（可能死锁） - 因I/O操作被阻塞（如数据库连接未释放） - 执行耗时操作未响应中断 #### 2. 恢复队列执行的紧急措施 ```java // 示例：动态调整线程池容量（Spring环境） @Bean public TaskScheduler taskScheduler() { ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler(); // I/O密集型场景建议设置为CPU核心数*2[^2] scheduler.setPoolSize(Runtime.getRuntime().availableProcessors() * 2); return scheduler; } ``` #### 3. 防止队列卡死的长期优化 | 优化方向 | 具体措施 | |----------------|-------------------------------------------------------------------------| | 队列选择 | 使用`LinkedBlockingQueue`设置合理容量阈值，避免无界队列导致内存溢出 | | 线程隔离 | 对关键任务使用独立线程池，防止因某一任务类型阻塞影响全局[^3] | | 任务监控 | 集成Micrometer指标监控队列深度、活跃线程数、任务耗时等关键指标 | | 优雅终止 | 实现`ShutdownHook`确保中断时先完成队列任务，再调用`awaitTermination()` | #### 4. 任务重试机制实现 ```java // 带指数退避的重试模板 public class RetryTemplate { private static final int MAX_RETRIES = 3; private static final long BASE_DELAY = 1000; public static <T> T executeWithRetry(Callable<T> task) { int retries = 0; while (retries < MAX_RETRIES) { try { return task.call(); } catch (Exception e) { long delay = (long) (BASE_DELAY * Math.pow(2, retries)); Thread.sleep(delay); retries++; } } throw new RetryException("Exceeded max retries"); } } ``` #### 5. 队列复活操作流程 1. **暂停新任务入队**：调用`queue.pause()` 2. **导出积压任务**：通过`drainTo()`方法转移现有任务到临时列表 3. **重置线程池**： ```java executor.shutdownNow(); // 发送中断信号 if (!executor.awaitTermination(10, TimeUnit.SECONDS)) { // 强制关闭未响应线程 } executor = new ThreadPoolExecutor(...); // 重建线程池 ``` 4. **重载任务**：按优先级重新提交任务，附加重试标记 5. **恢复服务**：逐步放开流量入口
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值