缺乏全局时钟
在单机系统中，程序以这个单机中的时钟为准，控制时序比较容易，在分布式系统中，每一个节点都有自己的时钟，在通过互相发送消息进行协调时，如果任然依赖时序，就会相对比较难处理，保持每一个节点的时钟完全一致可能是直觉上首先想到的办法，如果能够做到，那么一些分布式系统中的工程将会变得简单很多。
不过这个方式本身并没有办法实现，因为同步本身就存在时间差，因此我们需要有其他办法来解决这个问题，很多时候我们使用时钟，它可以区分两个动作顺序，而不是一定要知道准确的时钟，对于这种情况，我们可以把这个工作交给一个单独的集群来完成，通过这个集群来区分多个动作的顺序。
面对故障独立性
分布式系统由多个节点组成，整个分布式系统完全出问题的概率是存在的，但是咋实践中出现更多的是某个或者某些节点有问题，而其他节点及网络设备等都没有问题。这种情况提醒我们在开发的时候对问题的考虑要更加全面。
对于单机系统来说，我们如果不使用多进程的方式的话，基本不会遇到独立的故障，就是说在单机系统上的单进程程序，如果是机器问题、OS问题、或者程序自身的问题，基本的结果就是我们的程序整体不能用了，不会出现一些模块不行另外一些模块可以使用的情况。，另一些模块可以的情况我们称之为故障独立性。我们在实现分布式系统的时候，必须要找到应对和解决故障的独立性的办法。
处理单点故障
在整个分布式系统中，如果某个角色功能只有某台单机在支撑，那么这个节点称为单点，器发生的故障称为单点故障，也就是常说的SPoF(Single Point of Failure)。我们需要在分布式系统中尽量避免出现单点，尽量保证我们的功能都是由集群完成的，避免单点的关键就是把这个功能从单机实现变为集群实现，当然，这中变化一般会比较困难，否则就不会有太简单问题了，如果不能够把单机实现变为集群实现，那么一般还有另外的两种选择：
- 给这个单点做好备份，能够在出现问题时进行恢复，并且尽量做到自动恢复，降低恢复需要用的时间。
- 降低单点故障的影响范围。
那么如何降低单点故障的影响范围？
做法是：把原来的一个交易数据库拆分为两个（根据一定的规则做Sharding），那么，在单个数据库出现问题的时候，影响就不会是全部范围了，当且仅当这两台数据库同时发生故障的时候影响面就跟小了，需要多台机器同时出现问题才会出现严重故障，这个概率就比较低了，但是，一台数据库拆分到多台数据库后，出现故障的次数和总时间会比单台数据库的时候更多，也就是说： 我们增加了故障出现的次数和时间，降低了故障的影响面，从本质上来说，这种方式更多的是转移和交换，而没有真正的解决单点故障。
事务的挑战
在数据库理论中我们都了解富哦ACID，相对来说，单机的事务会容易很多，在分布式的环境中，如何解决事务问题也是一个重要的部分。
