What’s particularly tricky about applying back-pressure to handle overload via synchronous calls is having to determine what the typical operation should be taking in terms of time, or rather, at what point the system should time out.
尤其棘手的是通过同步调用处理负荷的back-pressure:必须要给典型的操作定一个执行时间,更确定地说就是操作执行时间达到指定最大的timeout时间后,这个操作会无效.The best way to express the problem is that the first timer to be started will be at the edge of the system, but the critical operations will be happening deep within it.This means that the timer at the edge of the system will need to have a longer wait time that those within, unless you plan on having operations reported as timing out at the edge even though they succeeded internally.
An easy way out of this is to go for infinite timeouts. Pat Helland 9 has an interesting answer to this:
Some application developers may push for no timeout and argue it is OK to wait indefinitely. I typically propose they set the timeout to 30 years.
That, in turn, generates a response that I need to be reasonable and not silly. Why is 30 years sily but infinity is reasonable? I have yet to see a messaging application
that really wants to wait for an unbounded period of time. . .
This is, ultimately, a case-by-case issue. In many cases, it may be more practical to use a different mechanism for that flow control. 10
[9] Idempotence is Not a Medical Condition, April 14, 2012 [10] In Erlang, using the value infinity will avoid creating a timer, avoiding some resources. If you do use this, remember to at least have a well-defined timeout somewhere in the sequence of calls.
[注9]:Idempotence is Not a Medical Condition, April 14, 2012 [注10]: Erlang中使用infinity不会创建一个定时器,不会使用一些资源。如果你打算这样用,请不要忘记在一系列的call中有至少要有一个定义好的timeout时间。