您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
这篇文章将为大家详细讲解有关大数据分布式的简介及理论是怎样的，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
分布式系统：就是将一个业务拆分为多个业务，分布在不同的服务器节点，共同构建的系统叫做分布式系统。
分布式与集群的区别：分布式是多个人在一起做不同的事情；集群是多个人在一起做同样的事情。
分布式系统的特点：
分布性
对等性
并发性
缺乏全局时钟
1：单体应用架构->2：应用服务器与数据库服务器分离->3：应用服务器集群->4：应用服务器负载均衡->5：数据库读写分离->6：添加搜索引擎缓解数据库压力->7：添加缓存机制缓解数据库压力->8：数据库水平拆分、垂直拆分->9：应用拆分->10：服务化
分布式架构演进图示
由于网络本身的不可靠性，因此每次网络通信都会伴随网络不可用的风险，都会导致分布式系统无法顺利进行一次网络通信。
网络之间出现了网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域，分布式系统就会出现局部小集群。
节点故障是分布式系统下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象。
绝大部分情况下，网络通信能够接收到成功或失败的响应，但当网络出现异常的情况下，就会出现超时现象，通常有以下两种情况：
请求并没有被成功的发送到接收方，而是在发送过程就发生了丢失现象
请求成功的被接收方接收后，并进行了处理，但在响应反馈给发送方过程中，发生了消息丢失现象
分布式一致性：指的是数据在多份副本中存储时，各个副本中的数据是一致的。
副本一致性：分布式系统当中，数据往往会有多个副本，各个副本要保证数据的一致性就带来了同步的问题。
因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，一致性级别由此诞生：
用户更改了什么数据，读出来就是什么数据，对系统性能影响大。其实现方式常为加锁的方式，比如节点一的数据被更改，给其它节点上的该数据加锁，直到改变的数据同步成功再释放锁。
系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到最终一致性即可。
最终一致性：不考虑所有的中间状态的影响，只保证当没有新的更新之后，经过一段时间之后，最终系统内所有副本的数据是正确的。
例子：比如银行转账，A扣了钱后，经过很长时间，B收到钱。只要最终的状态是正确的就行，其它方面可以降低要求。
最终一致性根据更新数据后各进程访问到数据的时间和方式的不同包含下面的几种方式：
读写一致性：用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容。
例子：比如我们发一条朋友圈，朋友圈的内容是不是第一时间被朋友看见不重要，但是一定要显示在自己的列表上.
解决方案：
一些特定的内容我们每次都去主库读取。（主库压力大）
设置一个更新时间窗口，在刚刚更新的一段时间内，我们默认都从主库读取，过了这个窗口之后，再挑选最近有过更新的从库进行读取
直接记录用户更新的时间戳，在请求的时候把这个时间戳带上，凡是最后更新时间小于这个时间戳的从库都不予以响应。
单调读一致性：本次读到的数据不能比上次读到的旧。由于主从节点更新数据的时间不一致，导致用户在不停地刷新的时候，有时候能刷出来（请求到已经同步了的节点），再次刷新之后会发现数据不见了（又请求到了还未同步的节点），再刷新又可能再刷出来，就好像遇见灵异事件一样。
解决方案：就是根据用户ID计算一个hash值，再通过hash值映射到机器。同一个用户不管怎么刷新，都只会被映射到同一台机器上。
指的是：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后 的值。同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。
CAP 理论含义是，一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A: Availability）和分区容错 性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个。
C 一致性：分布式系统中所有的节点（或副本）数据一致（这里的一致性指的是强一致性）
目标：若数据写入主数据库成功, 则从数据库查询数据也成功，若数据写入主数据库失败,则向从数据库查询也失败
实现：主数据库写入数据后对从数据库加锁，直到从数据库同步成功再释放锁
分布式一致性的特点：
写操作会有一定的延迟，因为存在数据同步的过程
同步过程中会对资源暂时锁定
若数据同步失败，请求这个数据会返回失败信息，而不是旧数据
A 可用性：Reads and writes always succeed. 系统一直可用
目标：立即响应数据库查询请求（不考虑同步），不能出现响应超时或错误。
实现：写入数据到主数据库后，不考虑从数据库的数据是否已经同步了，在读取从数据库数据时直接返回数据即可，即使数据是旧数据也行。
P 分区容错性：在系统节点或网络分区故障时，仍然能够提供满足一致性和可用性的服务
目标：主数据库同步数据到从数据库即使失败，也不能影响写操作；其中一个节点挂掉不会影响另一个节点提供服务。
Partition tolerance（分区容错性）的实现：
使用异步的方式将主数据库的数据同步到从数据库
添加数据库节点，当中间的一个从节点挂掉时，由另一个从节点提供服务
舍弃A，瞒足CP（一致性和容错性）
一个系统保证了一致性和分区容错性，舍弃可用性。也就是说在极端情况下，允许出现系统无法访问的情况出现，这个 时候往往会牺牲用户体验，让用户保持等待，一直到系统数据一致了之后，再恢复服务。
舍弃C，满足AP（可用性及容错性）
大部分的分布式系统的设计，保证高可用和分区容错，但是会牺牲一致性。
舍弃P，满足CA（一致性及可用性）
如果要舍弃P，那么就是要舍弃分布式系统，CAP也就无从谈起了，回到了传统的单机服务了。
BASE理论：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个 短语的缩写；是对CAP理论的一个协调，对CAP理论中一致性及可用性权衡的结果，让CAP三种条件都达到不错的效果，而不用必须三选二。
BASE理论的意义在于：我们不必在A或C中做出选择，可以实现部分的A和C，是对 CAP 中 AP 的一个扩展。
BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性
Basically Available(基本可用)
当分布式系统在出现不可预知故障的时候，允许损失部分可用性——但不等价于系统完全不可用。
例如：出现故障时，使用搜索功能响应时间可以适当增加一二秒；双十一时，为了保护系统稳定性，会引导部分用户到一个降级页面。
Soft state（软状态）
软状态：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟。
例如：外卖配送状态，对用户来说有配送中状态。
Eventually consistent（最终一致性）
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。而不需要实时保证系统数据的强一致性。 例如：转账不会立即到账，会经过一段时间后数据同步成功，但最终一定会成功。
关于大数据分布式的简介及理论是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。