认识达内从这里开始

分布式系统随着互联网的不断发展而被越来越多的程序员掌握，而本文我们就通过案例分析来简单了解一下，分布式系统应用场景与优缺点分析。

1关于分布式系统

1.1介绍

我们常见的单体结构的集中式系统，一般整个项目就是一个独立的应用，所有的模块都聚合在一起。明显的弊端就是不易扩展、发布冗重、服务治理不好做。

所以我们把整个系统拆分成若干个具备独立运行能力的计算服务的集合，而从用户的角度看，是一个完整的系统，但实际上，它是一个分布式服务的集合。

分布式系统主要从以下几个方面进行裂变：

应用可以从业务领域拆分成多个module，每个module还可以再按项目结构分成接口层、业务层、数据访问层;当然也可以按访问入口进行拆分，如移动、桌面、Web端访问的是不同的类型接口服务;

数据库可以按业务类型拆分成多个实例，还可以对单库或单表进行分库分表;来保证分布式系统的高可用，如分布式缓存、搜索服务、文件服务、消息队列、非关系型数据库等中间件;

1.2优势和不足

分布式系统可以解决集中式不便扩展的弊端，提供了便捷的扩展性、独立的服务治理，并提高了安全可靠性。随着微服务技术(SpringCloud、Dubbo)以及容器技术(Kubernetes、Docker)的大热，分布式技术发展非常迅速。

不足的地方：分布式系统虽好，也带来了系统的复杂性，如分布式事务、分布式锁、分布式session、数据一致性等都是现在分布式系统中需要解决的难题，虽然已经有很多成熟的方案，但都不完美。

分布式系统的便利，其实是牺牲了一些开发、测试、运维成本的，让工作量增加了，所以分布式系统管理不好反而会变成一种负担。

2分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

分布式场景下一次完整的操作由不同的action组成，这些actions可能分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些action要么全部成功，要么全部失败。保证单个完整操作的原子性。

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2.1CAP理论

CAP定理(也称为Brewer定理)，指的是在分布式计算环境下，有3个核心的需求：

1、一致性(Consistency)：再分布，所有实例节点同一时间看到是相同的数据

2、可用性(Availability)：不管是否成功，确保每一个请求都能接收到响应

3、分区容错性(PartitionTolerance)：系统任意分区后，在网络故障时，仍能操作

CAP理论告诉我们，分布式系统不可能同时满足以下三种。多只能同时满足其中的两项，因为很多时候P是必须的,因此往往选择就在CP或者AP中

2.2CAP的组合情况

CA:放弃分区容错性。非分布式架构，比如关系数据库，因为没有分区，但是在分布式系统下，CA组合就不建议了。

AP:放弃强一致性。追求终一致性，类似的场景比如转账，可以接受两小时后到账，Eureka的注册也是类似的做法。

CP:放弃可用性。zookeeper在leader宕机后，选举期间是不提供服务的。类似的场景比如支付完成之后出订单，必须一进一出都完成才行。

结论：在分布式系统中AP运用的多，因为他放弃的是强一致性，追求的是终一致性，性价比高

2.3数据一致性模型

分布式系统通过同步数据的副本来提高系统的可靠性和容错性，而且数据的不同的副本，合理会存在不同的机器或集群上。

强一致性：

当用户的操作完成之后，会立马被同步到不同的数据副本中，后续其他任意请求都会获得更新过的值。这种对用户的可见性是友好的，能始终保证读到正确的值。根据CAP理论，这种实现需要牺牲可用性。

弱一致性：

系统并不保证所有请求的访问都会获得新值。数据写入成功之后，不承诺立即可以读，也不承诺具体多久之后可以读到，甚至读不到。在请求获得数据更新的这段时间，我i们称之为“不一致性窗口”。

终一致性：

是弱一致性的一种。系统保证在没有后续更新的前提下，系统终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。