消息要不要必达?能做到必达吗?

akka说消息不需要必达,推理而来就是说发出的请求存储给定的数据到那些物理开关的消息不需要保证被那些物理开关收到了。现实世界就是这样的,99.999999999999999%到达就足够了。怎么保证这个99.999999999999%呢?用物理定律和时间来保证。我们认知到的物理定律表明如果发送这么大的电子流到那个物理开关它99.999999999999%会合起来,如果保证不了99.999999999999%的话那就弄一批这样的物理开关同时操作一批然后观察。用一排物理开关去保证那一件事情,可以把可靠性提高到无限接近100%。如果1个开关保证不了99.999999999999%的话就用100个开关来保证,只要有超过50个开关合起来了就认为是合起来了,如果一个开关能够做到99.99的话,那么100个中超过50个开关都合起来的几率是非常接近100%的。物理开关是啥?是一种具有可以观察出的0 1两种状态的时空单元。
技术框架只要保证0 1事务就行了,它只要确保开关按下去就按下去了弹起来就弹起来了,技术框架只需要确保能够检测出哪些物理设备坏掉了并将数据迁移到没坏的设备去就行了,只要确保应用层不需要考虑物理设备的健康状况这种事情就可以了。余下的事务都归应用系统来管。运行时框架应该是做到了这点的,它能确保var age = 30;要么赋值成功要么不成功。数据库负责的事务是数据存进去就是存进去了没存进去就是没存进去,它负责的事务不是业务系统中的业务事务。问题是现在有些数据库不负责“存进去了没存进去就是没存进去”这种保证了,人家之所以不负责就是因为这个事情更应该由业务系统去做。问题是现在有些数据库不负责“存进去了没存进去就是没存进去”这种保证了,人家之所以不负责就是因为这个事情更应该由业务系统去做。

消息可能做不到必达,但是可以做到到达后进行确认,然后基于这个确认做些可靠的工作,算是分布式系统的可靠性吧。

消息在网络之间丢失是分布式系统的固有问题,因此才有CAP定理的分区容错,也就是我们的软件设计应该对分区之间的消息丢失有容错功能,当然这种容错是以牺牲可用性和一致性中之一为代价。
[该贴被banq于2014-11-22 12:39修改过]