分布式程序理解算法_第1页
分布式程序理解算法_第2页
分布式程序理解算法_第3页
分布式程序理解算法_第4页
分布式程序理解算法_第5页
已阅读5页,还剩20页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

22/24分布式程序理解算法第一部分分布式共识机制概况 2第二部分Paxos算法的核心思想 5第三部分Raft算法的投票表决机制 8第四部分Zab算法的事务处理机制 11第五部分Chubby算法的锁服务实现 13第六部分ZooKeeper算法的协调服务特性 15第七部分Kafka算法的消息发布订阅模型 18第八部分Flink算法的流式数据处理框架 22

第一部分分布式共识机制概况关键词关键要点一致性算法

1.拜占庭将军问题及其对分布式共识机制的启发。

2.基本一致性模型(Paxos、Raft等)的原理和优缺点。

3.可扩展性和高可用性的一致性算法(Zab、ViewstampedReplication等)。

容错机制

1.拜占庭容错与非拜占庭容错机制的区别。

2.容错机制的分类,如主从复制、状态机复制、链式复制等。

3.不同容错机制的适用场景和性能特点。

消息传递

1.分布式系统中的消息传递协议和机制。

2.单播、组播和广播的实现方式和效率比较。

3.可靠性和顺序性保证的消息传递机制。

成员管理

1.分布式系统中成员加入、退出和故障检测机制。

2.成员管理协议(如一致性算法)的作用和实现方式。

3.成员管理在高可用性和可扩展性方面的影响。

分布式事务

1.分布式事务的特征和对一致性的要求。

2.两阶段提交协议(2PC)及其在分布式事务中的应用。

3.分布式事务的替代方案,如补偿事务(Saga)和事件驱动的架构。

趋势与前沿

1.分布式共识机制在云计算和区块链领域的应用和发展趋势。

2.分布式共识算法的可扩展性、效率和安全性的优化方向。

3.基于区块链的分布式共识机制的潜力和挑战。分布式共识机制概况

定义

分布式共识机制是一种算法,它允许一组分布式节点在没有中心协调器的情况下就公共状态达成一致。

分类

分布式共识机制可根据其容错能力进行分类:

*拜占庭容错(BFT):可容忍任意数量的恶意节点

*非拜占庭容错(NBFT):只能容忍少量恶意节点

主要机制

#区块链共识机制

*工作量证明(PoW):矿工通过解决复杂计算难题来创建新块。

*权益证明(PoS):节点根据其持有的代币数量来验证交易。

*委托权益证明(DPoS):节点由代币持有者选举,然后负责验证交易。

#复制状态机共识机制

*Raft:基于领导者选举的共识算法。

*Paxos:基于提案和接受的共识算法。

*ZAB:ZooKeeper中使用的共识算法。

#协商一致机制

*2PC(两阶段提交):事务性应用程序中使用的共识算法。

*3PC(三阶段提交):2PC的扩展,用于更复杂的分布式系统。

*OCC(乐观并发控制):允许并发执行事务,并在冲突发生时回滚。

优点

*容错性:分布式共识机制通过允许少数节点故障而保持可用性。

*去中心化:它们不需要中心协调器,这提高了系统的安全性。

*数据一致性:它们确保在所有节点上维护共同的状态。

缺点

*性能:一些共识机制可能需要大量计算资源,从而影响性能。

*延迟:在达成共识之前,交易必须等待一段时间。

*可扩展性:某些共识机制很难扩展到大型分布式系统。

应用

分布式共识机制广泛应用于以下领域:

*区块链技术

*分布式数据库

*分布式系统

*云计算

选择标准

选择分布式共识机制时,需要考虑以下因素:

*容错需求

*性能要求

*可扩展性需求

*安全要求

研究趋势

分布式共识机制的研究是活跃的,当前正在研究的领域包括:

*提高容错性

*提高性能

*降低延迟

*提高可扩展性

*新型的共识机制第二部分Paxos算法的核心思想关键词关键要点共识问题

1.分布式系统中,多个节点需要就某一状态达成一致。

2.共识问题难以解决,因为节点可能故障、网络延迟或受到恶意攻击。

3.Paxos算法的核心思想就是解决共识问题,保证分布式系统中不同节点在状态上的一致性。

提案者角色

1.Paxos算法中引入提案者角色,负责提出值并协调共识过程。

2.提案者提出一个唯一的提案号,用于标识提案。

3.提案者负责收集来自参与者节点的回复,并最终确定被接受的值。

参与者角色

1.Paxos算法中参与者负责处理来自提案者的提案。

2.参与者可以处于不同的状态,包括准备状态和接受状态。

3.参与者在达成共识之前,必须经过一个故障容忍的协调过程。

值传播

1.Paxos算法通过提案者和参与者之间的消息传递来传播值。

2.提案者将提案发送给所有参与者,等待他们的回复。

3.参与者在接受一个值后,将该值传播给其他参与者,确保所有参与者最终都接收到相同的值。

故障处理

1.Paxos算法能够处理节点故障、网络延迟和恶意攻击。

2.故障处理机制包括提案者超时、参与者仲裁和状态恢复。

3.故障处理机制确保即使在故障的情况下,也能最终达成共识。

实用性

1.Paxos算法在现实世界的分布式系统中得到了广泛应用。

2.该算法提供了高可用性、容错性和可扩展性。

3.Paxos算法的变体已被用于各种分布式系统,包括分布式数据库、分布式锁服务和分布式文件系统。Paxos算法的核心思想

Paxos算法是一种分布式共识算法,旨在解决分布式系统中因节点故障或网络分区导致数据不一致的问题。算法核心思想如下:

1.状态机复制

Paxos算法基于状态机复制模型,将分布式系统视为一个状态机,该状态机由一系列命令构成,每个命令应用于当前状态后都会产生新的状态。在分布式系统中,每个节点都维护着一个独立的副本,称之为副本状态机。

2.三阶段协议

Paxos算法的核心是一个三阶段协议,包括:

*提案阶段:提案者向大多数节点(定额组)发送一个提议值。

*接受阶段:节点在提案阶段接受提议值,或拒绝接受。

*学习阶段:节点在接受阶段接受提议值后,向所有其他节点广播该值,使其成为系统中所有副本状态机的当前值。

3.协调角色

Paxos算法中存在三个协调角色:

*提案者:发起提案阶段,选择提议值。

*接受者:在提案阶段接收提案,并在后续阶段参与值的选择和复制。

*学习者:在学习阶段接收提议值,并将其更新至自己的副本状态机中。

4.多数机制

Paxos算法的核心是多数机制,即任何提议值都需要获得大多数节点的接受才能被系统接受。决定大多数的关键是定额组,它是一个事先确定的超过半数的节点集合。

5.日志哨兵机制

为了确保值的正确复制和避免歧义,Paxos算法使用日志哨兵机制。每个日志条目都有一个唯一标识符,称为日志号。更高的日志号被认为比较低日志号的条目更权威。该机制确保:

*任何新提议值必须具有较高的日志号。

*节点只接受日志号最高的提议值。

6.处理故障

Paxos算法能够处理节点故障和网络分区。在节点故障的情况下,系统可以重新选举一个新的领导者继续执行算法。在网络分区的情况下,每个分区将独立运行Paxos算法,一旦分区恢复,系统将合并各个分区的决策。

7.性能优化

为了提高算法的性能,Paxos算法可以结合优化技术,例如FastPaxos和Multi-Paxos。这些优化技术减少了消息交互次数,提高了吞吐量和延迟。

总结

Paxos算法的核心思想包括状态机复制、三阶段协议、协调角色、多数机制、日志哨兵机制、故障处理和性能优化。这些思想共同保证了分布式系统中的数据一致性和可用性,使其能够容忍节点故障和网络分区。第三部分Raft算法的投票表决机制关键词关键要点候选人提名

1.每个服务器在启动或成为候选人时,都会提名它自己为领导者。

2.服务器可以同时提名多个候选人,但它只能为自己投票。

3.只有在过半数服务器提名同一个候选人时,才会进入领导人选举阶段。

领导人选举

1.领导人选举是一个多轮投票过程,每个回合中,服务器向其他服务器发送选票消息。

2.选票中包含候选人的信息、候选人在当前服务器上的日志索引和任期号。

3.服务器收到选票后,根据日志完整性和任期号决定是否投票给候选人。

日志复制

1.领导者接收客户端请求后,将请求转换成日志条目并复制到其他服务器。

2.服务器收到日志条目后,将条目追加到自己的日志中,并返回给领导者一个对响应。

3.领导者等待大多数服务器确认接收到日志条目,然后提交日志条目并应用到自己的状态机。

日志一致性

1.在领导者选举和日志复制过程中,Raft算法确保所有服务器上的日志是相同的。

2.如果服务器之间的日志不一致,Raft算法会强制不一致的服务器回滚日志,直到日志一致为止。

3.日志一致性对于分布式系统中的数据完整性和可靠性至关重要。

故障处理

1.Raft算法能够处理领导者的故障、服务器的故障以及网络分区。

2.当领导者故障时,算法将重新启动领导人选举过程,以选出新的领导者。

3.如果服务器故障,算法将等待故障服务器恢复,并重新同步其日志。

性能优化

1.Raft算法的优化策略旨在提高算法的性能和可扩展性。

2.这些策略包括减少投票回合的次数、使用心跳消息检测服务器故障以及使用分片来提高可扩展性。

3.性能优化对于大型分布式系统至关重要,以确保系统的高可用性和低延迟。Raft算法的投票表决机制

引言

Raft算法是一种分布式一致性算法,用于在分布式系统中达成共识和维护数据一致性。其关键机制之一是投票表决机制,该机制确保选举出领导者并维护系统稳定性。

投票表决过程

Raft集群中的每个节点都有三个状态:跟随者、候选人和领导者。投票表决机制主要用于选举出领导者。

当系统启动或现有领导者宕机时,集群中的节点会进入候选人状态。每个候选人向其他节点发送投票请求(RequestVoteRPC)。

收到投票请求的节点会根据以下规则投票:

*如果该节点已经投票给其他候选人(在当前选举周期中),则不投票。

*否则,该节点将投票给具有最新日志条目的候选人。

日志条目比较规则

Raft算法使用日志条目比较规则来确定哪个候选人拥有最新日志条目。规则如下:

*日志条目数较多的候选人拥有最新日志条目。

*如果日志条目数相同,则比较最后一条日志条目的任期。任期较大的候选人拥有最新日志条目。

投票表决结果

当候选人收到来自大多数节点(含自己)的投票时,它将成为领导者。如果候选人无法获得大多数票,则选举失败,新一轮选举将启动。

领导者变更

一旦选举出领导者,它将向所有跟随者发送附加日志条目(AppendEntriesRPC)。如果领导者连续一段时间内无法向大多数跟随者发送附加日志条目,则跟随者将开始新一轮选举。

稳定性与一致性

Raft算法的投票表决机制确保了领导者的稳定性,即使某些节点宕机。此外,该机制保证了所有跟随者的日志条目与领导者的日志条目保持一致。

容错性

Raft算法的投票表决机制对于以下容错至关重要:

*节点故障:如果节点宕机,其他节点将通过投票表决机制重新选举出领导者。

*网络分区:如果集群被网络分区,每个分区将独立选举出领导者。当网络分区恢复后,拥有最新日志条目的领导者将成为新领导者。

*恶意节点:如果节点出现恶意行为,投票表决机制将忽略其投票,防止其干扰选举或破坏系统一致性。

结论

Raft算法的投票表决机制是其核心的容错和一致性机制之一。它确保了领导者的稳定性、系统的可靠性以及日志条目的最终一致性。通过对该机制的深入理解,可以更好地理解和应用Raft算法,以构建可靠和可扩展的分布式系统。第四部分Zab算法的事务处理机制关键词关键要点Zab算法的事务处理机制

主题名称:Zab的事务协调

1.Zab算法使用Paxos协议实现事务的一致性,通过使用Leader来协调事务的执行。

2.Leader接收客户端的事务请求,并通过Paxos协议将事务提案发送给集群中的其他节点。

3.其他节点对事务提案进行投票,如果超过半数节点投票赞成,则Leader提交事务。

主题名称:事务的原子性和隔离性

Zab算法的事务处理机制

前言

Zab算法是一种分布式一致性协议,用于在分布式系统中复制和管理数据。它通过使用原子广播来确保数据的一致性和容错性。本文介绍了Zab算法的事务处理机制,包括事务的定义、事务处理的过程以及事务的保证。

事务的定义

在Zab算法中,事务是一个原子的操作序列。原子性意味着事务要么完全执行,要么完全不执行,不会出现部分执行的情况。事务还具有隔离性、一致性和持久性(ACID)属性。

事务处理的过程

Zab算法的事务处理过程涉及以下步骤:

1.事务提交:客户端向领导者节点提交事务请求。

2.提议阶段:领导者节点将事务请求提案给从节点。

3.同意阶段:从节点将确认(ACK)或拒绝(NACK)发回给领导者节点。

4.提交阶段:如果领导者节点收到大多数从节点的ACK,它将提交事务并将其复制到所有从节点。

事务的保证

Zab算法的事务处理机制提供了以下保证:

*原子性:要么整个事务执行成功,要么整个事务执行失败。

*一致性:所有从节点都复制了相同的事务版本。

*隔离性:事务与其他同时执行的事务隔离。

*持久性:一旦事务提交,它就会永久存储在所有从节点上。

事务处理的容错性

Zab算法的事务处理机制具有很强的容错性,可以处理以下情况:

*领导者故障:如果领导者节点出现故障,其他从节点将选举一个新的领导者节点,并继续处理事务。

*从节点故障:如果从节点出现故障,领导者节点将继续接受事务请求并复制事务到剩余的从节点。

*网络分区:如果网络分区,Zab算法将保证在每个分区内处理的事务是正确的,并且当网络分区恢复后,系统将保持一致。

应用

Zab算法的事务处理机制广泛应用于分布式系统中,例如ApacheKafka、ApacheHBase和etcd。它为这些系统提供了一致和可靠的事务处理功能。第五部分Chubby算法的锁服务实现关键词关键要点【Chubby锁管理器】

1.锁机制:Chubby使用分布式锁机制,通过协调多个服务器来确保对共享资源的独占访问。锁分为两种类型:会话锁和分布式锁,分别用于短期和长期访问锁定的资源。

2.锁获取流程:客户端向锁管理器请求获取锁,管理器检查锁的可用性,并在可用时授予锁。客户端保持与管理器的活动连接以续租锁,超时后锁自动释放。

3.会话失败处理:Chubby支持会话故障处理,当客户端断开连接时,管理器会自动释放与其关联的锁,防止死锁。

【Chubby架构】

分布式程序理解算法:Chubby算法的锁服务实现

引言

分布式系统中,协调不同进程之间的访问至关重要。锁服务通过提供一种协调机制,确保仅允许一个进程在特定时间段内访问共享资源,从而解决此问题。本文介绍了Chubby算法,这是一种用于构建分布式锁服务的著名且广泛使用的算法。

Chubby算法

Chubby算法由MikeBurrows在谷歌开发,它基于Paxos共识算法。Chubby算法的核心概念是一个叫做“单元格”的数据结构,它存储了一个值和一个单调递增的序列号。

锁服务实现

Chubby算法可以通过以下步骤实现锁服务:

1.创建锁:客户端向主服务器发送请求以创建锁。主服务器在Chubby中创建一个新单元格,并将值设置为“解锁”。

2.获取锁:客户端向主服务器发送请求以获取锁。主服务器检查单元格的值。如果值为“解锁”,则将其设置为“锁定”并返回序列号。

3.释放锁:客户端向主服务器发送请求以释放锁。主服务器检查单元格的值。如果值为“锁定”且序列号与客户端提供的序列号匹配,则将其设置为“解锁”。

并发控制

为了处理并发请求,Chubby算法使用Paxos共识算法。当主服务器收到请求时,它会向备份服务器发送提案。备份服务器在提案上执行Paxos算法,以达成共识并确定提案是否应该被接受。如果提案被接受,则主服务器将对其进行提交。

故障处理

Chubby算法具有容错性,可以承受主服务器或备份服务器的故障。如果主服务器发生故障,备份服务器将选举一个新的主服务器。新主服务器将从故障主服务器中获取状态,并继续处理请求。

优点

Chubby算法具有以下优点:

*高可用性:容错设计确保了即使在发生故障的情况下也能提供高可用性。

*可扩展性:可以轻松添加备份服务器以处理增加的负载。

*一致性:Paxos共识算法确保所有服务器就单元格的值达成一致。

缺点

Chubby算法也有一些缺点:

*性能开销:Paxos共识算法可能会引入性能开销,尤其是在系统负载较高的情况下。

*复杂性:算法的实现可能很复杂,需要深入了解分布式系统概念。

结论

Chubby算法是一种用于构建分布式锁服务的有效算法。它基于Paxos共识算法,具有容错性、可扩展性和一致性。虽然它可能存在一些性能开销和复杂性,但它仍然是分布式系统中协调访问共享资源的可靠选择。第六部分ZooKeeper算法的协调服务特性关键词关键要点主题名称:一致性保证

1.ZooKeeper算法通过原子事务和顺序协调机制,确保分布式系统中协调服务的强一致性。

2.原子事务保证更新操作要么全部成功,要么全部失败,防止系统出现不一致状态。

3.顺序协调保证更新操作按指定的顺序执行,避免并发冲突导致数据不一致。

主题名称:容错性

ZooKeeper算法的协调服务特性

ZooKeeper是一种分布式协调服务,用于管理分布式系统中的共享数据和协调操作。它提供了以下关键的协调服务特性:

1.分布式锁服务

分布式锁允许多个节点对共享资源进行互斥访问。ZooKeeper使用原子操作(如创建或删除znode)来实现分布式锁。如果一个节点获得了锁,则其他节点将被阻塞,直到锁被释放。

2.领导者选举

领导者选举算法允许一个分布式系统在任何时刻只选择一个节点作为领导者。ZooKeeper使用基于Zab协议的选举机制来选举领导者。领导者负责管理整个集群的状态和提供对共享数据的访问。

3.配置管理

ZooKeeper可以用作分布式系统的配置存储。它允许节点存储和检索有关系统配置和状态的信息。这使得应用程序可以动态调整其行为,而无需手动重新配置每个节点。

4.集群成员管理

ZooKeeper跟踪集群中节点的状态。它提供了一个监视机制,允许节点检测其他节点的故障或恢复。这有助于维护集群的可用性和一致性。

5.数据一致性

ZooKeeper确保集群中节点之间的数据一致性。它使用Paxos算法来保证所有节点在任何时候都看到相同的共享数据。这对于确保分布式系统中的数据完整性至关重要。

6.事件通知

ZooKeeper提供事件通知机制,允许节点订阅特定事件。当发生这些事件时,节点将收到通知,以便及时做出反应。这使得分布式应用程序能够对系统中的变化做出动态响应。

7.命名服务

ZooKeeper可以用作分布式系统中的命名服务。它允许节点使用分层命名空间注册和查找服务。这有助于简化服务发现和通信。

8.故障容错

ZooKeeper是一个高度容错的系统。它使用复制和故障转移机制来确保即使发生故障,集群也可以继续运行。这使得它非常适合于关键任务分布式应用程序。

9.扩展性

ZooKeeper可以轻松扩展到大型集群。它使用分层架构,可以添加更多节点以满足不断增长的需求。这使其可以用于大规模分布式系统。

10.性能

ZooKeeper经过优化,可以提供高性能。它使用高效的数据结构和算法来处理大量并发请求。这使其能够支持高吞吐量和低延迟的分布式应用程序。

总的来说,ZooKeeper算法的协调服务特性使其成为管理分布式系统共享数据和协调操作的理想解决方案。它具有分布式锁、领导者选举、配置管理、集群成员管理、数据一致性、事件通知、命名服务、故障容错、扩展性和性能等关键功能。第七部分Kafka算法的消息发布订阅模型关键词关键要点生产者和消费者模型

1.生产者负责将消息发布到主题中,而消费者负责从主题中订阅并消费消息。

2.这种模型提供了解耦生产者和消费者的优势,允许它们在不同的时间和频率下操作。

3.每条消息都会被附加一个偏移量,以确保消费者从上次离开的位置继续消费。

分区和副本

1.分区是主题的逻辑拆分,允许并行处理消息。

2.副本是同一分区的消息副本,存储在不同的服务器上,以提供容错和高可用性。

3.Kafka使用一致性哈希算法来确定消息应分配到哪个分区和副本。

消息键和排序

1.消息键允许对消息进行分区和排序。

2.通过使用相同的键发布相关消息,可以确保它们被分配到同一分区中,从而实现顺序处理。

3.Kafka支持消息的自定义排序,允许应用程序根据特定标准对消息进行排序。

消费组和偏移量管理

1.消费组是一个逻辑消费者组,共享消费主题的偏移量。

2.每个消费组中的每个消费者实例仅消费属于该组的特定分区。

3.Kafka自动管理消费者的偏移量,以确保每个消息只被消费一次。

事务和幂等性

1.Kafka事务允许应用程序在生产和消费消息时保持事务的一致性。

2.幂等性确保同一消息不会被多次处理,即使在网络故障或分区重新分配的情况下。

3.这些特性对于构建可靠和可扩展的分布式系统至关重要。

Streams和KTable

1.KafkaStreams是一种用于实时处理消息的库。

2.KTable是一个表状的数据结构,允许用户对消息进行聚合、join和窗口化操作。

3.使用KafkaStreams和KTable,应用程序可以构建复杂的处理管道,以分析和转换流数据。ApacheKafka消息发布订阅模型

简介

ApacheKafka是一种分布式消息平台,它使用发布订阅模型来实现高效的消息传递。在该模型中,消息生产者将消息发布到一个或多个主题(topic),而消息消费者订阅这些主题并消费消息。

主题

主题是Kafka中消息的逻辑分组。生产者将消息发布到特定主题,而消费者订阅感兴趣的主题。主题可以按应用程序领域、功能或其他标准进行组织。

分区

为了实现可扩展性和高可用性,主题被划分为多个分区。每个分区是一个有序的、不可变的消息序列。消息根据键(key)分配到分区,以确保所有具有相同键的消息都落入同一分区。

生产者

生产者是向主题发布消息的进程或服务。生产者可以使用多种API(如Java、Python和Go)与Kafka集群进行交互。生产者还可以配置以下设置:

*分区策略:用于确定消息应发布到哪个分区。

*键策略:用于为消息生成键。

*事务:用于确保消息的有序性和一致性。

消费者

消费者是订阅主题并消费消息的进程或服务。消费者使用以下API与Kafka集群进行交互:

*ConsumerAPI:用于创建消费者组并消费消息。

*StreamingAPI:用于实时处理消息。

消费者组

消费者组是一组消费者,它们共同订阅多个主题。消费者组中的每个消费者都处理不同分区的消息,以实现负载均衡。每个消息仅被消费者组中的一个消费者消费。

消息顺序保证

Kafka根据以下原则保证消息顺序:

*分区内顺序:每个分区内的消息都是按顺序传递的。

*分区间顺序:如果消息具有相同的键,则它们将被发送到同一分区并按顺序传递。

*跨分区顺序:对于具有不同键的消息,Kafka无法保证跨分区的消息顺序。

可靠性保证

Kafka提供以下可靠性保证:

*持久性:消息存储在磁盘上,以防止数据丢失。

*容错性:Kafka集群容忍分区和节点的故障,而不会丢失数据。

*可扩展性:Kafka集群可以轻松扩展以满足不断增长的需求。

用例

Kafka的消息发布订阅模型广泛用于以下用例:

*流数据处理:实时处理大量数据。

*数据集成:从不同来源聚合数据。

*消息传递:可靠高效地传递消息。

*事件驱动的架构:构建响应事件的应用程序。

*大数据分析:分析和处理大数据集。

优点

Kafka消息发布订阅模型具有以下优点:

*高吞吐量和低延迟

*可扩展性和高可用性

*可靠性和持久性

*消息顺序保证

*支持流数据处理

*与多种语言和框架兼容

总结

ApacheKafka的消息发布订阅模型提供了一种高效且可靠的方法来传递消息。该模型可用于各种用例,包括流数据处理、数据集成和消息传递。Kafka的可扩展性、高可用性和可靠性使其成为构建分布式应用程序的理想平台。第八部分Flink算法的流式数据处理框架关键词关键要点【Flink流式数据处理框架】

1.Flink是一个开源的分布式流

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论