大数据所要面临的麻烦

在计算机的发展当中，出现了两种选择，一个是超级计算机，另一个则是云架构。超级计算机看起来很美好，因为对于程序员而言，只要和平常一样当成单机系统处理就好，但是有如下几个原因，导致不能在商业应用。

1.在商业环境下，如果你的应用是线上的，那么必须保证可用性相当高。而超级计算机一旦宕机或者需要停机更新，一切都完了。

2.超级计算并不经济，因为你需要提供特别的硬件设备，特殊的网络带宽给超级计算机。

3.如果你的应用分布在各地，而你的超级计算机只有一台，那么意味着所有的请求必须承受网络延迟

于是云架构成为更为优秀的选择。但是云架构也面临着自己的问题，那就是不可靠的网络传输，集群间不可靠的时钟，甚至还有传输包的安全问题。

网络环境的复杂导致我们无法保证我们传输的信息会准时送到，甚至不会丢失。例如当A和B进行远程连接时，A发送了一条信息，这信息可能会丢失，可能没有及时送到，在传输过程中，B可能会挂掉，B也许只是暂时的没有回应，一会儿又好了。最后如果B处理好了这条信息，B的回应也有可能丢失，也有可能延迟。所以，我们能保证我们发送的信息是可靠的吗？

倘若网络是不可靠的，那么我们该如何检测呢？我们可以用timeout和重试去抽象这些问题，不过timeout的长短这个就靠经验了，因为过长的timeout意味着更长的等待时间，过短的timeout就必须承受更大的风险。在实践中，网络也会发生拥堵，这时TCP使用了流量控制的方法。

除了不靠谱的网络，我们还会面临时间的魔术。在前面的文章中，很多一致性的问题都来源于时间的作弄。一般意义上，时间有两种定义，一个是持续时间，一个是当前时间。计算机对于时间的同步，会使用NTP，当然更高大上的谷歌使用的是GPS。而这些无法确切的保证每台计算机的时间是同步的，比如计算机本身使用的quartz clock就不是很精确、计算机本身的时钟如果与NTP的时间相差过大，可能会拒绝同步、NTP也会受限于网络延迟、NTP的协调者也必须足够强大、时间本身也会产生泄露、如果你的应用部署在虚拟环境，虚拟和实际时间也需要时间同步。

除了时间本身不靠谱外，计算机应用自身也会出现问题。比如一般意义上的程序语言都会出现GC暂停，操作系统在进行上下文选择，应用和磁盘的IO消耗等等这些，这时，我们能认为计算机出现问题了吗？

我们在讨论上面的问题时，都默默假设每个机器接受的信息都是可靠的，真实的，然而分布式系统更需要注重安全问题，packet如果被调换了，该如何确认？这个就需要数据中心要保证相对的封闭性。