您对SD Erlang项目有什么经验吗？
似乎已经实现了许多关于通用网格优化的有趣概念，我只是好奇，如果你们中的一些人已经在生产中或者至少在一些真实项目中使用过那些。
谢谢！
答案 0 :(得分：6)
该项目已于一周前完成。 SD Erlang背后的主要思想是减少Erlang节点维护的连接数，同时保持节点组的传递性和公共命名空间。我们使用的基准测试（Orbit，蚁群优化（ACO）和Instant Messenger）显示了非常有希望的结果。不幸的是，我们没有足够的人力资源来重构Sim-Diasca模拟引擎。所以，不，SD Erlang还没有在真正的应用程序中使用过。
目前，我们正在撰写最后一份可交付成果，概述已取得的成果。它将在几周内出现here（D6.2）。总的来说，我们对使用SD Erlang获得的结果感到满意，因此有计划继续进行后续项目，但目前正在进行中。
答案 1 :(得分：6)
这不是一个直接的答案，但我会在嵌入式应用程序中使用SD-Erlang，它需要扩展到数百个节点（小型嵌入式CPU）。从我所看到它准备好在实际应用程序中尝试。为了进行评估，我们可以考虑替代方案：
您只有几个分布式节点：那么您可能不需要它，只能连接所有节点，并且对于名称注册表使用global模块（缓慢但坚固）或{{ 1}}使用新的locks_leader branch，避免了迄今为止阻止在生产中使用gproc分布式模式的完全损坏的gen_leader。
您需要多个节点（多少取决于您的硬件和要求，但是您开始进入有> 70个节点的有趣区域）
使用SD-Erlang并修复您在制作中遇到的任何问题，或者至少报告它们。它肯定解决了正常Erlang分发所带来的许多问题
使用不同的cookie值或隐藏节点来推送自己的解决方案：提示您可以为不同的对等节点设置不同的cookie值。但是，您需要滚动自己的全局名称注册表和管理代码：看起来像Greenspuns 10th rule的变体或更接近Erlang Virdings 1st rule：您可能会自己实现SD Erlang的一半。
根本不要使用Erlang发行版。这似乎是行业标准，对于涉及更多节点或跨越数据中心的任何事情，您根本不应该使用Erlang分发，而是运行您自己的协议。我个人的意见是宁愿修复Erlang Distributions问题而不是抛弃它。当它用于一个用例来放弃它时，它太有用了，节省了时间。我认为SD-Erlang是“太多节点”问题的解决方案，至少是正确的起点。