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

WIP: 延迟队列 #111

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
1 change: 1 addition & 0 deletions .CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,7 @@
- [atomicx: 泛型封装 atomic.Value](https://github.com/gotomicro/ekit/pull/101)
- [queue: API 定义](https://github.com/gotomicro/ekit/pull/109)
- [queue: 基于堆和切片的优先级队列](https://github.com/gotomicro/ekit/pull/110)
- [queue: 延时队列](https://github.com/gotomicro/ekit/pull/111)

# v0.0.4
- [slice: 重构 index 和 contains 的方法,直接调用对应Func 版本](https://github.com/gotomicro/ekit/pull/87)
Expand Down
169 changes: 169 additions & 0 deletions queue/delay_queue.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,169 @@
// Copyright 2021 gotomicro
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

package queue

import (
"context"
"sync"
"time"

"github.com/gotomicro/ekit/list"

"github.com/gotomicro/ekit/internal/queue"
)

type DelayQueue[T Delayable] struct {
q queue.PriorityQueue[T]
mutex sync.RWMutex

enqueueReqs *list.LinkedList[delayQueueReq]
dequeueReqs *list.LinkedList[delayQueueReq]
}

type delayQueueReq struct {
ch chan struct{}
}

func NewDelayQueue[T Delayable](c int) *DelayQueue[T] {
return &DelayQueue[T]{
q: *queue.NewPriorityQueue[T](c, func(src T, dst T) int {
srcDelay := src.Delay()
dstDelay := dst.Delay()
if srcDelay > dstDelay {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delay()内部依赖time.Until(deadline)系统调用,底层优先级队列需要维持内部不变性,每次操作需要在堆中比较O(logN)次,而每次比较又需要两次系统调用(src和dst).
当N=10时,每次操作最多要有3 * 2= 6次系统调用.
当N=100时,每次操作最多要有6 * 2 = 12次系统调用.

每次入队/出队时,因为调整堆结构而引入的至少两次额外的系统调用,是否可接受?是否会有性能问题?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

实际上 Delay 内部究竟依赖不依赖 time.Until 调用,这个是用户自己决定的。比如说如果他们能够做到 Delay 实现不调用,那就不调用。
我突然想到,要是我们这个接口改成返回 Deadline 呢?
对于用户来说,只需要计算一次 Deadline,我们优先级队列把 Deadline 比较大的放在后面

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

我觉得可以,其实我那个实现就是这么干的,Delayable接口名字我没改,将方法Delay改为了Deadline了。返回time.Time,这个问题就解决了。

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

=.= 我试了一下,用 deadline 的话,那么就是我们自己调用 time.Now,始终都是需要有人调用。

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

time.Now是一定要调用的,因为需要计算delay。但是在向底层堆插入/删除数据的时候即d.q.Enqueue/d.q.Dequeue就没有系统调用了(comparator内调用Deadline方法比较)。

return 1
}
if srcDelay == dstDelay {
return 0
}
return -1
}),
enqueueReqs: list.NewLinkedList[delayQueueReq](),
dequeueReqs: list.NewLinkedList[delayQueueReq](),
}
}

func (d *DelayQueue[T]) Enqueue(ctx context.Context, t T) error {
// 确保 ctx 没有过期
if ctx.Err() != nil {
return ctx.Err()
}
for {
d.mutex.Lock()
err := d.q.Enqueue(t)
if err == queue.ErrOutOfCapacity {
flycash marked this conversation as resolved.
Show resolved Hide resolved
ch := make(chan struct{}, 1)
_ = d.enqueueReqs.Append(delayQueueReq{ch: ch})
d.mutex.Unlock()
select {
case <-ctx.Done():
return ctx.Err()
case <-ch:
}
continue
}
if err == nil {
// 这里使用写锁,是为了在 Dequeue 那边
// 当一开始的 Peek 返回 queue.ErrEmptyQueue 的时候不会错过这个入队信号
flycash marked this conversation as resolved.
Show resolved Hide resolved
if d.dequeueReqs.Len() == 0 {
// 没人等。
d.mutex.Unlock()
return nil
}
req, err := d.dequeueReqs.Delete(0)
if err == nil {
// 唤醒出队的
req.ch <- struct{}{}
}
}
d.mutex.Unlock()
return err
}
}

func (d *DelayQueue[T]) Dequeue(ctx context.Context) (T, error) {
// 确保 ctx 没有过期
if ctx.Err() != nil {
var t T
return t, ctx.Err()
}
ticker := time.NewTicker(time.Second)
ticker.Stop()
defer func() {
ticker.Stop()
}()
for {
d.mutex.Lock()
head, err := d.q.Peek()
if err != nil && err != queue.ErrEmptyQueue {
var t T
return t, err
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return前需要解锁d.mutex.Unlock()

}
if err == queue.ErrEmptyQueue {
ch := make(chan struct{}, 1)
_ = d.dequeueReqs.Append(delayQueueReq{ch: ch})
d.mutex.Unlock()
select {
case <-ctx.Done():
var t T
return t, ctx.Err()
case <-ch:
}
continue
}

delay := head.Delay()
// 已经到期了
if delay <= 0 {
// 拿着锁,所以不然不可能返回 error
t, _ := d.q.Dequeue()
d.wakeEnqueue()
d.mutex.Unlock()
return t, nil
}

// 在进入 select 之前必须要释放锁
d.mutex.Unlock()
ticker.Reset(delay)
select {
case <-ctx.Done():
var t T
return t, ctx.Err()
case <-ticker.C:
var t T
d.mutex.Lock()
t, err = d.q.Dequeue()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. 不能直接d.q.Dequeue().
    假设queue= {10, 100}, G1和G2并发,Peek到10, G1等待前调用ticker.Reset(10)和G2等待前调用ticker.Reset(8)其中各自的delay是不同的但来自同一个head(10). 当G1先被唤醒,直接将10出队后.G2被唤醒后,原head(10)被G1拿走,而直接将新head(100)出队,此时head(100)的Delay()可能不为0. 所以出队前一定要判定head.Delay()<= 0
  2. 队头插队敏感性及过度延迟问题
    queue = {100}, G1和G2并发等待出队,此时G3 Enqueue(10),queue={10, 100}, 当G1/G2返回元素10时已经远远超出预计的截止日期, 因为G1和G2是按照元素100的delay在等待,G3 Enqueue(10)后并没有唤醒G1/G2重新等待新队头.

这里即便加入判断 head.Delay()<= 0再出队,仍会有插入高优先级元素后过度延迟出队的问题.

// 被人抢走了,理论上是不会出现这个可能的
if err != nil {
d.mutex.Unlock()
continue
}
d.wakeEnqueue()
d.mutex.Unlock()
return t, nil
}
}
}

func (d *DelayQueue[T]) wakeEnqueue() {
req, err := d.enqueueReqs.Delete(0)
if err == nil {
// 唤醒等待入队的
req.ch <- struct{}{}
}
}

type Delayable interface {
Delay() time.Duration
}