How Do You Drop
Most of the solutions outlined here work based on message quantity, but it’s also possible to try and do it based on message size, or expected complexity, if you can predict it. When using a queue or stack buffer, instead of counting entries, all you may need to do is count their size or assign them a given load as a limit.
I’ve found that in practice, dropping without regard to the specifics of the message works rather well, but each application has its share of unique compromises that can be acceptable or not 25.
There are also cases where the data is sent to you in a "fire and forget" manner — the entire system is part of an asynchronous pipeline — and it proves difficult to provide feedback to the end-user about why some requests were dropped or are missing.
If you can reserve a special type of message that accumulates dropped responses and tells the user " N messages were dropped for reason X", that can, on its own, make the compromise far more acceptable to the user.
This is the choice that was made with Heroku’s logplex log routing system, which can spit out L10 errors, alerting the user that a part of the system can’t deal with all the volume right now.
In the end, what is acceptable or not to deal with overload tends to depend on the humans that use the system. It is often easier to bend the requirements a bit than develop new technology, but sometimes it is just not avoidable.
还有一些情况是是数据发给你，然后就不管了的("fire and forget") ---那整个系统都是异步管道(asynchronous pipeline)的一部分----这个就很难给终端用户反馈为什么有些请求会被丢弃或丢失掉。
 Old papers such as Hints for Computer System Designs by Butler W. Lampson recommend dropping
messages: "Shed load to control demand, rather than allowing the system to become overloaded." The
paper also mentions that "A system cannot be expected to function well if the demand for any resource
exceeds two-thirds of the capacity, unless the load can be characterized extremely well." adding that "The
only systems in which cleverness has worked are those with very well-known loads."
[注25] ： Butler W.Lampson写的 Hints for Computer System Designs 论文中建议:"宁愿控制负载，也不能让系统超负荷",论文还指出"一个系统如果被要求工作大于2/3的负载之上，就不可以被认为是正常工作的"，"聪明的系统都会工作在适当的负载下"。