＆quot“ golang.org/x/time/rate＆quot;和上下文
在下面的示例中传递上下文wait（）函数的目的是什么？
假设有一个限制器每秒允许3个请求。
这是否意味着限制器将不是共享资源，因为对于每个“过程”函数调用，它将具有其自己的限制器实例和范围，对吗？ 如果不是这样？我该如何实现？
结构
type MyClass struct {
limiter *rate.Limiter
}
func NewMyClass() (*MyClass, error) {
return &MyClass{limiter: rate.NewLimiter(rate.Limit(3), 1)}, nil
}
func (m *MyClass) Process(ctx context.Context) error {
err := m.limiter.Wait(ctx)
if err != nil {
return err
}
//more code
}
示例
m, _ := s3Storage.NewMyClass()
ctx1 := context.TODO()
m.Process(ctx1)
m.Process(ctx1)
m.Process(ctx1)
ctx2 := context.TODO()
m.Process(ctx2)
What's the purpose of passing the context to Wait() function in the example below?
Let's say there is a limiter that allow 3 requests per second.
Does it mean that limiter will not be a shared resource in the sense that, for each "Process" function call, it will have it's own limiter instance and scope, is that right?
If it's not the case? How can I achieve it?
Struct
type MyClass struct {
limiter *rate.Limiter
}
func NewMyClass() (*MyClass, error) {
return &MyClass{limiter: rate.NewLimiter(rate.Limit(3), 1)}, nil
}
func (m *MyClass) Process(ctx context.Context) error {
err := m.limiter.Wait(ctx)
if err != nil {
return err
}
//more code
}
Example
m, _ := s3Storage.NewMyClass()
ctx1 := context.TODO()
m.Process(ctx1)
m.Process(ctx1)
m.Process(ctx1)
ctx2 := context.TODO()
m.Process(ctx2)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
上下文定义了呼叫的寿命，因此，如果上下文被取消，则等待呼叫也将被取消。例如，尝试使用非常小的超时将上下文从
context.todo（）context.withtime.withtime.withtime.withtime.withtime.withtime.code>更改。 官方文档在解释上下文背后的上下文和语义方面做得很好。The context defines the lifetime of the call, so if the context is cancelled, then the wait call will be cancelled as well. As an example, try changing the context from
context.TODO()tocontext.WithTimeout()with a very small timeout and observe the effect on the Wait() call. The official docs do a good job of explaining the context and semantics behindcontext.首先，您需要了解
RATE.LIMITER和context.Context类型的不同目的。限制器允许您控制执行并发过程的速率。上下文如果它们继续进行（例如超时，丢失的连接，用户cancellation ...），则允许终止一个过程或一组进程。这些都是简化的，因此请阅读DOCO以获取更多信息。回答您的问题：
没有目的，因为
todo上下文永远不会取消。不，它是共享的。您只有一个
myClass实例，该实例只有一个限制器。每个过程函数调用都没有限制器是没有意义的，因为一个调用永远不会超过3个限制。i
think 您想要多个不同的速率限制呼叫
Process < /code>，因此可能只需要多个实例myClass，每个实例都有其自己的限制器。我不确定您要做什么，但是作为典型使用率限制器的典型用途是限制用户或连接的过程数量。同样，上下文可能与单个连接上的所有过程相关联，因此，如果连接死亡，则所有内容都可以整齐地清理。因此，可能的情况是您拥有具有
limiter和上下文的Connection类型。我希望这是有道理的。
First, you need to understand the different purposes of the
rate.Limiterandcontext.Contexttypes. TheLimiterallows you to control the rate at which concurrent processes are executed. TheContextallows to terminate a process or group of processes if there is no point in them continuing (eg timeout, lost connection, user-cancellation...). These are simplifications so read the doco for more info.To answer your questions:
There is no purpose as the
TODOcontext is never cancelled.No, it is shared. You only have one
MyClassinstance which only has oneLimiter.There is no point in having a limiter on each Process function call, since one call will never exceed your limit of 3.
I think you want multiple different sets of rate-limited calls to
Process, and so probably just need multiple instances ofMyClass, each with it's ownLimiter.I'm not sure exactly what you are trying to do, but as an example a typical use of a rate limiter is to restrict the number of processes by user or by connection. Similarly, a context may be associated with all the processes attached to a single connection, so that if the connection dies everything can be neatly cleaned up. So a possible scenario is that you have a
Connectiontype that has aLimiterand aContext.I hope this makes sense.