我特别想知道，芹菜"broker"和海带"transport"之间是否存在1：1的关系？
假设直接关系，芹菜“经纪人”对“监视”和“远程控制”的支持与海带“运输”之间是否也存在直接关系？
换一种说法，是每个Kombu都“传输”有效的Celery“经纪人”，我如何仅通过代码检查来判断Celery“经纪人”是否支持“监控”和/或“远程控制” 甚至通过PDB。
我已经阅读了文档，但是当我发现this article using the filesystem Kombu transport for Celery时变得可疑。当我看到自2016年以来从未更新过受支持经纪人的名单时，这种怀疑就更加深了。
我还发现this stackoverflow question: "celery monitoring with sqs broker"是最近的，似乎严重依赖于可能已经过时的文档。
转向代码检查，我在Celery中找不到可以实现或切换监视或远程控制的任何Kombu Transport 代码，这些术语似乎未出现在{{3} }。
此外，Kombu似乎在将传输与Celery封装在一起并实现虚拟传输以支持这些传输原本不支持的功能方面做得非常好。我想知道这种巧妙的封装是否实质上使Celery关于经纪人支持的文档过时了，而对于Celery来说，一种传输方式与另一种传输方式一样好（除了性能之外）。
我还对Celery的变更说明和Github Issues进行了高级别的扫描，也没有出现在我身上。
至少在我们尝试使用内存或文件系统代理（如果可以使用这样的传输方式）时，在评估Celery时非常有利。如果可行，在我们使用Celery的同时还测试其监视和远程控制功能将很有趣。
我们当前将SQS用于消息队列，我非常想使用Celery封装以摆脱SQS，从而为我们提供了更多的自由度和可测试性。很高兴知道SQS经纪人是否支持超过所记录的范围。
我的下一步将是尝试并查看，但是我非常想了解引擎盖下面发生了什么，无论以上方法是否有效。
感谢您的帮助！
答案 0 :(得分：-1)
我相信每一个Kombu的“运输”都是有效的经纪人选择。
但是，正如您已经提到的，它们（传输）并不支持所有功能（监视，远程控制）。因此，即使我非常愿意使用SQS，我也不会使用它。我希望可以将AWS AMQ与Celery一起使用。