分布式系统的难点

缺乏全局时钟

在单机系统中,程序以这个单机中的时钟为准,控制时序比较容易,在分布式系统中,每一个节点都有自己的时钟,在通过互相发送消息进行协调时,如果任然依赖时序,就会相对比较难处理,保持每一个节点的时钟完全一致可能是直觉上首先想到的办法,如果能够做到,那么一些分布式系统中的工程将会变得简单很多。

不过这个方式本身并没有办法实现,因为同步本身就存在时间差,因此我们需要有其他办法来解决这个问题,很多时候我们使用时钟,它可以区分两个动作顺序,而不是一定要知道准确的时钟,对于这种情况,我们可以把这个工作交给一个单独的集群来完成,通过这个集群来区分多个动作的顺序。

面对故障独立性

分布式系统由多个节点组成,整个分布式系统完全出问题的概率是存在的,但是咋实践中出现更多的是某个或者某些节点有问题,而其他节点及网络设备等都没有问题。这种情况提醒我们在开发的时候对问题的考虑要更加全面。

对于单机系统来说,我们如果不使用多进程的方式的话,基本不会遇到独立的故障,就是说在单机系统上的单进程程序,如果是机器问题、OS问题、或者程序自身的问题,基本的结果就是我们的程序整体不能用了,不会出现一些模块不行另外一些模块可以使用的情况。,另一些模块可以的情况我们称之为故障独立性。我们在实现分布式系统的时候,必须要找到应对和解决故障的独立性的办法。

处理单点故障

在整个分布式系统中,如果某个角色功能只有某台单机在支撑,那么这个节点称为单点,器发生的故障称为单点故障,也就是常说的SPoF(Single Point of Failure)。我们需要在分布式系统中尽量避免出现单点,尽量保证我们的功能都是由集群完成的,避免单点的关键就是把这个功能从单机实现变为集群实现,当然,这中变化一般会比较困难,否则就不会有太简单问题了,如果不能够把单机实现变为集群实现,那么一般还有另外的两种选择:

  • 给这个单点做好备份,能够在出现问题时进行恢复,并且尽量做到自动恢复,降低恢复需要用的时间。
  • 降低单点故障的影响范围。

那么如何降低单点故障的影响范围?
做法是:把原来的一个交易数据库拆分为两个(根据一定的规则做Sharding),那么,在单个数据库出现问题的时候,影响就不会是全部范围了,当且仅当这两台数据库同时发生故障的时候影响面就跟小了,需要多台机器同时出现问题才会出现严重故障,这个概率就比较低了,但是,一台数据库拆分到多台数据库后,出现故障的次数和总时间会比单台数据库的时候更多,也就是说: 我们增加了故障出现的次数和时间,降低了故障的影响面,从本质上来说,这种方式更多的是转移和交换,而没有真正的解决单点故障。

事务的挑战

在数据库理论中我们都了解富哦ACID,相对来说,单机的事务会容易很多,在分布式的环境中,如何解决事务问题也是一个重要的部分。

坚持原创技术分享,您的支持将鼓励我继续创作!