考虑到实际应用中这类的消息并不需要很及时，
可以在正常发送给client的时候附带发送
比如每个Node有个ets表存储广播的消息，用户进程记录上次发送的广播ID,以此来对比是否有新的广播

现在的广播，是用 for each 的方式来发送，一个广播意味着 X 次 send 调用，这里的 X 等于用户数量。那么，是否有可能采用某种底层设施(比如说 driver)来执行广播，此时，只需要发送一条消息，其内容为：接收者列表＋消息内容，然后交由具体的底层设施来做实际的发送动作(X = 1)。此前 yufeng 提到 C 写的广播也只能做到 6-7w 。那么在发送性能上，两者的差别其实并不是太显著，所以，实际上已经失去了这么做的意义。

另外一个思路是通过多机集群来实现，比如，将每台单机的用户数量控制在一定的数量上(N)，由 M 台机器来实现整个集群。广播时，对每台机器只需发送一条消息(M条)，再由各自的机器分别对 N 个用户广播(X = M * N)。如此，应当可以实现对庞大用户数量的广播。但，如果 N 的值并不够大，在成本的考量上可能并不理想，此乃后话，另当别论。

是否还有其他的思路？不妨讨论讨论。

目前我在研究这些，有兴趣的同学一起来哦。

1, erl -smp disable 大有关系(我的古董机为单核，未涉及)。
2, 源码表明 binary > 256 会产生传引用的行为。
3, node 之间的 TCP 传递可以累积，一次发送多个包。

很有营养的认识。:D

把 broadcast 放到 driver 层面来做似乎是个靠谱的想法。然而，以 yufeng 之前的实践经验来看，单机 6w-7w/s 的广播性能，与之前根据 erlang 发包效能所做的性能推测(50K-60K/s)，似乎并没有我想象中的那么高(我的意思是，比如说，我原本以为会快上一两个数量级之类的)。这是否说明：

1，Erlang 的发送其实效率已经非常高，在 for each 的方式下，与底层 driver 方案之间的性能差异已经差别不大(至少不会有一个数量级之类的差异)？
2，现有 for each 的发送方式，无论是在 Erlang 里做还是在 driver 里做，其极限恐怕也差不多就是这么多了？(当然，大小为 1K 的数据包，要在 1s 以内广播给 50K-60K 的客户端，这本身也是一种极端场景)

根据 Erlang 的公平调度原则来推论，这确实很容易导致大面积的延迟(比如，在广播数量大于某个值之后，平均延迟会与之呈现出类似指数曲线的相关性)。

我现在很好奇，除了 driver 层方案(外包给更高效率的底层代码)之外，还有什么方式可供考虑呢？

http://blog.javaeye.com