SDerlang项目有多成熟？

你有SD Erlang项目的经验吗？

似乎已经实现了许多有关通用网格优化的有趣概念,我只是好奇你们是否有人已经在生产中或至少在某个真实项目中使用过这些.

SD二郎回购

谢谢!

该项目已于一周前完成.SD Erlang背后的主要思想是减少Erlang节点维护的连接数,同时保持节点组的传递性和公共命名空间.我们使用的基准测试(Orbit,蚁群优化(ACO)和Instant Messenger)显示了非常有希望的结果.不幸的是,我们没有足够的人力资源来重构Sim-Diasca模拟引擎.所以,不,SD Erlang还没有在真正的应用程序中使用过.

目前,我们正在编写最后一份可交付成果,概述已取得的成果.它会出现在这里在几周内(D6.2).总的来说,我们对使用SD Erlang获得的结果感到满意,因此有计划继续进行后续项目,但目前正在进行中.

这不是一个直接的答案,但我会在嵌入式应用程序中使用SD-Erlang,它需要扩展到数百个节点(小型嵌入式CPU).从我所看到它准备好在实际应用程序中尝试.为了进行评估,我们可以考虑替代方案:

你只有几个分布式节点:然后你可能不需要它,只能连接所有节点,并且对于名称注册表使用global模块(缓慢但坚固)或gproc使用新的locks_leader分支,这避免了gen_leader到目前为止完全破坏阻止gproc在生产中使用分布式模式.

您需要许多节点(多少取决于您的硬件和要求,但您开始进入有> 70个节点的有趣区域)

使用SD-Erlang并修复您在生产中遇到的任何问题,或者至少报告它们.它肯定解决了正常Erlang分发带来的许多问题

通过播放不同的COOKIE值或隐藏节点来滚动您自己的解决方案:提示您可以为不同的对等节点设置不同的COOKIE值.但是你需要推出自己的全局名称注册表和管理代码:看起来像是Greenspuns第10条规则的变体,或者更接近Erlang Virdings第一条规则:你可能会自己实现SD Erlang的一半.

根本不要使用Erlang发行版.这似乎是行业标准,对于涉及更多节点或跨越数据中心的任何事情,您根本不应该使用Erlang分发,而是运行您自己的协议.我个人的意见是宁愿修复Erlang Distributions问题而不是抛弃它.当它用于一个用例来放弃它时,它太有用了,节省了时间.我认为SD-Erlang是"太多节点"问题的解决方案,至少是正确的起点.