所以我喜欢 beanstalkd：小、轻量级、优先处理消息、拥有大量客户端、易于使用。
我不喜欢 beanstalkd 的地方：如果您可以连接到端口，则缺少身份验证，您可以将消息插入其中。
所以我的想法是要么将它防火墙到受信任的系统（这是一个痛苦的维护并且在应用程序外部添加另一层要做的事情）或者使用像stunnel之类的东西将它包装在 TLS/SSL 中（这将产生一个很好的块建立连接和诸如此类的开销）。我确实想过可能会签署作业（作业字符串的MD5或SHA+时间值+附加到作业的秘密），但如果攻击者用虚假作业淹没服务器，我仍然会遇到麻烦。谁能想到任何其他方法来保护 beantalkd 免受攻击者插入虚假消息的影响？尤其是那些在计算或管理上不会产生大量开销的。
我不得不不同意无限期保持连接打开的做法，因为我使用 Web 脚本语言 (php) 中的 BeanstalkD 来处理各种事件。打开安全连接的开销将是我必须非常仔细考虑的事情。
与 Memcached 一样，beantalkd 是为在受信任的环境中使用而设计的——在防火墙后面。如果您不控制整个专用网络，那么限制对一组机器的访问（通过 IP 地址）将是控制它的典型方法。放入安全哈希然后丢弃无效作业并不困难，并且几乎不需要检查工作或开销，但不会阻止大量作业被发送。
要问的问题是“您的计算机可能被添加到的频率（在给定范围之外的随机 IP 地址），以及也在本地网络上的第三方希望向您的计算机注入随机作业的可能性有多大队列？第一部分是关于关闭机器的防火墙需要做多少工作，后者是关于你是否需要这样做？
这个问题确实属于beanstalkd 谈话清单。
出于类似的原因，我最近向 memcached 添加了 SASL 支持。开销在实践中几乎无关紧要，因为您仅在连接时进行身份验证（并且您无限期地保持连接打开）。
如果您需要身份验证，我建议您将其带到人们可能会帮助您解决问题的地方。
我做了两件事来减少您提到的问题：
First I always run beanstalkd on 127.0.0.1
Second, I normally serialize the job structure, and load a "secret key" encrypted base64 digest as the job string. Only workers that can decrypt the job string correctly can parse jobs.
I know that this is certainly not a substitute for authentication. But I hope they do minimize to some extent some one hijacking enqueued jobs.