java 分布式

这篇具有很好参考价值的文章主要介绍了java 分布式。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一:分布式

        分布式是一种架构模式,是将公有模块进行提取,构建成单独的模块,部署在不同服务器上进行调用。分布式系统一定是由多个节点组成的系统(这些节点一般不是孤立的,而是互通的);节点之间相互的操作会有协同。

特点:

        1.增大系统容量

        2.加强系统可用

        3.系统模块重用度高

        4.模块被拆分,开发和发布速度可以并行而变得更快

        5.系统扩展性更高

类型:

        1.分布式处理,但只有一个总数据库,没有局部数据库

        2.分层式处理,每一层都有自己的数据库

        3.充分分散的分布式网络,没有中央控制部分,各节点之间的联系方式又可以有多种

二、分布式理论

CAP理论

        CAP理论:又称为布鲁尔定理;CAP是一致性、可用性、分区容错性的首字母组合;CAP定理指出对于一个分布式系统来说需满足以下三点中的两点(分区容错性一定要满足,一致性和可用性二选一):

        一致性:所有节点访问同一份最新的数据副本

        可用性:非故障的节点在合理的时间内返回合理的响应

        分区容错性:分布式系统出现网络分区的时候,仍然能够对外提供服务

网络分区:分布式系统中,多个节点之前的网络本来是连通的,但是因为某些故障(比如部分节点网络出了问题)某些节点之间不连通了,整个网络就分成了几块区域。

总结:

        1.在系统发生“分区”的情况下,CAP 理论只能满足 CP 或者 AP。要注意的是,这里的前提是系统发生了“分区”

        2.如果系统没有发生“分区”的话,节点间的网络连接通信正常的话,也就不存在 P 了。这个时候,我们就可以同时保证 C 和 A 了

        3.如果系统发生“分区”,我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话,我们要思考如何保证 CA

BASE理论

        BASE:基本可用、软状态、最终一致性的缩写;BASE理论是对CAP中的一致性C和可用性A权衡的结果是基于 CAP 定理逐步演化而来的,它大大降低了我们对系统的要求。

        核心思想:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采取适当的方式来使系统达到强一致性(也就是牺牲数据的一致性来满足系统的高可用性,系统中一部分数据不可用或者不一致时,仍需要保持系统整体“主要可用”)。

        基本可用:指分布式系统在出现不可预知故障的时候,允许损失部分可用性。但是,这绝不等价于系统不可用。(响应时间上的损失、系统功能上的损失)

        软状态:软状态指允许系统中的数据存在中间状态(CAP 理论中的数据不一致),并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

        最终一致性:系统中所有的数据,在经过一段时间的同步后,最终能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

分布式一致性:

        强一致性 :系统写入了什么,读出来的就是什么

        弱一致性 :不一定可以读取到最新写入的值,也不保证多少时间之后读取到的数据是最新的,只是会尽量保证某个时刻达到数据一致的状态

        最终一致性 :弱一致性的升级版,系统会保证在一定时间内达到数据一致的状态

如何实现最终一致性:

        1.读时修复 : 在读取数据时,检测数据的不一致,进行修复

        2.写时修复 : 在写入数据,检测数据的不一致时,进行修复

        3.异步修复 (推荐): 这个是最常用的方式,通过定时对账检测副本数据的一致性,并修复

CAP 是分布式系统设计理论,BASE 是 CAP 理论中 AP 方案的延伸

三、分布式ID

ID:ID就是数据的唯一标识。

分布式ID:分布式系统下的 ID;如何为不同的数据节点生成全局唯一主键,这个时候就需要生成分布式 ID了。

分布式ID满足条件:

        1.全局唯一:ID 的全局唯一性肯定是首先要满足的

        2.高性能:分布式 ID 的生成速度要快,对本地资源消耗要小

        3.高可用:生成分布式 ID 的服务要保证可用性无限接近于 100%

        4.方便易用:拿来即用,使用方便,快速接入

分布式ID常见解决方案:

数据库:

        数据库主键自增:数据库的自增主键产生来唯一的 ID,新建占位字段,创建了唯一索引,保证其唯一性;插入时,如果主键或唯一索引字段出现重复数据错误而插入失败时,先从表中删除含有重复关键字值的冲突行,然后再次尝试把数据插入到表中

                优点:实现起来比较简单、ID 有序递增、存储消耗空间小

                缺点:支持的并发量不大、每次获取 ID 都要访问一次数据库

        数据库号段模式:批量获取ID,然后存在内存里面,需要用到的时候,直接从内存里面拿;基于数据库的号段模式来生成分布式 ID(数据库的访问次数更少,数据库压力更小);

                优点:ID 有序递增、存储消耗空间小

                缺点:存在数据库单点问题、ID 没有具体业务含义

        redis:利用命令即可实现对 id 原子顺序递增

算法:

        UUID:包含 32 个 16 进制数字,生成简单

                优点:生成速度比较快、简单易用

                缺点:存储消耗空间大、无序

        雪花算法:生成64 bit的二进制被分成了几部分,每一部分存储的数据都有特定的含义(第 1~41 位 :一共 41 位,用来表示时间戳;第 42~52 位 :一共 10 位,一般来说,前 5 位表示机房 ID,后 5 位表示机器 ID;第 53~64 位 :一共 12 位,用来表示序列号)

                优点 :生成速度比较快、生成的 ID 有序递增、比较灵活

                优点 :生成速度比较快、生成的 ID 有序递增、比较灵活

开源框架:

        百度:基于雪花算法进行了改进,生成ID的组成不一样;

        美团:基于雪花算法和号段模式

        滴滴:基于数据库号段模式的唯一 ID 生成器

四、分布式锁

分布式锁,分布式系统中的锁;为了解决分布式系统中控制资源共享访问的问题。

具备条件:

        1.互斥:任意一个时刻,锁只能被一个线程持有

        2.高可用:释放锁的代码逻辑出现问题,锁最终一定还是会被释放,不会影响其他线程对共享资源的访问

        3.可重入:一个节点获得锁之后,还可以再次获得锁

实现方式:

基于数据库的分布式锁

        1.基于数据库表的增删:先创建一张锁的表,当需要锁住某个方法时,往该表中插入一条相关的记录,如果有多个请求同时提交到数据库的话,数据库会保证只有一个操作可以成功,那么我们就认为操作成功的那个线程获得了该方法的锁,可以执行方法体内容。执行完毕之后,需要delete该记录

        2.基于数据库的排它锁:数据库在查询过程中给数据库表增加排他锁。获得排它锁的线程即可获得分布式锁,当获得锁之后,可以执行方法的业务逻辑,执行完方法之后,释放锁。当某条记录被加上排他锁之后,其他线程无法获取排他锁并被阻塞。

redis实现分布式锁

        1.基于set命令的分布式锁:

        2.基于setnx、get、getset的分布式锁

        3.基于RedLock的分布式锁

        4.基于Redisson看门狗的分布式锁

zookeeper实现分布式锁

        基于zookeeper临时有序节点可以实现的分布式锁。每个客户端对某个方法加锁时,在zookeeper上的与该方法对应的指定节点的目录下,生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单,只需要判断有序节点中序号最小的一个。 当释放锁的时候,只需将这个瞬时节点删除即可。

五、分布式事务

分布式事务是指在分布式系统中实现事务,它其实是由多个本地事务组合而成;分布式事务而言几乎满足不了 ACID。

分布式事务方案:

1.2PC/3PC

2PC:二阶段提交。 二阶段提交是一种强一致性设计,2PC 引入一个事务协调者的角色来协调管理各参与者的提交和回滚,二阶段分别指的是准备和提交两个阶段:

        准备阶段:协调者会给各参与者发送准备命令,做完提交事务之外的所有事情

        提交阶段:提交或回滚事务

3PC: 是为了解决 2PC 的一些问题,相比于 2PC 它在参与者中也引入了超时机制,并且新增了一个阶段使得参与者可以利用这一个阶段统一各自的状态(预提交阶段);

不管哪一个阶段有参与者返回失败都会宣布事务失败;

思想:先试探性的执行,如果都可以那就真正的执行,如果不行就回滚

2.本地消息表

本地消息表:利用了各系统本地的事务来实现分布式事务;

        会有一张存放本地消息的表,一般都是放在数据库中,然后在执行业务的时候 将业务的执行和将消息放入消息表中的操作放在同一个事务中,这样就能保证消息放入本地表中业务肯定是执行成功的。

本地消息表其实实现的是最终一致性,容忍了数据暂时不一致的情况

3.事务消息

事务消息是通过消息中间件来解耦本地消息表和业务数据表,适用于所有对数据最终一致性需求的场景。现在支持事务消息的消息中间件只有RocketMQ,这个概念最早也是RocketMQ提出的。

流程:发起方发送半事务消息会给RocketMQ,发起方进行本地事务操作,后确认提交消息,此时接受方可以消费到此消息了。

4.TCC

TCC 是业务层面的分布式事务;(预留-确认操作-撤销操作);都是先试探性的执行,如果都可以那就真正的执行,如果不行就回滚;

        比如说一个事务要执行A、B、C三个操作,那么先对三个操作执行预留动作。如果都预留成功了那么就执行确认操作,如果有一个预留失败那就都执行撤销动作。

TCC可以跨数据库、跨不同的业务系统来实现事务

5.Saga

Saga事务模型又叫做长时间运行的事务;

        核心思想就是拆分分布式系统中的长事务为多个短事务,或者叫多个本地事务,然后由 Saga工作流引擎负责协调,如果整个流程正常结束,那么就算是业务成功完成,如果在这过程中实现失败,那么Saga工作流引擎就会以相反的顺序调用补偿操作,重新进行业务回滚。 

6.Seate

Seata是一个由阿里做背书的分布式事务框架,致力于提供高性能和简单易用的分布式事务服务。

        特点是对业务无入侵,用户只需关注自己的“业务 SQL”,用户的 “业务 SQL” 作为一阶段,Seata 框架会自动生成事务的二阶段提交和回滚操作。

特点是对业务无入侵,用户只需关注自己的“业务 SQL”,用户的 “业务 SQL” 作为一阶段,Seata 框架会自动生成事务的二阶段提交和回滚操作文章来源地址https://www.toymoban.com/news/detail-416521.html

到了这里,关于java 分布式的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 一种基于springboot、redis的分布式任务引擎的实现(一)

     总体思路是,主节点接收到任务请求,将根据任务情况拆分成多个任务块,将任务块标识的主键放入redis。发送redis消息,等待其他节点运行完毕,结束处理。接收到信息的节点注册本节点信息到redis、开启多线程、获取任务块、执行任务、结束处理。 1、主节点接收任务请求

    2024年02月11日
    浏览(39)
  • 【分布式】分布式存储架构

    说到分布式存储,我们先来看一下传统的存储是怎么个样子。 传统的存储也称为集中式存储, 从概念上可以看出来是具有集中性的,也就是整个存储是集中在一个系统中的,但集中式存储并不是一个单独的设备,是集中在一套系统当中的多个设备,比如下图中的 EMC 存储就需

    2024年02月10日
    浏览(52)
  • 分布式爬虫架构-对等分布式(2)

    前言 本文是该专栏的第45篇,后面会持续分享python爬虫干货知识,记得关注。 在面对海量数据的采集需求时,使用分布式爬虫是非常有必要的。继上一篇,详细介绍主从分布式爬虫架构,对主从分布式相关知识感兴趣的同学,可往前翻阅。而本文,笔者再单独来详细介绍分布

    2023年04月25日
    浏览(55)
  • 分布式系统架构设计之分布式缓存技术选型

    随着互联网业务的快速发展,分布式系统已经成为了解决大规模并发请求、高可用性、可扩展性等问题的重要手段。在分布式系统中,缓存作为提高系统性能的关键技术,能够显著降低数据库负载、减少网络延迟、提高数据访问速度。当面对大量并发请求时,如果每次都直接

    2024年02月03日
    浏览(117)
  • 分布式软件架构——分布式事务TCC和SAGA

    TCC 是另一种常见的分布式事务机制,它是“ Try-Confirm-Cancel ”三个单词的缩写,是由数据库专家 Pat Helland 在 2007 年撰写的论文《Life beyond Distributed Transactions: An Apostate’s Opinion》中提出。 前面介绍的可靠消息队列虽然能保证最终的结果是相对可靠的,过程也足够简单(相对于

    2024年02月12日
    浏览(44)
  • 【系统架构】分布式系统架构设计

    分布式系统是指由多个计算机节点组成的一个系统,这些节点通过网络互相连接,并协同工作完成某个任务。 与单个计算机相比,分布式系统具有更高的可扩展性、可靠性和性能等优势,因此广泛应用于大规模数据处理、高并发访问、分布式存储等领域。 分布式系统的设计

    2024年02月15日
    浏览(55)
  • 聊聊分布式架构09——分布式中的一致性协议

    目录 01从集中式到分布式 系统特点 集中式特点 分布式特点 事务处理差异 02一致性协议与Paxos算法 2PC(Two-Phase Commit) 阶段一:提交事务请求 阶段二:执行事务提交 优缺点 3PC(Three-Phase Commit) 阶段一:CanCommit 阶段二:PreCommit 阶段三:doCommit 优缺点 Paxos算法 拜占庭将军问题

    2024年02月08日
    浏览(51)
  • 分布式系统架构设计之分布式数据存储的扩展方式、主从复制以及分布式一致性

    在分布式系统中,数据存储的扩展是为了适应业务的增长和提高系统的性能。分为水平扩展和垂直扩展两种方式,这两种方式在架构设计和应用场景上有着不同的优势和局限性。 水平扩展是通过增加节点或服务器的数量来扩大整个系统的容量和性能。在数据存储领域,水平扩

    2024年02月03日
    浏览(76)
  • 单机架构到分布式架构的演变

    目录 1.单机架构 2.应用数据分离架构 3.应用服务集群架构 4.读写分离 / 主从分离架构 5.引入缓存 —— 冷热分离架构 6.垂直分库 7.业务拆分 —— 微服务 8.容器化引入——容器编排架构 总结          初期,我们需要利用我们精干的技术团队,快速将业务系统投入市场进行

    2024年02月04日
    浏览(46)
  • 分布式系统架构1

    目前比较成熟的分布式架构技术包括: J2EE, CORBA 和 .NET (本书于 2020.05 出版), 书重点讲述 J2EE, 一个由 Sun 公司推出的一项中间件技术 (或平台). 用于 简化 和 规范 多层分布式 企业 应用系统开发和部署 特点: 具有分布式的体系: 组件与服务器环境无关, 无需担心组件和资源的分布

    2024年01月22日
    浏览(61)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包