Skip to content
New issue

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

消息通道优先级设计 #64

Open
dduo518 opened this issue Nov 12, 2022 · 0 comments
Open

消息通道优先级设计 #64

dduo518 opened this issue Nov 12, 2022 · 0 comments
Labels

Comments

@dduo518
Copy link
Owner

dduo518 commented Nov 12, 2022

在saas系统中消息队列优先级划分主要意义是提高吞吐,降低延时很有意义,从业务历史来看,主要是防止一个大的公司生成大量的消息阻塞消息通道,让其他公司的消息延时提高,当一个超大型公司在短时间内产生大量的推送消息造成长时间占用消息通道的时候,此时就应该将此公司等级动态降低优先级,无可厚非的提高消息时延。
所以,对于存在优先级的队列应实现如下:

  • 防止单一大公司单一业务把消息通道堵死,目标:拥堵发生不影响其他公司的消息通道
  • 防止恶意堵塞消息通道,操作不当或者故意造成大数量的消息
  • 随时动态扩容,调整队列优先级数量,调整数量区间
  • 随时清理拥塞中的消息
  • 消息通道分级无关公司规模或者版本,仅与公司正常的消息产生数量与速率(拥塞数量)有关
  • 消费端可以动态调整资源大小,对于保障型公司发生拥塞可以动态调整资源倾斜,非保障型公司消息时延与消息产生速率正相关。
  • 业务无感

流程

xvl1Ze32hej_CmTNkH_qaA

redis-queue_block_${company_id}:${queue_type}:

redis 记录消息数量,生产端+1,消费端-1,形成公司与队列类型维度的消息数量记录。

A: 判断当前公司,消息拥塞数量

根据公司业务类型消息拥塞数量进行选择队列优先级。此时就算单一公司单一业务出现积压,也不影响其他公司的其他业务,且不影响该公司的其他业务。

B: 判断是否是付费保障型公司

非保障型公司出现大数量消息积压时,可不对消费资源进行扩容,按照正常速度消费,此时积压造成的消息时延应该归类为客户操作不当引起。
对于保障型公司,可对消费资源进行合理的扩容,降低消息时延

C: 当前是否可丢弃消息

某家公司某单一业务出现大面积拥塞时,可随时清理积压的消息,快速消除积压数量,但是一般不使用,仅在出现恶意操作出现时。

queue

消息队列类型,根据业务进行合理的调整数量区间,根据平峰时期消费能力,推算合理区间范围,目标是可随时调整区间、优先级划分等级

资源对比

    1. 每个类型的队列都将增加多3种消息优先级,一共4条消息队列
    1. 增加了消息队列,势必增加消费端的资源,如果每个队列一个pod,将增加3个pod。
    1. redis 资源的消耗,最大key数量为:公司数*队列类型数量。
@dduo518 dduo518 added the 设计 label Nov 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant