前言
什么是分布式系统?关于这点其实并没有明确且统一的定义。在我看来,只要一个系统满足以下几点就可以称之为分布式系统
系统由物理上不同分布的多个机器节点组成
系统的多个节点通过网络进行通信,协调彼此之间的工作。
系统作为整体统一对外提供服务,其分布式细节对客户端透明。
要想更好的理解分布式系统,并正确使用甚至构建分布式系统,需要理解其中的两个关键概念——分布式系统的数据一致性和分布式系统的幂等性。
1. 分布式系统的数据一致性对于分布式系统,数据可能存在于不同的物理节点上,节点之间只能通过网络进行通信来协调彼此之间的状态,而网络通信需要时间并且其本身并不十分可靠,因而如何保持数据一致性成为了分布式系统的难题。对于不同的分布式系统,其一致性语义以及面对的一致性难题可能略有差别
1.1 分布式存储系统中的一致性问题在分布式存储系统中,为了保持系统的高可用,同时增加读操作的并发性,同一份数据会有多份副本,不同的副本存储于不同的节点上,如下图所示
在并发环境下,因为存在多个客户端同时读取同一数据在不同节点上的副本,因而如何维护数据的一致性视图就非常重要,即对于使用该分布式系统的客户端而言,对于多副本数据的读写其表现应该和单份数据一样,通常系统是通过数据复制的方式来达到这一点的,
客户端将节点1中的副本A修改为10,系统将通过网络通信的方式将节点2和节点3中的副本A也更新为10。然而网络通信是需要时间的,假设在系统还未将节点1中的A值同步到节点2和节点3,此时另一个客户端访问了节点2和节点3,这个时候系统怎么办？
甚至,考虑更极端的场景,节点之间的网络被断开,不同节点无法感知到彼此的存在,当然也就无法保持多副本数据的同一视图,那么这个时候系统又该怎么办？
1.2 微服务应用的分布式一致性问题微服务架构下,原有的单体应用按功能被拆分成一个个微服务应用,每个微服务应用被部署在不同的机器节点上,只完成原有单体应用的某一部分功能,操作属于该业务功能的数据库或表。彼此之前通过网络通信的方式协调彼此之间的工作,作为整体共同对外提供服务,因而一个业务功能的实现,可能会涉及到多个微服务的调用,操作物理上不同的多个数据库或表。比如对于下单并支付这个业务功能而言,需要调用下单微服务和支付微服务来共同完成。
对于下单并支付这一业务功能,应用先调用订单微服务,在订单数据库中添加一条订单记录,成功后再调用支付微服务添加相应的支付记录,只有这两个微服务都调用成功,该业务功能才算执行成功。这个过程可能存在以下的问题:
订单微服务调用成功,订单记录已落地,但是支付微服务由于各种原因迟迟得不到响应,此时用户通过订单号查询只能查到订单记录而查不到支付记录,这对于已经成功付款的用户而言肯定是无法接受的,这种情况该怎么办？
订单微服务调用成功,订单记录已落地,但是支付微服务调用失败,此时订单记录和支付记录所对应的业务状态不一致,这时候系统该怎么办?
1.3 对于一致性的正确理解分布式存储系统的一致性问题,主要在于如何维持多副本的一致性视图上,即如何使多份数据对外表现的和一份数据一样。而微服务架构下的分布式应用系统,其一致性问题主要在于如何使不同微服务的数据对同一业务状态的描述保持一致,比如对于下单并支付这一业务操作而言,下单和支付要么同时成功,要么应该同时失败,而不应该一个成功一个失败,并且在这个过程中,某部分已经成功或失败的数据是否应该对客户端可见。在联系一下本地事务ACID中的一致性,我们可能会产生一定的混乱:它们讲的一致性是一个东西吗？先说下我的个人理解:不管是ACID的一致性还是不同分布式系统中的一致性,它们本质上讲的是一件事:数据的一致性,在于正确的反应现实世界,对发生于现实世界的事情的正确描述。这就要求,一致性的数据至少要满足以下两个条件:
1.符合系统本身具有的约束条件,比如数据库中的数据要遵循主码,外码,check约束。