celluloid/dcell 学习8：同 DRb 的比较

原文地址：

Ruby 标准库中已经有了一个分布式对象系统：DRb，就是分布式 Ruby 的意思。DRb 出了啥问题？为什么我们需要一个新的系统？DRb 有一个主要的缺点：它先天就是基于同步的，你能对一个 object 做的唯一操作就是方法调用，流程就是给远端 object 发送一个消息，远端执行方法，然后返回本地一个响应。

而 DCell 使用了异步消息协议。异步消息机制允许你采用更多的消息处理模式，而不仅仅是 DRb 实现的 请求/响应这一种模式，这些模式包括：

• Broadcast： 广播模式。可以给所有 actors 发送消息而不用等待响应。
• Publish/Subscribe: 发布/订阅模式。actors 可以注册订阅一个主题 topic，然后其他的 actors 就可以给所有订阅者发布信息。
• Scatter/Gather： 分散/聚集模式（我觉得叫撒网模式比较贴切）。并行地发送消息给一堆 actors，然后将所有返回的有效数据收集到一起。
• Multicall/Quorum：不好翻译，我理解为一种多播/投票机制。对一堆 actors 发出调用，然后等待满足法定数目的响应。

补充参考（来自其他网站）：
Quorum 原指为了处理事务、拥有做出决定的权力而必须出席的众议员或参议员的数量（一般指半数以上）。
Quorom 机制，是一种分布式系统中常用的，用来保证数据冗余和最终一致性的投票算法，其主要数学思想来源于。
在分布式系统中，冗余数据是保证可靠性的手段，因此冗余数据的一致性维护就非常重要。一般而言，一个写操作必须要对所有的冗余数据都更新完成了，才能称为成功结束。比如一份数据在5台设备上有冗余，因为不知道读数据会落在哪一台设备上，那么一次写操作，必须5台设备都更新完成，写操作才能返回。

DCell 同样提供 Erlang 所倡导的错误容忍模式（fault-tolerance），即倾向于鼓励 actors 不做任何错误处理，一旦崩溃后只是简单地清除状态然后重启。Linking to actors on remote nodes can be used to detect these sorts of errors and have dependent actors restart in a clean state.

最终，DRb 需要你来保证作为 services 发布的 objects 是线程安全的，而 Celluloid 抽离出一系列的线程安全的原则，从而默认就可以保证你编写的 objects 是线程安全的。