大数据所要面临的麻烦

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

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如果被调换了,该如何确认?这个就需要数据中心要保证相对的封闭性。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180123G0Z3Z600?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券