We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
在saas系统中消息队列优先级划分主要意义是提高吞吐,降低延时很有意义,从业务历史来看,主要是防止一个大的公司生成大量的消息阻塞消息通道,让其他公司的消息延时提高,当一个超大型公司在短时间内产生大量的推送消息造成长时间占用消息通道的时候,此时就应该将此公司等级动态降低优先级,无可厚非的提高消息时延。 所以,对于存在优先级的队列应实现如下:
redis 记录消息数量,生产端+1,消费端-1,形成公司与队列类型维度的消息数量记录。
根据公司业务类型消息拥塞数量进行选择队列优先级。此时就算单一公司单一业务出现积压,也不影响其他公司的其他业务,且不影响该公司的其他业务。
非保障型公司出现大数量消息积压时,可不对消费资源进行扩容,按照正常速度消费,此时积压造成的消息时延应该归类为客户操作不当引起。 对于保障型公司,可对消费资源进行合理的扩容,降低消息时延
某家公司某单一业务出现大面积拥塞时,可随时清理积压的消息,快速消除积压数量,但是一般不使用,仅在出现恶意操作出现时。
消息队列类型,根据业务进行合理的调整数量区间,根据平峰时期消费能力,推算合理区间范围,目标是可随时调整区间、优先级划分等级
The text was updated successfully, but these errors were encountered:
No branches or pull requests
在saas系统中消息队列优先级划分主要意义是提高吞吐,降低延时很有意义,从业务历史来看,主要是防止一个大的公司生成大量的消息阻塞消息通道,让其他公司的消息延时提高,当一个超大型公司在短时间内产生大量的推送消息造成长时间占用消息通道的时候,此时就应该将此公司等级动态降低优先级,无可厚非的提高消息时延。
所以,对于存在优先级的队列应实现如下:
流程
redis-queue_block_${company_id}:${queue_type}:
redis 记录消息数量,生产端+1,消费端-1,形成公司与队列类型维度的消息数量记录。
A: 判断当前公司,消息拥塞数量
根据公司业务类型消息拥塞数量进行选择队列优先级。此时就算单一公司单一业务出现积压,也不影响其他公司的其他业务,且不影响该公司的其他业务。
B: 判断是否是付费保障型公司
非保障型公司出现大数量消息积压时,可不对消费资源进行扩容,按照正常速度消费,此时积压造成的消息时延应该归类为客户操作不当引起。
对于保障型公司,可对消费资源进行合理的扩容,降低消息时延
C: 当前是否可丢弃消息
某家公司某单一业务出现大面积拥塞时,可随时清理积压的消息,快速消除积压数量,但是一般不使用,仅在出现恶意操作出现时。
queue
消息队列类型,根据业务进行合理的调整数量区间,根据平峰时期消费能力,推算合理区间范围,目标是可随时调整区间、优先级划分等级
资源对比
The text was updated successfully, but these errors were encountered: