为什么我的98系统在下载大一点的文件时就会死机？在线等待......

xyqdp 2003-10-16 11:12:34

为什么我的98系统在下载大一点的文件时就会死机？是不是跟网卡有关系，还是系统不身的问题，或是其他的硬件问题？各位高手请帮忙！急急！！！

...全文

96 10 打赏收藏转发到动态举报

写回复

10 条回复

切换为时间正序

请发表友善的回复…

发表回复

kbkingbird 2003-10-19

打赏
举报

回复

NT/2000的每一个进程都在启动时分配了4GB（0xFFFFFFFF）的虚拟内存。其中的某些部份实际上是由所有进程共享的，例如核心和设备驱动程序区域。但它们都会被映射到每个进程的虚拟地址空间里。实际上没有进程分配到4GB的物理内存，而是仅当需要时才分配物理内存。因此每一个进程都有各自的4GB虚拟内存，编址范围从0x00000000到0xFFFFFFFF。其中，0x00000000－0x0000FFFF是为NULL指针分配而保留的。访问该区域内存将导致“非法访问”错误。0x00010000－0x7FFEFFFF是用户进程空间。EXE文件的映像被加载到其中（起始地址0x00400000），DLL（动态链接库）也被加载到这部份空间。如果DLL或EXE的代码被装入到该范围的某些地址，就能够被执行。访问该区域中没有代码装入的地址将导致“非法访问”错误。0x7FFF0000－0x7FFFFFFF是保留区域，对此区域的任何访问都将导致“非法访问”错误。0x80000000－0xFFFFFFFF仅供操作系统使用。用于加载设备驱动程序和其它核心级代码。从用户级应用程序（ring 3）访问此区域将导致“非法访问”错误。

回炉重造，学习编程中。。。 2003-10-19

打赏
举报

回复

重装系统试试，另外你的机器什么配置

----------------------------------------
宠辱不惊，坐看庭前花开花落；
去留无意，漫随天上云卷云舒；
----------------------------------------

bigcar 2003-10-18

打赏
举报

回复

:)

lello1234 2003-10-18

打赏
举报

回复

可能是你的机器的内存太小了！~
还有CPU

liuchangchun1998 2003-10-17

打赏
举报

回复

您好！我的电脑装的是windows2000专业版，系统连接局域网，打开D盘的一个文件夹时，总出现explorer.exe -应用程序错误，"0X780127a8"指令引用的"0X00000000"内存，该内存不能为"written",要终止程序，请单击“确定“，调试程序，请单击“取消”。我选择任何一个选相都会关闭该文件夹。但用其他程序如realone player却可调得出该文件夹中的文件，我该如何解决呢？期待您的回音！
刘长春 <liuchangchun1998@sohu.com>

mjlwt 2003-10-17

打赏
举报

回复

机器配置低的原因。

powersaving 2003-10-17

打赏
举报

回复

换个好网卡吧！

csdnzl 2003-10-17

打赏
举报

回复

是不是机器配置低了

kevinliuu 2003-10-16

打赏
举报

回复

是不是用网际快车（flashget）下载的呢？如果是的话，下载大文件（几百兆以上）的时候，flashget先会读取远端文件的大小，然后在本机分配出一部分同样大小的空间，这段时间视硬件环境而决定，一般这段时间机器会没有任何反映，就像死机，等等会好的。

xyqdp 2003-10-16

打赏
举报

回复

我不是用网际快车（flashget）下载的，而是直接用另存为下载的。

购买提醒：全程代码实战，本系列课程建议有Java开发经验2年以上的学员观看和购买。录制本套教程的初衷，通过从业10年接触过很多的技术开发人员，尤其在面试一些技术人员的时候，发现他们的技术知识更新较慢，很多人渴望接触到高并发系统和一些高级技术架构，为了帮助更多人能够提升自己和接触到这类技术架构，并满足企业的人才需求，利用业余时间我开始录制这套教程。通过录制教程有很多学员给我反馈信息，给了我很大的鼓舞，当然也有吐槽，我想说的是技术是没有边界的，脱离一线业务场景去谈技术，都是耍流氓的。如对我录制的教程内容有建议请及时交流。本套课程历经1年时间研发，案例来源于真实业务场景抽离，由从业10年企业一线架构师实录，没有基础不建议购买。购买后提供企业级多方位指导，通过本套案例可以让你学习目前主流的微服务技术架构和多种企业级高并发和海量数据、高可用、分布式、支付、多语言、前后端分离等技术的综合应用解决方案。在开始本课程前给大家科普几个概念: 高并发是指在比较短的时间内有大量的访问者访问目标系统，系统负载饱和或者过载宕机。高并发的应用，我们应该都有用过或者见过，比如天猫、京东、拼多多、亚马逊的秒杀抢购还有12306的抢票。我们在体验应用的时候，可能并不会像到这种高并发系统背后的技术实现难度。高并发系统都存在这几种问题，高并发读、高并发写、访问高峰突发性、反馈结果的即时性。在抢购的时候，尤其是抢购火车票的时候，我们经常会疯狂的刷库存，几亿用户产生非常大的高并发读；通过以上的科普相信大家对课程有一个基本的认知了，本套教程以应用最为广泛的电商系统为标本，给大家构建一个亿级微服务秒杀系统，让大家跟着我的步骤能学习行为背后的原理。本课程采用全新的微服务架构，运用了很多工业界企业解决方案和高级技术，带大家手把手实现一个高性能，高并发，高可用等的亿级微服务秒杀系统，本课程会包含很多高级的内容，比如微服务架构、分布式部署方案、多线程、支付、多语言、全链路性能压力测试等，让大家在实战中学习知识，在实战中不断进步。该课程是一个完整的微服务架构秒杀系统项目代码，案例具有很高的商业价值，大家可以根据自己的业务进行修改,便可以使用。本套课程可以满足世面上绝大多数企业级的业务场景，本课程全部代码可以直接部署企业，普通集群，支撑**并发；集群规模大，支撑亿级并发。本课程包含的技术： IDEA集成开发工具 SpringBoot2.0.2.RELEASE SpringCloudFinchley.RELEASE Thymeleaf（模板引擎技术）微信支付支付宝支付银联支付分布式数据库Mycat MySQL Druid RabbitMQ 分布式事务分布式锁事件驱动多线程 MyBatis QuartzEhcache Redis Hystrix 单点登陆CAS Nginx Lua Restful AOP技术性能压力测试Jemter VUE+jQuery+Ajax+NodeJS Python Go语言课程亮点： 1.与企业无缝对接、真实工业界产品 2.主流支付全覆盖（微信、支付宝、银联） 3.前后端分离（主流技术架构） 4.实现高并发请求和实现高可用架构解决方案 5.多语言（Java、Go、Python） 6.亿级微服务秒杀系统（支撑海量数据） 7.大型系统分布式部署方案 8.全链路性能压力测试 9.分布式事务解决方案 10.事件驱动设计解决方案 11.多线程技术的实战应用 12.高并发下的服务降级、限流实战 13.分布式架构师下实现分布式定时调度 14.集成MyBatis实现多数据源路由实战 15.集成Redis缓存实战 16.Eureka注册中心 17.OpenFeign声明式服务调用 18.Hystrix服务熔断降级方式 19.基于Hystrix实现接口降级实战 20.集成SpringCloud实现统一整合方案 21.全程代码实操，提供全部代码和资料 22.提供答疑和提供企业技术方案咨询购买提醒：我本人在企业从业10年，因为热爱，所以坚持，下一个10年依然会在企业一线服务，因此对于课程中的技术点可以提供全方面的业务场景解决方案。我本人并非培训机构脱离一线业务场景的讲师，从业多年接触过大量的真实业务场景案例，后面会逐步通过教程案例分享我多年的实战经验，送给同行一句话：技术是服务于业务的，脱离一线业务场景就是耍流氓。

什么是共识算法背景分布式系统集群设计中面临着一个不可回避的问题，一致性问题对于系统中的多个服务节点，给定一系列操作，如何试图使全局对局部处理结果达成某种程度的一致？这个一致性问题大致有如下的场景：节点之间通讯不可靠的，延迟和阻塞节点的处理可能是错误的，甚至节点自身随时可能宕机节点作恶举例说明，就比如有两家电影院同时售卖总量一定的电影票，在这样的场景下，要如何设计方式来保证两家电影院协调同步不出现超卖或者错卖的问题呢？共识算法，就是解决对某一提案（目标，投票等各种协作工作），大家达成一致意见的过程比如上述的买票问题，就可以有如下的设计：1.每次卖票打电话给其他电影院，确认当前票数2.协商售卖时间，比如一三五A卖，二四六B卖3.成立个第三方存票机构，它统一发票通过以上的设计，可以看出一个很重要的解决一致性算法的解决思路，即：将可能引发不一致的并行操作进行串行化，就是现在计算机系统里处理分布式一致性问题基础思路和唯一秘诀著名的共识设计理论FLP 不可能性原理共识算法的理论下限提出该定理的论文是由 Fischer, Lynch 和 Patterson 三位作者于 1985 年发表，该论文后来获得了 Dijkstra（就是发明最短路径算法的那位）奖。FLP 原理认为对于允许节点失效情况下，纯粹异步系统无法确保一致性在有限时间内完成。三人三房间投票例子三个人在不同房间，进行投票（投票结果是 0 或者 1）。三个人彼此可以通过电话进行沟通，但经常会有人时不时地睡着。比如某个时候，A 投票 0，B 投票 1，C 收到了两人的投票，然后 C 睡着了。A 和 B 则永远无法在有限时间内获知最终的结果。如果可以重新投票，则类似情形每次在取得结果前发生带入到计算机领域就是说，即便在网络通信可靠情况下，一个可扩展的分布式系统的共识问题的下限是无解。即可靠性的下限是0%CAP 分布式系统领域的重要原理CAP 原理最早由 Eric Brewer 在 2000 年，ACM 组织的一个研讨会上提出猜想，后来 Lynch 等人进行了证明• C（一致性）：所有的节点上的数据时刻保持同步，即数据一致• A（可用性）：每个请求都能在一定时间内接受到一个响应，即低延迟• P（分区容错）：当系统发生分区时仍然可以运行的定理：任何分布式系统只可同时满足二点，没法三者兼顾。即数据一致，响应及时，可分区执行不可能同时满足。举个例子：一个分布式网路上，某一个节点有一组依赖数据A，当网络无延迟，无阻塞时，依赖于X的操作可正常进行。但网络无延迟阻塞在现实世界中是没法100%保证的，那么当网络异常时，必然会产生分布式系统的分区和孤岛，那当一个执行操作在A分区之外时，如果要保证P,即当系统发生分区时仍可运行，就需要在分布式系统中多个节点有X的备份数据，以应对分区情况。则这时候就需要在C,A之间做出选择。假如选择C，即要保证数据在分布式网络中的一致性，那么就需要在X每次改动时，需要将全网节点的X数据同步刷新成最新的状态，那么在等待数据刷新完成之前，分布式系统是不可响应X的依赖操作的，即A的功能缺失假如选择A，即要突出低延迟的实时响应。那么在响应的时候，可能全节点的X数据并没有同步到最新的状态，则会导致C的缺失。上面看上去有些绕，那么你只要记住这句话，CAP原理在分布式网络系统的应用讨论，其实就是讨论在允许网络发生故障的系统中，该选择一致性还是可靠性？如果系统重视一致性，那么可以基于ACID原则做系统设计即 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）。ACID 原则描述了对分布式数据库的一致性需求，同时付出了可用性的代价。• Atomicity：每次操作是原子的，要么成功，要么不执行；• Consistency：数据库的状态是一致的，无中间状态；• Isolation：各种操作彼此互相不影响；• Durability：状态的改变是持久的，不会失效相应的有一个BASE原则，（Basic Availiability，Soft state，Eventually Consistency）则强调了可用性。经典的共识算法设计业内，针对节点异常的情况，会有两种分类1.故障的，不响应的节点，成为非拜占庭错误2.恶意响应的节点，称为非拜占庭错误Paxos 最早的共识算法非拜占庭算法的代表Paxos有三种角色：• proposer：提出一个提案，等待大家批准为结案。客户端担任该角色；• acceptor：负责对提案进行投票。往往是服务端担任该角色；• learner：被告知结案结果，并与之统一，不参与投票过程。即普通节点系统运行由proposer驱动，当合法提案在一定时间内收到1/2以上投票后达成共识。

什么是共识算法背景分布式系统集群设计中面临着一个不可回避的问题，一致性问题对于系统中的多个服务节点，给定一系列操作，如何试图使全局对局部处理结果达成某种程度的一致？这个一致性问题大致有如下的场景：节点之间通讯不可靠的，延迟和阻塞节点的处理可能是错误的，甚至节点自身随时可能宕机节点作恶举例说明，就比如有两家电影院同时售卖总量一定的电影票，在这样的场景下，要如何设计方式来保证两家电影院协调同步不出现超卖或者错卖的问题呢？共识算法，就是解决对某一提案（目标，投票等各种协作工作），大家达成一致意见的过程比如上述的买票问题，就可以有如下的设计：1.每次卖票打电话给其他电影院，确认当前票数2.协商售卖时间，比如一三五A卖，二四六B卖3.成立个第三方存票机构，它统一发票通过以上的设计，可以看出一个很重要的解决一致性算法的解决思路，即：将可能引发不一致的并行操作进行串行化，就是现在计算机系统里处理分布式一致性问题基础思路和唯一秘诀著名的共识设计理论FLP 不可能性原理共识算法的理论下限提出该定理的论文是由 Fischer, Lynch 和 Patterson 三位作者于 1985 年发表，该论文后来获得了 Dijkstra（就是发明最短路径算法的那位）奖。FLP 原理认为对于允许节点失效情况下，纯粹异步系统无法确保一致性在有限时间内完成。三人三房间投票例子三个人在不同房间，进行投票（投票结果是 0 或者 1）。三个人彼此可以通过电话进行沟通，但经常会有人时不时地睡着。比如某个时候，A 投票 0，B 投票 1，C 收到了两人的投票，然后 C 睡着了。A 和 B 则永远无法在有限时间内获知最终的结果。如果可以重新投票，则类似情形每次在取得结果前发生带入到计算机领域就是说，即便在网络通信可靠情况下，一个可扩展的分布式系统的共识问题的下限是无解。即可靠性的下限是0%CAP 分布式系统领域的重要原理CAP 原理最早由 Eric Brewer 在 2000 年，ACM 组织的一个研讨会上提出猜想，后来 Lynch 等人进行了证明• C（一致性）：所有的节点上的数据时刻保持同步，即数据一致• A（可用性）：每个请求都能在一定时间内接受到一个响应，即低延迟• P（分区容错）：当系统发生分区时仍然可以运行的定理：任何分布式系统只可同时满足二点，没法三者兼顾。即数据一致，响应及时，可分区执行不可能同时满足。举个例子：一个分布式网路上，某一个节点有一组依赖数据A，当网络无延迟，无阻塞时，依赖于X的操作可正常进行。但网络无延迟阻塞在现实世界中是没法100%保证的，那么当网络异常时，必然会产生分布式系统的分区和孤岛，那当一个执行操作在A分区之外时，如果要保证P,即当系统发生分区时仍可运行，就需要在分布式系统中多个节点有X的备份数据，以应对分区情况。则这时候就需要在C,A之间做出选择。假如选择C，即要保证数据在分布式网络中的一致性，那么就需要在X每次改动时，需要将全网节点的X数据同步刷新成最新的状态，那么在等待数据刷新完成之前，分布式系统是不可响应X的依赖操作的，即A的功能缺失假如选择A，即要突出低延迟的实时响应。那么在响应的时候，可能全节点的X数据并没有同步到最新的状态，则会导致C的缺失。上面看上去有些绕，那么你只要记住这句话，CAP原理在分布式网络系统的应用讨论，其实就是讨论在允许网络发生故障的系统中，该选择一致性还是可靠性？如果系统重视一致性，那么可以基于ACID原则做系统设计即 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）。ACID 原则描述了对分布式数据库的一致性需求，同时付出了可用性的代价。• Atomicity：每次操作是原子的，要么成功，要么不执行；• Consistency：数据库的状态是一致的，无中间状态；• Isolation：各种操作彼此互相不影响；• Durability：状态的改变是持久的，不会失效相应的有一个BASE原则，（Basic Availiability，Soft state，Eventually Consistency）则强调了可用性。经典的共识算法设计业内，针对节点异常的情况，会有两种分类1.故障的，不响应的节点，成为非拜占庭错误2.恶意响应的节点，称为非拜占庭错误Paxos 最早的共识算法非拜占庭算法的代表Paxos有三种角色：• proposer：提出一个提案，等待大家批准为结案。客户端担任该角色；• acceptor：负责对提案进行投票。往往是服务端担任该角色；• learner：被告知结案结果，并与之统一，不参与投票过程。即普通节点系统运行由proposer驱动，当合法提案在一定时间内收到1/2以上投票后达成共识。因此，可得出无法达成共识的条件：1.proposer故障2.二分之一以上acceptor故障拜占庭问题与BFT(Byzantine Fault Tolerant) 算法Leslie Lamport 1982 年提出用来解释一致性问题的一个虚构模型。拜占庭是古代东罗马帝国的首都，由于地域宽广，守卫边境的多个将军（系统中的多个节点）需要通过信使来传递消息，达成某些一致的决定。但由于将军中可能存在叛徒（系统中节点出错），这些叛徒将努力向不同的将军发送不同的消息，试图会干扰一致性的达成。拜占庭问题即为在此情况下，如何让忠诚的将军们能达成行动的一致。对于拜占庭问题来说，假如将军总数为 N，叛变将军数为 F，则当N>=3F+1 时，问题才有解，即叛变的将军不超过1/3时，存在有效的算法，如BFT，不论叛变者如何折腾，忠诚的将军们总能达成一致的结果。这是一个数学论证的结论，有兴趣的同学可以自行推导。PBFT 一种高效拜占庭容错共识算法PBFT是Practical Byzantine Fault Tolerance的缩写，意为实用拜占庭容错算法。该算法是Miguel Castro 和Barbara Liskov（2008年图灵奖得主）在1999年提出来的，解决了原始拜占庭容错算法效率不高的问题。他的核心思想是：对于每一个收到命令的将军，都要去询问其他人，他们收到的命令是什么。如上图，假设命令由A将军分发，假如A是作恶异常，分发给B,C,D的操作分别是1,2,3.意图扰乱共识。拜占庭容错算法上设计实现是，当B,C,D收到命令后，相互之间也会沟通从A收到的命令是否一致，从而达到识破干扰的目的。其容错的极限值就是N>=3F+1。PBFT 在区块链上的实现区块链的节点分为记账节点和普通节点两个角色记账节点负责向全网提供记账服务，并维护全局账本，每过一段时间从记账节点中选一个议长，进行命令的分发，其他记账节点则作为议员进行验证将军就是记账节点，拥有全局账本，并验证交易的有效性，过互相传达验证结果，在f共识的一般流程如下：1.任一节点接收到发送者签名的交易数据请求后，向全网广播2.所有记账节点均独立监听全网的交易数据，并记录在内存3.议长在经过t后发送共识请求提案request4.议员在收到提案后，进行相关验证，发送响应response5.任意节点在限定时间内收到至少F+1个response后，共识达成，把交易记录入区块并发布给全网，如果超时，则更换视图和议长6.任意节点在收到完整区块后，把包含的交易从内存中删除开始下一个共识循环区块产生间隔t, 记账节点n, 可容错节点数f，视图编号v, 区块高度h, 议长编号p, 议员编号i p=(h-v)%n 未来的发展POW算法建立了比特币帝国，具有划时代的意义。但其能耗和速度问题却是制约区块链普及的两大难以解决的问题。目前POS算法是一大趋势，以太坊的Casper，EOS的DPos等都是借鉴了上述前人的设计理念做的基于应用场景的优化改造，但万变不离其宗，我和大家一样，需要不断的学习和思考，没准，能有发明出自己的共识算法的一天呢。

分布式计算是计算机科学中一个研究方向，它研究如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给多个计算机进行处理，zui后把这些计算结果综合起来得到zui终的结果。分布式网络存储技术是将数据分散地存储于多台独立的机器设备上。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，不但解决了传统集中式存储系统中单存储服务器的瓶颈问题，还提高了系统的可靠性、可用性和扩展性。分布式计算与互联网的普及随着计算机的普及，个人电脑开始进入千家万户。与之伴随产生的是电脑的利用问题。越来越多的电脑处于闲置状态，即使在开机状态下CPU的潜力也远远不能被完全利用。我们可以想象，一台家用的计算机将大多数的时间花费在“等待”上面。即便是使用者实际使用他们的计算机时,处理器依然是寂静的消费，依然是不计其数的等待（等待输入，但实际上并没有做什么）。互联网的出现, 使得连接调用所有这些拥有闲置计算资源的计算机系统成为了现实。分布式计算项目那么，一些本身非常复杂的但是却很适合于划分为大量的更小的计算片断的问题被提出来，然后由某个研究机构通过大量艰辛的工作开发出计算用服务端和客户端。服务端负责将计算问题分成许多小的计算部分，然后把这些部分分配给许多联网参与计算的计算机进行并行处理，zui后将这些计算结果综合起来得到zui终的结果。当然，这看起来也似乎很原始、很困难，但是随着参与者和参与计算的计算机的数量的不断增加, 计算计划变得非常迅速，而且被实践证明是的确可行的。一些较大的分布式计算项目的处理能力已经可以达到甚而超过世界上速度zui快的巨型计算机。您也可以选择参加某些项目以捐赠的 CPU内核处理时间,您将发现您所提供的 CPU 内核处理时间将出现在项目的贡献统计中。您可以和其他的参与者竞争贡献时间的排名，您也可以加入一个已经存在的计算团体或者自己组建一个计算小组。这种方法很利于调动参与者的热情。参与计算随着民间的组队逐渐增多, 许多大型组织(例如公司、学校和各种各样的网站)也开始了组建自己的战队。同时，也形成了大量的以分布式计算技术和项目讨论为主题的社区，这些社区多数是翻译制作分布式计算项目的使用教程及发布相关技术性文章，并提供必要的技术支持。那么谁可能加入到这些项目中来呢? 当然是任何人都可以! 如果您已经加入了某个项目，而且曾经考虑加入计算小组, 您将在中国分布式计算总站及论坛里找到您的家。任何人都能加入任何由我站的组建的分布式计算小组。希望您在中国分布式总站及论坛里发现乐趣。参与分布式计算——一种能充分发挥您的个人电脑的利用价值的zui有意义的选择——只需要下载有关程序，然后这个程序会以zui低的优先度在计算机上运行，这对平时正常使用计算机几乎没有影响。如果你想利用计算机的空余时间做点有益的事情，还犹豫什么？马上行动起来吧，你的微不足道的付出或许就能使你在人类科学的发展史上留下不小的一笔呢。 raft算法之所以容易理解，其一是他将一致性问题划分成几个子问题，这几个子问题都是独立、可理解和解释的。从传统的思维来讲，对于一个复杂的系统或者工程，都是大化小，分解实现，然后去尝试融合解决整体逻辑。包括CS系统的设计也是如此。一致性算法的目标 1.安全性：在非拜占庭错误情况下，包括网络延迟、分区、丢包、冗余和乱序等错误都可以保证正确。2.可用性：只要集群中大多数节点处于runing，并且不分区，和客户端能通信，那么我们需要保证这个集群可用。3.对于数据同步，小部分慢节点的不会影响系统性能。因为对于日志复制，我们如果等待所有节点响应，那么系统的性能会存在短板效应。说白了，就是如果一个集群中，如果大多数节点可用（网络、服务），那么通过raft算法，我们就能保证整个系统可用（可处理请求，数据一致性）。后面我们主要研究的就是raft是如何做到的。首先我们要知道，Raft算法将其问题划分为领导选举日志复制安全性对于一个集群只有一个leader（领导），那么我们就很容易理解。只要领导操作同步到对应的followers（跟随者），数据必然一致。当leader宕机，需要进行领导选举。日志复制其实就是同步操作数据的过程。leader将操作日志同步到其他节点。安全性：如何安全的同步，在不同的情况，我们都能保证一致性，这也就是安全性需要考虑的问题。其实就是如此，raft首先假设了领导选举。然后实现了日志复制，zui后在安全问题上解决上面的漏洞问题。

Re： LVS + Keepalived 实现 MySQL 负载均衡与高可用========================================================# LVS产生背景把单台计算机无法承受的大规模的并发访问或数据流量分担到多台节点设备上分别处理，为减少用户等待响应的时间，提升用户体验。单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。 7*24小时的服务保证，任意一个或多个设备节点设备宕机，不能影响到业务。在负载均衡集群中，所有计算机节点都应该提供相同的服务（非必须），集群负载均衡获取所有对该服务的如站请求。 # 集群的作用提供一种廉价、有效、透明的方法，来扩展网络设备和服务器的负载带宽、增加吞吐量，加强网络数据处理能力、提高网络的灵活性和可用性。

6,850

社区成员

178,035

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章