• 关于

    传输理论故障原因

    的搜索结果

问题

网站打开速度很慢是什么原因

edison_du 2019-12-01 22:06:08 8112 浏览量 回答数 2

回答

数据可靠性RocketMQ支持异步实时刷盘,同步刷盘,同步Replication,异步ReplicationKafka使用异步刷盘方式,异步Replication/同步Replication总结:RocketMQ的同步刷盘在单机可靠性上比Kafka更高,不会因为操作系统Crash,导致数据丢失。Kafka同步Replication理论上性能低于RocketMQ的同步Replication,原因是Kafka的数据以分区为单位组织,意味着一个Kafka实例上会有几百个数据分区,RocketMQ一个实例上只有一个数据分区,RocketMQ可以充分利用IO Group Commit机制,批量传输数据,配置同步Replication与异步Replication相比,性能损耗约20%~30%,Kafka没有亲自测试过,但是个人认为理论上会低于RocketMQ。性能对比Kafka单机写入TPS约在百万条/秒,消息大小10个字节RocketMQ单机写入TPS单实例约7万条/秒,单机部署3个Broker,可以跑到最高12万条/秒,消息大小10个字节总结:Kafka的TPS跑到单机百万,主要是由于Producer端将多个小消息合并,批量发向Broker。RocketMQ为什么没有这么做?Producer通常使用Java语言,缓存过多消息,GC是个很严重的问题Producer调用发送消息接口,消息未发送到Broker,向业务返回成功,此时Producer宕机,会导致消息丢失,业务出错Producer通常为分布式系统,且每台机器都是多线程发送,我们认为线上的系统单个Producer每秒产生的数据量有限,不可能上万。缓存的功能完全可以由上层业务完成。单机支持的队列数Kafka单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长。Kafka分区数无法过多的问题RocketMQ单机支持最高5万个队列,Load不会发生明显变化队列多有什么好处?单机可以创建更多Topic,因为每个Topic都是由一批队列组成Consumer的集群规模和队列数成正比,队列越多,Consumer集群可以越大消息投递实时性Kafka使用短轮询方式,实时性取决于轮询间隔时间,0.8以后版本支持长轮询。RocketMQ使用长轮询,同Push方式实时性一致,消息的投递延时通常在几个毫秒。消费失败重试Kafka消费失败不支持重试。RocketMQ消费失败支持定时重试,每次重试间隔时间顺延总结:例如充值类应用,当前时刻调用运营商网关,充值失败,可能是对方压力过多,稍后再调用就会成功,如支付宝到银行扣款也是类似需求。这里的重试需要可靠的重试,即失败重试的消息不因为Consumer宕机导致丢失。严格的消息顺序Kafka支持消息顺序,但是一台Broker宕机后,就会产生消息乱序RocketMQ支持严格的消息顺序,在顺序消息场景下,一台Broker宕机后,发送消息会失败,但是不会乱序Mysql Binlog分发需要严格的消息顺序定时消息Kafka不支持定时消息RocketMQ支持两类定时消息开源版本RocketMQ仅支持定时Level,定时Level用户可定制阿里云ONS支持定时Level,以及指定的毫秒级别的延时时间分布式事务消息Kafka不支持分布式事务消息阿里云ONS支持分布式定时消息,未来开源版本的RocketMQ也有计划支持分布式事务消息消息查询Kafka不支持消息查询RocketMQ支持根据Message Id查询消息,也支持根据消息内容查询消息(发送消息时指定一个Message Key,任意字符串,例如指定为订单Id)总结:消息查询对于定位消息丢失问题非常有帮助,例如某个订单处理失败,是消息没收到还是收到处理出错了。消息回溯Kafka理论上可以按照Offset来回溯消息RocketMQ支持按照时间来回溯消息,精度毫秒,例如从一天之前的某时某分某秒开始重新消费消息总结:典型业务场景如consumer做订单分析,但是由于程序逻辑或者依赖的系统发生故障等原因,导致今天消费的消息全部无效,需要重新从昨天零点开始消费,那么以时间为起点的消息重放功能对于业务非常有帮助。消费并行度Kafka的消费并行度依赖Topic配置的分区数,如分区数为10,那么最多10台机器来并行消费(每台机器只能开启一个线程),或者一台机器消费(10个线程并行消费)。即消费并行度和分区数一致。RocketMQ消费并行度分两种情况顺序消费方式并行度同Kafka完全一致乱序方式并行度取决于Consumer的线程数,如Topic配置10个队列,10台机器消费,每台机器100个线程,那么并行度为1000。消息轨迹Kafka不支持消息轨迹阿里云ONS支持消息轨迹开发语言友好性Kafka采用Scala编写RocketMQ采用Java语言编写Broker端消息过滤Kafka不支持Broker端的消息过滤RocketMQ支持两种Broker端消息过滤方式根据Message Tag来过滤,相当于子topic概念向服务器上传一段Java代码,可以对消息做任意形式的过滤,甚至可以做Message Body的过滤拆分。消息堆积能力理论上Kafka要比RocketMQ的堆积能力更强,不过RocketMQ单机也可以支持亿级的消息堆积能力,我们认为这个堆积能力已经完全可以满足业务需求。开源社区活跃度Kafka社区更新较慢RocketMQ的github社区有250个个人、公司用户登记了联系方式,QQ群超过1000人。成熟度Kafka在日志领域比较成熟RocketMQ在阿里集团内部有大量的应用在使用,每天都产生海量的消息,并且顺利支持了多次天猫双十一海量消息考验,是数据削峰填谷的利器。

王晨纯 2019-12-02 01:44:21 0 浏览量 回答数 0

回答

分布式事务的解决方案有如下几种: 全局消息基于可靠消息服务的分布式事务TCC最大努力通知方案1:全局事务(DTP模型)全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务,需要三种角色: AP:Application 应用系统 它就是我们开发的业务系统,在我们开发的过程中,可以使用资源管理器提供的事务接口来实现分布式事务。 TM:Transaction Manager 事务管理器 分布式事务的实现由事务管理器来完成,它会提供分布式事务的操作接口供我们的业务系统调用。这些接口称为TX接口。事务管理器还管理着所有的资源管理器,通过它们提供的XA接口来同一调度这些资源管理器,以实现分布式事务。DTP只是一套实现分布式事务的规范,并没有定义具体如何实现分布式事务,TM可以采用2PC、3PC、Paxos等协议实现分布式事务。RM:Resource Manager 资源管理器 能够提供数据服务的对象都可以是资源管理器,比如:数据库、消息中间件、缓存等。大部分场景下,数据库即为分布式事务中的资源管理器。资源管理器能够提供单数据库的事务能力,它们通过XA接口,将本数据库的提交、回滚等能力提供给事务管理器调用,以帮助事务管理器实现分布式的事务管理。XA是DTP模型定义的接口,用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力。DTP只是一套实现分布式事务的规范,RM具体的实现是由数据库厂商来完成的。有没有基于DTP模型的分布式事务中间件?DTP模型有啥优缺点?方案2:基于可靠消息服务的分布式事务这种实现分布式事务的方式需要通过消息中间件来实现。假设有A和B两个系统,分别可以处理任务A和任务B。此时系统A中存在一个业务流程,需要将任务A和任务B在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。 title 在系统A处理任务A前,首先向消息中间件发送一条消息消息中间件收到后将该条消息持久化,但并不投递。此时下游系统B仍然不知道该条消息的存在。消息中间件持久化成功后,便向系统A返回一个确认应答;系统A收到确认应答后,则可以开始处理任务A;任务A处理完成后,向消息中间件发送Commit请求。该请求发送完成后,对系统A而言,该事务的处理过程就结束了,此时它可以处理别的任务了。 但commit消息可能会在传输途中丢失,从而消息中间件并不会向系统B投递这条消息,从而系统就会出现不一致性。这个问题由消息中间件的事务回查机制完成,下文会介绍。消息中间件收到Commit指令后,便向系统B投递该消息,从而触发任务B的执行;当任务B执行完成后,系统B向消息中间件返回一个确认应答,告诉消息中间件该消息已经成功消费,此时,这个分布式事务完成。上述过程可以得出如下几个结论: 消息中间件扮演者分布式事务协调者的角色。 系统A完成任务A后,到任务B执行完成之间,会存在一定的时间差。在这个时间差内,整个系统处于数据不一致的状态,但这短暂的不一致性是可以接受的,因为经过短暂的时间后,系统又可以保持数据一致性,满足BASE理论。 上述过程中,如果任务A处理失败,那么需要进入回滚流程,如下图所示: title 若系统A在处理任务A时失败,那么就会向消息中间件发送Rollback请求。和发送Commit请求一样,系统A发完之后便可以认为回滚已经完成,它便可以去做其他的事情。消息中间件收到回滚请求后,直接将该消息丢弃,而不投递给系统B,从而不会触发系统B的任务B。此时系统又处于一致性状态,因为任务A和任务B都没有执行。 上面所介绍的Commit和Rollback都属于理想情况,但在实际系统中,Commit和Rollback指令都有可能在传输途中丢失。那么当出现这种情况的时候,消息中间件是如何保证数据一致性呢?——答案就是超时询问机制。 title 系统A除了实现正常的业务流程外,还需提供一个事务询问的接口,供消息中间件调用。当消息中间件收到一条事务型消息后便开始计时,如果到了超时时间也没收到系统A发来的Commit或Rollback指令的话,就会主动调用系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果: 提交 若获得的状态是“提交”,则将该消息投递给系统B。回滚 若获得的状态是“回滚”,则直接将条消息丢弃。处理中 若获得的状态是“处理中”,则继续等待。消息中间件的超时询问机制能够防止上游系统因在传输过程中丢失Commit/Rollback指令而导致的系统不一致情况,而且能降低上游系统的阻塞时间,上游系统只要发出Commit/Rollback指令后便可以处理其他任务,无需等待确认应答。而Commit/Rollback指令丢失的情况通过超时询问机制来弥补,这样大大降低上游系统的阻塞时间,提升系统的并发度。 下面来说一说消息投递过程的可靠性保证。 当上游系统执行完任务并向消息中间件提交了Commit指令后,便可以处理其他任务了,此时它可以认为事务已经完成,接下来消息中间件一定会保证消息被下游系统成功消费掉!那么这是怎么做到的呢?这由消息中间件的投递流程来保证。 消息中间件向下游系统投递完消息后便进入阻塞等待状态,下游系统便立即进行任务的处理,任务处理完成后便向消息中间件返回应答。消息中间件收到确认应答后便认为该事务处理完毕! 如果消息在投递过程中丢失,或消息的确认应答在返回途中丢失,那么消息中间件在等待确认应答超时之后就会重新投递,直到下游消费者返回消费成功响应为止。当然,一般消息中间件可以设置消息重试的次数和时间间隔,比如:当第一次投递失败后,每隔五分钟重试一次,一共重试3次。如果重试3次之后仍然投递失败,那么这条消息就需要人工干预。 title title 有的同学可能要问:消息投递失败后为什么不回滚消息,而是不断尝试重新投递? 这就涉及到整套分布式事务系统的实现成本问题。 我们知道,当系统A将向消息中间件发送Commit指令后,它便去做别的事情了。如果此时消息投递失败,需要回滚的话,就需要让系统A事先提供回滚接口,这无疑增加了额外的开发成本,业务系统的复杂度也将提高。对于一个业务系统的设计目标是,在保证性能的前提下,最大限度地降低系统复杂度,从而能够降低系统的运维成本。 不知大家是否发现,上游系统A向消息中间件提交Commit/Rollback消息采用的是异步方式,也就是当上游系统提交完消息后便可以去做别的事情,接下来提交、回滚就完全交给消息中间件来完成,并且完全信任消息中间件,认为它一定能正确地完成事务的提交或回滚。然而,消息中间件向下游系统投递消息的过程是同步的。也就是消息中间件将消息投递给下游系统后,它会阻塞等待,等下游系统成功处理完任务返回确认应答后才取消阻塞等待。为什么这两者在设计上是不一致的呢? 首先,上游系统和消息中间件之间采用异步通信是为了提高系统并发度。业务系统直接和用户打交道,用户体验尤为重要,因此这种异步通信方式能够极大程度地降低用户等待时间。此外,异步通信相对于同步通信而言,没有了长时间的阻塞等待,因此系统的并发性也大大增加。但异步通信可能会引起Commit/Rollback指令丢失的问题,这就由消息中间件的超时询问机制来弥补。 那么,消息中间件和下游系统之间为什么要采用同步通信呢? 异步能提升系统性能,但随之会增加系统复杂度;而同步虽然降低系统并发度,但实现成本较低。因此,在对并发度要求不是很高的情况下,或者服务器资源较为充裕的情况下,我们可以选择同步来降低系统的复杂度。 我们知道,消息中间件是一个独立于业务系统的第三方中间件,它不和任何业务系统产生直接的耦合,它也不和用户产生直接的关联,它一般部署在独立的服务器集群上,具有良好的可扩展性,所以不必太过于担心它的性能,如果处理速度无法满足我们的要求,可以增加机器来解决。而且,即使消息中间件处理速度有一定的延迟那也是可以接受的,因为前面所介绍的BASE理论就告诉我们了,我们追求的是最终一致性,而非实时一致性,因此消息中间件产生的时延导致事务短暂的不一致是可以接受的。 方案3:最大努力通知(定期校对)最大努力通知也被称为定期校对,其实在方案二中已经包含,这里再单独介绍,主要是为了知识体系的完整性。这种方案也需要消息中间件的参与,其过程如下: title 上游系统在完成任务后,向消息中间件同步地发送一条消息,确保消息中间件成功持久化这条消息,然后上游系统可以去做别的事情了;消息中间件收到消息后负责将该消息同步投递给相应的下游系统,并触发下游系统的任务执行;当下游系统处理成功后,向消息中间件反馈确认应答,消息中间件便可以将该条消息删除,从而该事务完成。上面是一个理想化的过程,但在实际场景中,往往会出现如下几种意外情况: 消息中间件向下游系统投递消息失败上游系统向消息中间件发送消息失败对于第一种情况,消息中间件具有重试机制,我们可以在消息中间件中设置消息的重试次数和重试时间间隔,对于网络不稳定导致的消息投递失败的情况,往往重试几次后消息便可以成功投递,如果超过了重试的上限仍然投递失败,那么消息中间件不再投递该消息,而是记录在失败消息表中,消息中间件需要提供失败消息的查询接口,下游系统会定期查询失败消息,并将其消费,这就是所谓的“定期校对”。 如果重复投递和定期校对都不能解决问题,往往是因为下游系统出现了严重的错误,此时就需要人工干预。 对于第二种情况,需要在上游系统中建立消息重发机制。可以在上游系统建立一张本地消息表,并将 任务处理过程 和 向本地消息表中插入消息 这两个步骤放在一个本地事务中完成。如果向本地消息表插入消息失败,那么就会触发回滚,之前的任务处理结果就会被取消。如果这量步都执行成功,那么该本地事务就完成了。接下来会有一个专门的消息发送者不断地发送本地消息表中的消息,如果发送失败它会返回重试。当然,也要给消息发送者设置重试的上限,一般而言,达到重试上限仍然发送失败,那就意味着消息中间件出现严重的问题,此时也只有人工干预才能解决问题。 对于不支持事务型消息的消息中间件,如果要实现分布式事务的话,就可以采用这种方式。它能够通过重试机制+定期校对实现分布式事务,但相比于第二种方案,它达到数据一致性的周期较长,而且还需要在上游系统中实现消息重试发布机制,以确保消息成功发布给消息中间件,这无疑增加了业务系统的开发成本,使得业务系统不够纯粹,并且这些额外的业务逻辑无疑会占用业务系统的硬件资源,从而影响性能。 因此,尽量选择支持事务型消息的消息中间件来实现分布式事务,如RocketMQ。 方案4:TCC(两阶段型、补偿型)TCC即为Try Confirm Cancel,它属于补偿型分布式事务。顾名思义,TCC实现分布式事务一共有三个步骤: Try:尝试待执行的业务 这个过程并未执行业务,只是完成所有业务的一致性检查,并预留好执行所需的全部资源Confirm:执行业务 这个过程真正开始执行业务,由于Try阶段已经完成了一致性检查,因此本过程直接执行,而不做任何检查。并且在执行的过程中,会使用到Try阶段预留的业务资源。Cancel:取消执行的业务 若业务执行失败,则进入Cancel阶段,它会释放所有占用的业务资源,并回滚Confirm阶段执行的操作。下面以一个转账的例子来解释下TCC实现分布式事务的过程。 假设用户A用他的账户余额给用户B发一个100元的红包,并且余额系统和红包系统是两个独立的系统。 Try 创建一条转账流水,并将流水的状态设为交易中将用户A的账户中扣除100元(预留业务资源)Try成功之后,便进入Confirm阶段Try过程发生任何异常,均进入Cancel阶段Confirm 向B用户的红包账户中增加100元将流水的状态设为交易已完成Confirm过程发生任何异常,均进入Cancel阶段Confirm过程执行成功,则该事务结束Cancel 将用户A的账户增加100元将流水的状态设为交易失败在传统事务机制中,业务逻辑的执行和事务的处理,是在不同的阶段由不同的部件来完成的:业务逻辑部分访问资源实现数据存储,其处理是由业务系统负责;事务处理部分通过协调资源管理器以实现事务管理,其处理由事务管理器来负责。二者没有太多交互的地方,所以,传统事务管理器的事务处理逻辑,仅需要着眼于事务完成(commit/rollback)阶段,而不必关注业务执行阶段。 TCC全局事务必须基于RM本地事务来实现全局事务TCC服务是由Try/Confirm/Cancel业务构成的, 其Try/Confirm/Cancel业务在执行时,会访问资源管理器(Resource Manager,下文简称RM)来存取数据。这些存取操作,必须要参与RM本地事务,以使其更改的数据要么都commit,要么都rollback。 这一点不难理解,考虑一下如下场景: title 假设图中的服务B没有基于RM本地事务(以RDBS为例,可通过设置auto-commit为true来模拟),那么一旦[B:Try]操作中途执行失败,TCC事务框架后续决定回滚全局事务时,该[B:Cancel]则需要判断[B:Try]中哪些操作已经写到DB、哪些操作还没有写到DB:假设[B:Try]业务有5个写库操作,[B:Cancel]业务则需要逐个判断这5个操作是否生效,并将生效的操作执行反向操作。 不幸的是,由于[B:Cancel]业务也有n(0<=n<=5)个反向的写库操作,此时一旦[B:Cancel]也中途出错,则后续的[B:Cancel]执行任务更加繁重。因为,相比第一次[B:Cancel]操作,后续的[B:Cancel]操作还需要判断先前的[B:Cancel]操作的n(0<=n<=5)个写库中哪几个已经执行、哪几个还没有执行,这就涉及到了幂等性问题。而对幂等性的保障,又很可能还需要涉及额外的写库操作,该写库操作又会因为没有RM本地事务的支持而存在类似问题。。。可想而知,如果不基于RM本地事务,TCC事务框架是无法有效的管理TCC全局事务的。 反之,基于RM本地事务的TCC事务,这种情况则会很容易处理:[B:Try]操作中途执行失败,TCC事务框架将其参与RM本地事务直接rollback即可。后续TCC事务框架决定回滚全局事务时,在知道“[B:Try]操作涉及的RM本地事务已经rollback”的情况下,根本无需执行[B:Cancel]操作。 换句话说,基于RM本地事务实现TCC事务框架时,一个TCC型服务的cancel业务要么执行,要么不执行,不需要考虑部分执行的情况。 TCC事务框架应该提供Confirm/Cancel服务的幂等性保障一般认为,服务的幂等性,是指针对同一个服务的多次(n>1)请求和对它的单次(n=1)请求,二者具有相同的副作用。 在TCC事务模型中,Confirm/Cancel业务可能会被重复调用,其原因很多。比如,全局事务在提交/回滚时会调用各TCC服务的Confirm/Cancel业务逻辑。执行这些Confirm/Cancel业务时,可能会出现如网络中断的故障而使得全局事务不能完成。因此,故障恢复机制后续仍然会重新提交/回滚这些未完成的全局事务,这样就会再次调用参与该全局事务的各TCC服务的Confirm/Cancel业务逻辑。 既然Confirm/Cancel业务可能会被多次调用,就需要保障其幂等性。 那么,应该由TCC事务框架来提供幂等性保障?还是应该由业务系统自行来保障幂等性呢? 个人认为,应该是由TCC事务框架来提供幂等性保障。如果仅仅只是极个别服务存在这个问题的话,那么由业务系统来负责也是可以的;然而,这是一类公共问题,毫无疑问,所有TCC服务的Confirm/Cancel业务存在幂等性问题。TCC服务的公共问题应该由TCC事务框架来解决;而且,考虑一下由业务系统来负责幂等性需要考虑的问题,就会发现,这无疑增大了业务系统的复杂度。

1210119897362579 2019-12-02 00:14:25 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

ReFtp4oss(只需配置、不用写代码)完美兼容DiscuzX、phpwind、wordpress等网站 Ftp4oss 官方网址:http://www.ftp4oss.com/   2013年阿里云开发者大赛 决赛20强作品,欢迎大家的支持!非常感谢! Ftp4oss是目前阿里云生态环境中已提供的 最简单的OSS专用的FTP服务;只需10分钟配置、不用写代码,普通站长即可快速地使用上阿里云OSS云存储的一个应用级FTP服务,同时提供安全的FTP快速中转服务,符合OSS云安全理念! 1、上传文件快速无延时、无停顿感(仅受限于用户家庭ADSL的上传瓶颈)! 2、完美兼容DiscuzX、phpwind、wordpress等网站系统(这里有各种演示和试用哦 ),理论上支持所有设计有远程附件的FTP站点, 网站升级再也不用发愁了! 3、不用服务器环境配置、不用看黑界面、不用安装程序……都不用,只需要网站注册账户、三步网站操作获得FTP服务、远程附件配置即可! 4、……还有各种优势等您去帮大家发现! 快来选择Ftp4oss吧!请点击www.ftp4oss.com  详细了解,并使用FTP for OSS服务吧! 注册Ftp4oss账户 三步网站操作,10分钟快速拥有FTP服务: 第一步:输入OSS Access Key和Access Secret; 第二步:选择Bucket或者新创建一个Bucket; 第三步:输入Ftp用户名和Ftp密码; 即可获得FTP服务,立即用FlashXP、FtpRush、FileZilla等客户端软件登录测试(能创建文件夹、上传文件夹、上传文件等) 下图所示: 测试左侧上传一个文件,然后在右侧的上部您是 看不到该文件(但是文件已经成功到OSS了)的(故而您也无法做出删除操作),但是您可以从右下部显示的文件已经成功上传到OSS上了,您可以点击该URL链接来查看! 把Ftp4oss服务应用到您的爱站,详细配置可参考:http://www.ftp4oss.com/help/UsefulSitesHelp.htm —————————————————————————————————————————————————————————— 1、安全的云FTP 考虑到OSS的安全特点,我们特意屏蔽了部分FTP功能,比如默认账户权限只具有创建文件夹、上传文件、删除文件等功能,但是屏蔽了危险的删除文件夹等操作——这些功能已经能满足市面常见网站系统的远程附件要求,同时避免账号泄漏带来的风险; 2、网站用户登录安全:网站的介绍页面采用静态发布,而用户登录、账户管理等交互页面采用SSL的Https安全协议,尽最大努力保护用户的信息安全; 3、关键信息加密:用户口令MD5不可逆加密传输与保存,用户的OSS Access密码采用动态密钥加密后存储,数据库连接字符串加密,即使网站数据库被黑客入侵也无法获得用户的关键信息; 4、高性能缓存转换:针对ECS的磁盘性能低效情况,我们首创缓存转换设计,即在FTP上传文件过程中,直接保存该文件流到缓存中,并不写入系统磁盘,而是缓存转换后通过OSS的SDK直接传到OSS上,实现高性能设计; 注:用户—站长的网站—Ftp4oss—OSS各角色之间的关系,其中红色背景的是Ftp4oss. Ftp4oss程序实现了基本的FTP服务器的功能,监听网站服务器的FTP连接请求,当普通用户向网站提交图片、附件的时候(注1), 网站服务器接收后会及时自动的通过FTP连接、发送到Ftp4oss服务器(注2), Ftp4oss程序即刻应答并接收该文件,并通过OSS的SDK同步到OSS上(注3), 这个过程就是用户上传图片到网站服务器后通过Ftp4oss同步到OSS的过程,整个过程对于用户来说是透明的,由于阿里云内网时延低、带宽在2G以上,所以对于用户上传一张1M的图片多耗费的时间均在1秒以内,其时间等候体验基本是相同的。 当用户访问网站的时候,直接下载了网站服务器的网页内容,该网页的图片、附件则直接从OSS高速下载到用户的浏览器上(注4); ------------------------- ReFtp4oss(只需配置、不用写代码)完美兼容DiscuzX、phpwind、wordpress等网站 我们欢迎阿里云ECS、OSS、RDS等各种为站长网站服务的作品与我们合作,大家互相支持、互相推广,更好的为广大站长们提供一体化解决方案! 首先,我们欢迎OSS的客户端工具与我们合作推广,希望您作品成熟、功能完善,安装部署简单! 因为我们的作品是专门为网站的远程附件服务的,所以特意屏蔽了FTP的部分功能,所以站长无法通过FTP客户端软件完全管理OSS上的文件(即使我们开放了FTP的所有功能,其效率也是如果OSS客户端软件直连OSS的效率高) 所以, 我们欢迎OSS工具的作者与我们合作,您不一定能给我们带来用户,但是我们是肯定可以为您带去用户的!   其它作品作者也欢迎与我们合作推广! http://www.ftp4oss.com/ 首页底部有联系我们的方法! ------------------------- 回4楼mrznz的帖子 非常感谢版主的支持! 您的建议“为附件添加HTTP头信息 Expires与Cache-control的选项”我们会加入下一步的改进计划(如果OSS的C# SDK有支持的话)~~~ ------------------------- 回7楼mayle的帖子 接受版主的批评~~~ 另:我们的产品确实已经上线,我们在提交阿里云审核的时候,已有一个多月的内测了(主要针对的是Disucz和phpwind系统) ------------------------- 回8楼cuinew的帖子 谢谢老兄的支持! ------------------------- 回6楼牛逼王的帖子 谢谢支持~~~ ------------------------- 回12楼cuinew的帖子 嗯,这个问题确实存在,某些逻辑未处理好,我们会改进的,下一个版本将解决这个问题~~~ ------------------------- 回14楼susan20120530的帖子 谢谢管理员的支持!非常感谢! ------------------------- 回23楼mrznz的帖子 您放心,HTTP头的信息添加这两天就放出来了; 本次更新的内容较多,加上这周有3天时间出差到上海参加了华为的云计算世界大会耽搁了点时间 预计您提的建议,明天晚上可以完成,我们测试没问题 后联系你~~~ ------------------------- 回22楼kylin30的帖子 谢谢您的夸奖~~~这让我们有更多的动力把Ftp4oss做的更好~~~ ------------------------- Re第111号作品:Ftp4oss(只需三步网站配置,不需配置环境、不用写代码) 顶起来,希望得到大家的支持哦~~~ ------------------------- 回30楼daigoubu的帖子 确实很方便,感谢支持! ------------------------- 回31楼司徒尔特的帖子 信息不详细者或者无法联系上的,均不能通过审核~~~~ 为了保障服务,初步了解用户站点请求压力情况和避免恶意注册占用资源,才增加了信息审核一关,请放心使用,感谢支持~~~ ------------------------- 回36楼孤独小超的帖子 您好,Ftp4oss目前推出的 FTP云服务和FTP云工具一直都是免费的呀,包括即将推出的Linux版本云工具和OSS客户端等产品也都将是免费的,并且今后也将持续提供这些免费产品来满足大部分用户的使用; FTP云服务的免费的单文件上传大小限制 故意比 FTP云工具的要小,目的就是尽量引导有需要的用户使用FTP云工具,这样可以减轻我们的服务器压力。 部分增值功能预留给收费版本也是为了将来有一点点收入来维持我们的持续研发和运维; 很多用户支持收费说只有收费才能信任我们的产品和服务,但是也有一部分用户反对我们收费,希望提供全功能的免费产品,这对我们真是一个两难的选择啊;这两个极端是实事,我们也理解. ------------------------- 回38楼孤独小超的帖子 FTP云工具链接OSS的方式,是由用户自由设定的; 如果设定由内网通信,则该工具必须运行在对应的ECS服务器上;如果设定外网通信,则运行物理位置不限制; 如您的需求为了省下流量费用,则可以把FTP云工具设置为内网模式,并运行在对应节点的ECS服务器上,那么上传、下载(下载功能在新版本会提供)确实不占用OSS的外网流量; 您可以到基础工具频道下载一个试用看看,谢谢您的支持! ------------------------- 回44楼老残的帖子 您好,感谢支持啊 Linux版本的Ftp4oss云工具快完成了,目前进度在跨Linux版本运行上存在点问题,我们尽快解决; 原来计划年内发布,现在看样子得推迟到年后再发布了~~~ ------------------------- 感谢支持~~~ ------------------------- 回47楼老残的帖子 很可能是你粘贴的IP、用户名或者密码两端存在空格引起的~~~~ 你加我们的技术客服QQ 1487960688 ,人工协助你看一下问题原因~~~ ------------------------- 回51楼老残的帖子 能用了就好 ------------------------- 回 53楼(centaurus) 的帖子 支持Linux系统的版本从月初延迟到月底,不过本周已经开始内测了,计划本周末开始邀请部分Ftp4oss用户一起测试,测试结束后,完善程序后即可发布。有望在3月上旬发布,敬请期待! ------------------------- 回 54楼(疯少) 的帖子 您好,请问您用的是哪一套网站系统?目前使用的是Ftp4oss的哪一个产品(FTP云工具还是FTP云服务?) 如果方便的话,请加我的QQ 1487960688 ,我来帮你定位故障的原因~~~ 感谢您的支持! ------------------------- 回 58楼(yxfwz) 的帖子 您好,您可以加QQ 1487960688 反映注册情况哦 一般我们都是在1--2天之内完成审核工作的。另外,如果你注册的是FTP云工具类型的账户,则无需审核即可直接登录软件了; http://bbs.aliyun.com/read/152856.html ------------------------- 顶起啦,希望大家多多支持! ------------------------- 回 65楼(薇薇luo) 的帖子 你的ftp4oss注册通知邮件里面有客服QQ,你可以联系一下 ------------------------- 2014年6月19日(应该是5月28日才对)更新,请点击:  [分享]发布:支持OSS的FTP云工具稳定版V1.0(Linux版——Ftp4oss出品) ------------------------- 回 71楼(amu) 的帖子 你好,FTP云服务(在线的FTP服务)为了尽量的提高安全性,所以设计上屏蔽了文件列表显示,但是整体功能并不影响网站远程附件的使用; 如果您是人工操作OSS的话,现在你可以有两种选择: 1、选择使用FTP云工具——类似FTP云服务,但是增加了文件列表、下载、删除等功能; 支持OSS的FTP云工具Linux版本 http://market.aliyun.com/product/12-121590002-cmgj000207.html 支持OSS的FTP云工具Windows版本 http://market.aliyun.com/product/12-121590002-cmgj000208.html 2、选择使用OssExplorer——OSS的专用客户端,方便OSS上的文件管理! [分享]OssExplorer(OSS专用客户端)http://bbs.aliyun.com/read/161263.html ------------------------- 回 75楼(nydalu) 的帖子 您好,可以联系我们技术客服的QQ,以便协助你找一下原因~~~ 这个是我们刚刚通过Ftp4oss上传了png图片的一个效果,请你查看 http://ftp4oss.oss-cn-hangzhou.aliyuncs.com/2011121417032133245.png 我们这边测试是正常的哦 ------------------------- 回 77楼(cbiz100) 的帖子 您好,近期阿里云ECS增加了很多Linux版本,我们还未做兼容性测试; 详细的系统支持请见介绍: http://market.aliyun.com/product/12-121590002-cmgj000207.html?spm=0.0.0.0.cceFhh#user_comments 1、你这里提到的是32位系统,请你下载32位版本自行测试看看,不一定兼容;(下载和配置地址 http://bbs.aliyun.com/read/154294.html?spm=5176.7189909.0.0.tuCDe9) 2、目前的FTP云工具只能支持一个账号而已(下一个升级版本有考虑到这个多用户的支持); 3、近期还不能支持七牛。 您可以更简单的选择我们的FTP云服务,对系统不作要求,直接使用我们提供的在线FTP云服务。 ------------------------- [分享]★★★   OssExplorerOSS客户端正式发布了——Ftp4oss出品 ------------------------- 回 83楼(云通) 的帖子 你好,你说的Linux版本是哪个工具呢? ------------------------- Re:★★CT团队出品:Ftp4oss阿里云OSS最好用的FTP云工具、客户端和文件同步 .. www.ftp4oss.com 现更改为 www.ct.cc   "Ftp4oss团队"现更名为"CT团队" ------------------------- Re:★★CT团队出品:Ftp4oss阿里云OSS最好用的FTP云工具、客户端和文件同步 .. 支持支持! ------------------------- 回 87楼(晓庄) 的帖子 当然可以修改产品类型了,我们的帐号注册后通行我们开发的所有产品~~~ ------------------------- 回 89楼(晓庄) 的帖子 估计是您的注册信息缺失太多,导致未能通过审核,虽然不影响您的工具类产品的使用,但是无法登陆网站; 您可以联系我们的QQ技术(到www.ct.cc获取联系方法)协助您处理,审核通过后即可登陆网站更新类型了; ------------------------- 回 90楼(itdashen) 的帖子 联系我们的QQ技术(到www.ct.cc获取联系方法)协助您查看原因! ------------------------- Re:★★CT团队出品:Ftp4oss阿里云OSS最好用的FTP云工具、客户端和文件同步 .. 不同的工具采用不同的SDK,也有直接自己封装API的; ------------------------- 回 96楼(bigoo) 的帖子 如果你的文件夹555下有图片的话,那么你直接FTP上传图片或者整个文件夹的话,肯定是没有问题的,这个只是最最基本的功能而已! 根据你的描述,很可能你连接的FTP很可能只是你自己的传统FTP服务器,而不是我们提供的Ftp4oss~~ 建议发个FTP连接IP的截图看看,如有需要,也可以请联系技术QQ 1020736080 协助你看看~~~ ------------------------- 回 98楼(bigoo) 的帖子 你的这么多截图都看不到重点的交互,你的楼上也给你留了协助联系方式,不过你也没联系,我们也联系不到你,呵呵;论坛帖子留言是反馈问题,不是解决问题的最佳方式~~~ 我们的Ftp4oss一年多了用户反映兼容性还是不错的,期待你能和我们联系,可以和你一起看看你那边有什么特殊的情况; ------------------------- 回 101楼(晓庄) 的帖子 你好,FTP云服务默认给的是10M的全局大小;而FTP云工具默认是2M,采用Ftp4oss帐号登陆则默认为10M,还可以免费授权大于10M的上传; ------------------------- Re:★★CT团队出品:Ftp4oss阿里云OSS最好用的FTP云工具、客户端和文件同步 .. 楼上用户已联系技术客服沟通完毕; 说明:现有的FTP云服务支持10M以下的文件上传,需要传输大小10M的文件,需要选用FTP云工具;

ftp4oss 2019-12-02 02:03:28 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 企业建站模板