免费在线 数据库自增长 5 使用Redis生成ID 生成唯一的ID——发号机制 2 6 时钟算法 7 变异时钟算法——SnowFlake（雪花）算法 8 自定义发号机制 9 数据库分库、分表、分区 3 优点：简单方便、性能高 11 哈希分片之求余算法 缺点：无法满足较大的伸缩性 分布式数据库技术 图14.6 通过求哈希值将数据库节点放入哈希环中 1 13 实际实践三大问题 12 一致性哈希算法 14 优点：对于伸缩性大有好处 10 分片算法 15 缺点：能导致数据分配不均，造成某一节点数据膨胀 16 热点数据 热点分配法 17 分布式技术 1 基本原理 1 18 19 分片中间件ShardingSphere ShardingSphere的重要概念 强一致性：指任何多个后续线程或者其他节点的访问都会返回最新值。需要复杂 的协议，也会牺牲更多性能。 强一致性与弱一致性 弱一致性：指当用户对数据完成更新操作后，并不保证在后续线程或者其他节点 马上访问到最新值，它只是通过某种方法来保证最后的一致性。 23 第一阶段 1 两阶段提交协议-如：XA协议 22 第二阶段 24 1 优点：实现简单 ，缺点：性能低，死锁 21 强一致性事务（不适用） 25 三阶段提交协议 分布式数据库事务 20 26 增加询问阶段 27 增加超时机制 29 状态表 30 RabbitMQ可靠事件 32 提高尝试次数 31 最大尝试 33 保证幂等性 28 弱一致性事务 34 TCC模式 tcc-interface.png tcc-service.png 备注： 1. Spring Cloud微服务和分布式系统实践-杨开振-第15章 I S B N ：06 2. 生成ID的机制需要从这么几方面进行评价。 ●机制的可靠性：有些算法可能有一定的概率出现重复的ID ，也可以利用缓存机制来实现，但缓存工具也不一定完全可靠，可能也需要重启或者出现故障，如果遇到类似这样的问题，是否会对ID的 唯一性造成影响。 ●实现复杂度：有些算法可以实现ID的唯一性和可读性，但是实现起来十分复杂，后续也难以改造。 ●可扩展性：有时候，发号机制不单单是一个节点的工作，可能是多个节点的工作，节点能否伸缩是一个考量点。 ●ID的可读性：有些ID只是为了唯一性，如UUID机制，它是不可读的，没有业务含义。不过，生成一个可读的带有业务含义的ID ，将有助于业务人员和开发人员定位业务和问题所在。 ●性能：分布式系统往往也需要面对高并发的情况，在这种情况下，性能也会列入评价ID机制的范畴。 3. 为什么不建议用UUID? 1.业务不可读 2. 占据存储空间大，网络传输内容多 3.降低数据库主键算法性能、检索数据的性能(B+树) 4. 在分布式系统中使用MySQL的概率要比Oracle大，所以这里我会采用MySQL进行讲述。对于Oracle数据库，可以考虑使用其序列（SEQUENCE）机制。 通过设置主键开始值和主键的步长来实现： 不过这样做会带来以下的问题。 ●如果需要增加数据库节点，就要改变自增长规则，显然，这样做不利于扩展。 ●如果出现高并发场景，数据库的性能可能就无法满足需要了，这时优化数据库会变得十分复杂，优化的空间也相对有限。 ●如果数据需要迁徙或合并，还需要考虑现有规则和新规则的适应性。 5. 使用Redis生成ID: 优点:原子性、不会产生重号，可以满足一般应用性能需要。 缺点:依赖Redis服务、Redis服务可能出现故障，算法复杂增加开发者实现的复杂度。 6. // 同步锁 private static final ClassClockId LOCK = ClockId.class; public static long timeKey(){ // 线程同步锁，防止多线程错误 synchronized (LOCK){ // 获取当前时间的纳秒值 long result = System.nanoTime(); // 死循环 让程序循环到下一个纳秒才返回，这样就能够保证其返回ID的唯一性了。 while (true){ long current = System.nanoTime(); if (current - result 1){ // 返回结果 return result; } } } } 时钟算法生成ID: 优点:简单、单机性能高 缺点:用于分布式节点上容易重号。 7. SnowFlake （雪花）算法是Twitter提出的一种算法，我们之前在阐述时钟算法的时候谈到过，如果MySQL的主键采用BIGINT （大整数）类型，那么它的取值范围是−263到263−1 ，从计算机原理的角 度来说，存储一个BIGINT类型就需要64位二进制位。基于这个事实，SnowFlake算法对这64位二进制位做了如下的约定。 关于SnowFlake算法对于64位二进制的约定： ●第1位二进制值固定为0 ，没有业务含义，在计算机原理中，它是一个符号位，0代表正数，1代表负数，这里恒定为0。 ●第2 ～42位，共41位二进制，为时间戳位，用于存入精确到毫秒数的时间。 ●第43 ～52位，共10位二进制，为工作机器id位，其中工作机器又分为5位数据中心编号和5位受理机器编号，而5位二进制表达整数时取值区间为[0, 31]。 ●第53 ～64位，共12位二进制，代表1ms内可以产生的序列号，当它表示整数时，取值区间为[0,4095]。 通过上述讲解，我们可以看到，这样的一个算法可以保证在1ms内生成4096个编号，实际就是1秒至多产生4096000个ID ，这样的性能显然可以满足分布式系统的需要，而更加好的是，存在10位工作 机器位，这样出现问题可以定位到机器，有助于业务和开发者定位问题。 缺陷： ●因为时间戳只存在41位二进制，所以只能使用69年，69年后就可能产生重复Kaiyun的ID了，不过这个时间已经比较长了，相信大部分的系统和主要的算法早已更替。 ●从SnowFlake算法上来看，如果机器性能足够好，每秒可以产生超过400万个ID ，但是对于大部分企业来说，只需要每秒满足数万个ID即可，并不需要这么高的性能。这种高性能浪费的主要是序号 的二进制位，实际上，二进制位达到9位，就可以产生512个序号，如果机器性能足够，就可以每秒产生超过50万的ID ，这就已经能满足大部分企业的需要了。 ●从机器位来说，因为去中心化是分布式和微服务的趋势，所以我在实现的时候，并未考虑受理机器编号，这样就会造成机器位数有10位二进制，可以表达区间[0, 1023]的整数。如果数据中心预估 总共只有几十台机器，显然也会造成二进制位的浪费。 8. SnowFlake算法有诸多缺点，例如，产生的序号和机器位可能浪费了太多的二进制。 所以我们可以改造SnowFlake算法，编写自定义发号机制。 在改造前，需要先明确自己的系统的实际情况，这是第一步。这里做如下假设。 ●预估数据中心不会超过100个，这就意味着数据中心使用8位二进制即可，原来的10位就能够节省出2位了。 ●系统不会超过每秒10万次的请求（这符合大部分企业的需求），如果超过可以使用限流算法进行处理，所以序号使用8位二进制即可，这样原来的12位就能够节省出4位了。 由此来看，一共可以节省6位二进制，可以用于表示发号机器编号，这样就可以同时在多个节点上使用发号算法了。 约定如下。 ●第1位二进制固定为0。 ●第2 ～42位，共41位二进制，存储时间戳。 ●第43 ～48位，共6位二进制，存储发号机器号。 ●第49 ～56位，共8位二进制，存储数据中心编号。 ●第57 ～64位，共8位二进制，存储序号。SnowFlake算法有诸多缺点，例如，产生的序号和机器位可能浪费了太多的二进制。 所以我们可以改造SnowFlake算法，编写自定义发号机制。 在改造前，需要先明确自己的系统的实际情况，这是第一步。这里做如下假设。 ●预估数据中心不会超过100个，这就意味着数据中心使用8位二进制即可，原来的10位就能够节省出2位了。 ●系统不会超过每秒10万次的请求（这符合大部分企业的需求），如果超过可以使用限流算法进行处理，所以序号使用8位二进制即可，这样原来的12位就能够节省出4位了。 由此来看，一共可以节省6位二进制，可以用于表示发号机器编号，这样就可以同时在多个节点上使用发号算法了。 约定如下。 ●第1位二进制固定为0。 ●第2 ～42位，共41位二进制，存储时间戳。 ●第43 ～48位，共6位二进制，存储发号机器号。 ●第49 ～56位，共8位二进制，存储数据中心编号。 ●第57 ～64位，共8位二进制，存储序号。 9. 分库：将一套数据库的设计结构，部署到多个数据库实例的节点（逻辑节点）中去，在应用的时候，按照一定的方法通过多个数据库实例节点访问数据。#13; 核心：将数据库分为多个节点，所以需要一个路由算法来确定数据具体存放在哪个库中，于是路由算法就成了我们关注的核心内容之一。#13; 查询/操作：最简单的路由算法是求余算法.例如，现在划分为3个数据库，在获取用户ID （userId ，假设是一个Long型数据）后，采用userId对3求余（userId%3 ），得到余数（可能为0或1或2），然 后再根据余数存放到对应的库中。当然，这样也会有一定的缺点，为此有人提出了一致性哈希算法。#13; #13; #13; 分区：一张表的数据分成n个区块，在逻辑上看，最终只是一张表，但底层是由n个物理区块组成的。#13; 分区技术与分表技术很类似，只是分区技术属于数据库内部的技术，对于开发者来说，它逻辑上仍旧是一张表，开发时不需要改变SQL表名。当前Oracle和MySQL 5.1后的版本都能够支持分区技 术。将一张表切分为多个物理区块，有以下这么几个好处。#13; ●相对于单个文件系统或是磁盘，分区可以在不同的磁盘上存储更多的数据。#13; ●数据管理比较方便，例如，需要按日期删除交易记录时，只需要在对应的分区操作即可。#13; ●在使用分区的字段查询时，可以先定位到分区，然后就只需要查询分区，而不需要全表查询了，这样可以大大提高数据检索效率。#13; ●支持CPU多线程同时查询多个分区磁盘，提高查询的吞吐量。#13; ●在涉及聚合函数查询时，可以很容易地合并数据。#13; #13; 分表（不推荐使用）：指在一个或者多个数据库实例内，将一张表拆分为多张表存储。#13; 原因：一张表数据量太大，性能瓶颈（MySQL 5000万条记录左右）#13; 拆分：根据某种算法拆分表，比如交易记录表根据年份拆#13; 查询：分表查找、需要路由算法和合并算法合并数据。#13; 不推荐原因：分表会导致表名变化，产生逻辑不一致，继而加大后续开发的工作量和统计上的困难。 10. 在互联网的实践中，数据往往被划分为两大类： 一类是带有用户性质的数据； 另一类是不带用户性质的数据。 带有用户性质的数据往往是网站中最庞大最主要的，是我们分布式数据库存储的主要内容，也是我们关注的重点；另外一部分是不带用户性质的，例如产品，它和用户无关，是平台发布的数据， 相对于用户数据，这部分数据会少得多。 11. 常见的哈希算法有两种，一种是求余算法，另外一种是一致性哈希算法。相对来说，求余算法很简单。 3个库sc_chapter14_1、sc_chapter14_2和sc_chapter14_3。我们只需要使用userId对3进行求余，就知道要存入哪个数据库了，这个算法十分简单易行。 但是数据量不断膨胀，所以3个库已经不够用了，要增加1个库，从3个库变为4个库，就需要通过使用userId对4求余来决定将数据存放到哪个库。当然，这对新的用户数据没有什么影响，但是旧的 用户数据就必须迁徙了。然而，所有数据库的数据都做迁徙，无疑需要大量的时间和代价，成本也较高。对于那些已经部署了数百个数据库的企业，当出现业务增长缓慢、出现资源浪费、需要为 了节省成本而减少数据库的时候，也要迁徙所有的数据才能重新部署。所以这样的算法不适合那些频繁增加和减少节点的企业，为了满足业务伸缩性较大的企业的需求，有软件开发者提出了新的 算法——著名的一致性哈希算法。 12. 其他标识性的属性求其哈希值（hash code ），然后该值就会对应到这个哈希环上的某一点。 为了进行说明，这里需要进行一些假设。 ●假设Node A、Node B、Node C和NodeD这4个节点的哈希值为Hash A、Hash B、Hash C和Hash D ，根据图14-6就可以得到以下5个区间：[0, Hash A]、[Hash A, Hash B]、[Hash B,Hash C]、[Hash C, Hash D]和[Hash D, 232 −1)。 ●假设对userId也求哈希值，记为n ，而n必然落入Node A、Node B、Node C和NodeD这4个节点所产生的5个区间之中。 在一致性哈希算法中，对于n ，采用顺时针方向找到下一个数据库节点，用来存放该数据。为了说明这点，这里举几个例子，这些例子都紧扣图14-6，所以结合该图进行阅读往往会事半功倍。 例如： Hash A n Hash B 那么根据图14-6，按顺时针方向找到的下一个数据库节点就是Node B节点。 又如： 0 = n Hash A 那么根据图14-6，按顺时针方向找到的下一个数据库节点就是Node A节点。 再如： Hash D =n2^32 -1 那么根据图14-6，按顺时针方向找到的下一个数据库节点就是Node A节点。 13. ●在使用JDK的hashcode方法计算哈希值的时候，如果字符串对象长度较短，那么得到的哈希值也会很小，不足以比较平均地划分区间[0, 2^32 −1]，这时我们该如何处理？ 在诸多的哈希算法中，应该说，当前最好的一致性哈希算法是FNV1哈希算法，它是一个可以支持32位二进制的算法。 ●存不存在既能支持哈希环模式，又能简化我们编程的数据结构？ 在Java中，支持哈希环的数据结构是SortedMap ，使用它可以保存数据库的编号（或其他标识）或者其哈希值，并且支持顺时针路由到下一个节点，能简化我们的开发。 ●区间[0, 2^32 −1]很大，实践中可能并不需要那么大的区间，是否可以缩小区间，以简化我们的开发？ 区间[0, 2^32 −1]确实过大，在实践中可以考虑缩小区间，但在缩小区间之前，需要先进行合理的评估，例如，如果觉得预留1000个数据库就足够未来用了，那么就可以采用区间[0, 1023]作为哈希环 14. 一致性哈希算法，对于伸缩性大有好处：当我们减少一个节点的时候，只需要将减少的那个节点的数据插入到顺时针的下一个节点即可；当我们新增一个节点的时候，只需要通过哈希值计算将下 一个节点的部分数据分配给新增节点即可。从上述可以知道，通过一致性哈希算法，新增或者减少节点，只需要移动附近节点的数据即可，无须全局迁徙，所以一致性哈希算法非常合适那些需要 经常增加和删除存储节点的应用。 15. 为了解决这个问题，我们需要先了解导致这个缺点的两个主要原因。 ●哈希值划分哈希环不太平均，导致划分大的区间得到分配的概率大，划分小的区间得到分配的概率小。 ●划分的节点太少，容易得到一个很大的区间，导致大部分数据流入某一区间之内，导致数据碰撞。 一般来说，第一个原因比较难去除，因为哈希算法是相对固定的。但是第二个原因可以通过虚拟节点来去除，例如，对于编号001的节点，我们可以生成10个虚拟节点：001#1、001#2、001# 3、…、001#10 ，这样一个真实的数据源节点就变成了10个虚拟的节点，如果是3个数据源，就会演变为30个划分哈希环的节点，这样整个哈希环就有更大的概率趋近于平均分配区间。 虚拟节点越多，分配越平均，但是，虚拟节点使用过多，也会导致伸缩性下降。 16. 对于那些常常需要访问的数据，我们称为热点数据。 假设我们采用了一致性哈希分片算法，有3个库，即库1、库2和库3。3个库的数据分配得比较平均，但是80%的热点数据在库1中。这样就会导致库1比较繁忙，库2和库3比较清闲，在高并发下，库 1就可能因为超负荷工作而瘫痪。这是因为数据虽然平均分配了，但是热点数据分配不平均。为了解决这个问题，一些开发者提出了按热点分配的方法，最理想的情况是，热点数据能够比较平均地 分配到各个库中，这样在负荷上分配就比较平均了，整个系统性能也会得到显著提升。 17. 在公共的数据库（一般将这张表数据放入公共的缓存数据库）上创建一张用户数据映射表，通过它来区分热点数据和非热点数据。 之后，每当月末时，通过判断登录次数，决定该用户的数据是否为热点数据，然后将这些热点数据通过数据迁徙的方式，平均分配到各个数据库中，这样，热点数据就被平均分配到各个数据库中 了，每个数据库的负荷就相对平均了，系统性能也会比较理想。但是别忘了，在迁徙数据的同时，也需要维护映射表和Redis缓存的数据，这样微服务系统才能够重新从Redis读写最新的映射关系。 18. ShardingSphere是基于当当网开发的开源框架Sharding-JDBC开发的，能够支持数据库的分片技术，但是它还不能支持如HAVING、DISTINCT等SQL语句，此外它在联机分析处理（OLAP）方面，性 能不佳，所以需要进行分布式统计分析的，最好不要使用ShardingSphere。 19. ShardingSphere是一个能够支持分片和分库的轻量级框架，在使用它之前，需要了解它的一些重要概念。 ●逻辑表：分表技术是将一个原本存储大量数据的表拆分为具有相同字段但表名不同的一系列表，我们把这一系列表统称为逻辑表。例如，当我们把产品表拆分为表t_product_1、t_product_2、t_pro duct_3……时，把表t_product_1、t_product_2、t_product_3……统称为表t_product ，它是一个逻辑概念，不是一个真实存在的表。 ●真实表：是指在数据库中真实存在的表，例如，逻辑表概念中谈到的表t_product_1、t_product_2、t_product_3……这些就是真实表，它真实地存在于数据库中。 ●数据节点：它是ShardingSphere拆分的最小分片单位，它会定位到具体的某个数据库的某张真实表，格式为ds_name.t_product_x ，其中ds_name为数据库名称，t_product_x为真实表的名称。 ●绑定表：指分片规则下的主表和子表，这个概念有点复杂，后面再解释它。 上面谈及的绑定表的概念，理解起来可能有一些困难，这里再说明一下。在数据库中，有主表和从表的概念，例如，我们说产品表（t_product）是主表，销售表（t_sales ）是从表，因为从表是基于 主表派生出来的。 如果未分表，直接一条join 的SQL就可以搞定。 采用分表技术之后，查询起来就不那么容易了。假设这里将产品表拆分为表t_product_0和t_product_1 ，同时把销售表拆分为表t_salses_0和t_salses_1 ，那么上述的SQL就会被ShardingSphere翻译为4条 SQL （t_product_0与t_salses_0、t_product_0与t_salses_1、t_product_1与t_salses_0、t_product_1与t_salses_1 ） 20. 如商品的库存和用户的账户资金，而这些却极有可能分别存储在不同的数据库节点中，那么如何在多个数据库节点中保证这些数据的一致性，就是分布式数据库事务要解决的问题。 21. 无论是两阶段提交协议，还是三阶段提交协议，当前都不是企业保证一致性的主流技术了，原因大体有两个。 第一，它们的实现相对来说比较复杂，日后维护和运维起来都比较困难。 第二，使用了大量锁技术，在高并发的情况下，会造成大量的阻塞，导致用户体验不佳，影响用户的忠诚度。因此，两阶段和三阶段提交协议就都渐渐地没落了，取代它们的是弱一致性事务的技 术。 另外微服务也不适用强一致性事务： 微服务是按业务区分的，并且每一个子业务都是一个单独的服务，是一个独立的产品，拥有单独的数据系统。为了划清界限，这些微服务之间的服务调用是通过REST风格的调用来完成的，而不是 通过调用数据库来完成的。这就意味着，在协作的时候，一个微服务无法直接调用另一个微服务的数据库，只能通过REST调用来完成协作，这显然无法使用强一致性的数据库事务。 22. 顾名思义分两个阶段完成分布式事务。 在XA协议中，首先会引入一个中间件，叫作事务管理器，它是一个协调者。 为了支持XA协议，Java方面定义了JTA （Java Transaction API ）规范，和JDBC一样，JTA只是一个规范，它需要具体的数据库厂商进行实现，这是一种典型的桥接模式。在JTA中，定义了接口XACo nnection和XADataSource ，这两个接口的实现需要具体的数据库厂商提供。在MySQL中，5.0以后的版本才开始支持XA协议，因此在MySQL中使用JTA ，需要使用MySQL 5.0以后的版本。MySQL中 提供了XAConnection和XADataSource两个接口的具体实现类，因而支持XA协议。为了更好地支持分布式事务，一些开源框架也提供了很好的支持，其中以Atomikos、Bitronix和Narayana最为出名。 当今评价最高、使用较广泛的是Atomikos。 23. 第一阶段执行步骤： ●应用系统使用事务管理器，首先将数据发送给需要操作的分布式数据库，并且给予预备命令。 ●当分布式数据库得到数据和预备命令后，对数据进行锁定（MySQL和Oracle都会将事务隔离级别设置为Serializable——序列化），保证数据不会被其他事务干扰。 ●在本地资源管理器做好上一步后，对事务管理器提交就绪信息。 24. 第二结阶段执行步骤： ●当事务管理器接收到XA协议第一阶段得到的所有数据库的就绪信息后，就会对所有数据库发送提交的命令。 ●当各个本地资源管理器接收到提交的命令时，就会将在XA协议第一阶段锁定的数据进行提交，然后释放锁定的数据。 ●当做完上一步后，本地资源管理器就会对事务管理器发送提交成功的信息，表明数据已经操作成功了。 25. 在两阶段提交协议的基础上演变出来的，它只是增加了询问和超时的功能。询问功能是指在执行XA协议之前，对数据库连接和资源进行验证。超时功能是指数据库在执行XA协议的过程中锁定的 资源，在超过一个时间戳后，会自动释放锁，避免死锁。 26. 在执行两阶段前做一些询问和验证，如验证连接数据库是否成功，可通过执行简易查询SQL是否成功进行验证，如果成功了，就继续执行，如果没成功，则中断执行，这样就能在大大提升成功率 的同时，减少出错的可能性。 27. 其次，在执行XA协议的过程中，如果事务执行超时，则提交事务。这里也许有读者会问：为什么不是回滚事务呢？那是因为互联网的大量实践经验表明，在大部分情况下，提交事务的合理性要远 远超过回滚事务。这样操作的好处在于，可以防止数据库锁定资源，导致系统出现的死锁问题。 28. 弱一致性是指当用户对数据完成更新操作后，并不保证后续线程或者其他节点能马上访问到最新值，一致性由后续操作保证。弱一致性的好处是，各个服务实例的操作可以在无锁的情况下进行， 性能上没有损失，能迎合高并发的要求，实现起来也相对简单和灵活。 什么是冲正交易？在学习数学的时候，我们知道，正数+负数是可以等于零的，如算式1+(−1)=0，利用这个原理，我们在设计产品交易表和资金交易明细表时，设置状态字段（state）。 这里假设状态字段可以有4个枚举值，下面稍加说明一下。 ●1—准备提交：指在业务流程中，未生效的记录。 ●2—提交成功：指在业务流程完成后，已经生效的记录。 ●3—被冲正：指原本在“1—准备提交”的状态，但后续因为某种原因无法完成交易的记录，这个时候就会发起冲正交易，冲掉该记录，将状态修改为被冲正。 ●4—冲正记录：因为某种原因无法完成交易时，用于冲掉“1—准备提交”状态下记录的记录。 实现弱一致性有很多种方法，常用的4种方法：状态表、RabbitMQ可靠事件，最大尝试和TCC模式。 29. ●在产品服务减库存后，记录产品交易明细，如果没有异常，就将产品交易记录的状态位设置为“1—准备提交” ，并且记录在Redis的状态表中。 ●产品服务通过服务调用资金服务，如果成功，就将账户交易表的记录的状态位设置为“1—准备提交” ，并且记录在Redis的状态表中。 ●最后，读取Redis相关的所有状态位，确定是否所有的操作都为“1—准备提交”状态

　　2、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。

　　3、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。

　　4、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档

　　初中英语新人教版八年级上册Unit 2 Home Sweet Home语法知识讲解和练习（2025秋）.doc

　　新教材高中物理 期末综合检测（A、B卷）（含解析）新人教版必修第一册.pdf

　　2025新人教版八年级英语上册Unit 2 Home Sweet课文讲解学案.docx

　　2024年新教材高中物理模块综合检测A含解析新人教版必修第一册.docx

　　2024_2025学年新教材高中物理期末把关检测卷含解析新人教版必修第一册.doc

　　原创力文档创建于2008年，本站为文档C2C交易模式，即用户上传的文档直接分享给其他用户（可下载、阅读），本站只是中间服务平台，本站所有文档下载所得的收益归上传人所有。原创力文档是网络服务平台方，若您的权利被侵害，请发链接和相关诉求至 电线) ，上传者