问个问题，如 QQ,MSN 服务器系统有很多机，它们之间如何同步维护客户端的在线列表呢？ 如何做到负载平均的呢？ ( 积分: 0 )

问个问题，如 QQ,MSN 服务器系统有很多机，它们之间如何同步维护客户端的在线列表呢？ 如何做到负载平均的呢？

有什么好的想法，大家讨论一下，多谢

这还用讨论？！
这是一个经典的问题，具体的方法你不必在这里问，应为他是在ip协议里实现的，详情可以在linux的专业站点里找到，那里写得很明白了。

楼上的意思一个IP不是一个固定的机器，是一群，死掉几个没关系

应为他是在ip协议里实现的

----------------------------
我想没这样难吧.

据我所知 IP 协议中没有集群的信息

TCP协议粘的分层是这样的

Ethernet -- > IP --> TCP/ UDP

Ethernet 层很简单，就 目标MAC 与源 MAC，与包类型

IP 层有，版本， 头长度，总长度， id, CheckSum, 目标IP， 源IP，超时 ..

TCP 层有，目的PORT， 源PORT SeqNum , AckNum 等等,

总之没有你说的那种集群的信息。

我想补充几个问题
1.为了做到负载平衡应该有多个服务器
这些服务器如何做到信息同步呢？
2.传输文本（一定长度）、图象也许难度不大，我想知道如何传输大量的信息呢？比如查找目前在线的网友，我的理解是发一个请求信息包过去，然后后台数据库进行查询，问题是查询的结果（数据集）通过什么方式显示在客户端呢？

借花献佛，如果有满意答复，我愿帮楼主付分：）

TCP/IP本身没有集群，但是IP地址对应什么mac地址可以变的

负载平均其实是分很多种的
从数据层来说就有基本的就有两种，一种是几台机数据完全一样的，只是客户调用时是通过一个负载均衡来调试的。这种方式也是最简单的，稳定性也好。不过并不适合超大数据量的。
另一种就是把数据分割，每台机的数据都是不一样的，各自负责一块，可以客户分别请求，也可以由服务器集中请求整合再返回给用户。这种方法在数据分割的层面上讲，理论上可以支持无限的数据。但实际是不可能的。
还有就是把这两种结合在一起的。内层是用数据分割，然后每个数据分割单独做负载均衡。

调用层上，前面也提到了，有客户端分别请求和集中服务器请求完了整合返回两种，这两种优缺点也是相对的。

来自：xusong168, 时间：2007-1-4 17:06:28, ID：3651937
TCP/IP本身没有集群，但是IP地址对应什么mac地址可以变的

这位仁兄提到的，只是第一种负载均衡的其中一种实现方法。

不要只指到为止吧, 来点实质性的东东吧, Thanks

找到了点资料

最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的[1]。DNS负载均衡是一种简单而有效的方法，但是它不能区分服务器的差异，也不能反映服务器的当前运行状态。

反向代理服务器可以将请求转发给内部Web服务器，如果代理服务器能够将请求均匀转发给多台内部服务器，就能达到负载均衡的目的[2]。反向代理方式下能应用优化的负载均衡策略，每次访问最空闲的内部服务器来提供服务。但是随着并发连接数量的增加，代理服务器本身的负载也变得非常大，最后反向代理服务器本身会成为服务的瓶颈。

支持负载均衡的地址转换网关中可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的[3]。很多硬件厂商将这种技术集成在他们的交换机中，作为他们第四层交换的一种功能来实现，一般采用随机选择、根据服务器的连接数量或者响应时间进行选择的负载均衡策略来分配负载。然而硬件实现的负载控制器灵活性不强，不能支持更优化的负载均衡策略和更复杂的应用协议。

除了这三种负载均衡方式之外，有的协议内部支持与负载均衡相关的功能，例如HTTP协议中的重定向能力等，但它依赖于特定协议，因此使用范围有限。根据现有的这些负载均衡技术，我们选择了使用软件方式实现网络地址转换的负载均衡的方式，以弥补硬件负载均衡器的不灵活，并应用优化的均衡策略来实现后端服务器负载分担的最优状态。


2. 负载均衡策略

为了将负载均匀的分配给内部的多个服务器上，就需要应用一定的负载均衡策略。传统的负载均衡策略并没有考虑到服务请求的不同类型、后台服务器的不同能力以及随机选择造成的负载分配不均匀等问题。为了使得负载分配十分均匀，就要应用能够正确反映各个服务器CPU及I/O状态的负载均衡策略[4]。

客户发起的服务请求类型是多种多样的，按照对处理器、网络和I/O的资源要求，可以简单的将它们分为两个不同类别，以便应用不同的处理策略：



静态文档请求：例如普通的文本、图象等静态多媒体数据，它们对处理器负载影响不大，造成的磁盘I/O负载与文档的大小成正比，主要对网络I/O造成压力。


动态文档请求：更为常见的请求常常需要服务器预先进行处理，例如搜寻数据库、压缩解压缩多媒体文件等，这些请求需要相当大的处理器和磁盘I/O资源。


对于静态文档，每个服务进程占用大致相同的系统资源，因此就可以使用进程数来表示系统负载。而动态文档服务需要进行额外的处理，其占用的系统资源就超过处理静态请求，因此需要使用一个权重来表示。这样一个最简单的服务器负载表示公式就为：

其中L为服务器的负载，Ns为静态文档服务进程数，Nd为动态文档服务进程数，而a为每个动态文档服务相对于静态文档服务的权重，可以在10到100之间进行选择。

在这个公式中没有考虑服务器硬件的限制，当达到硬件限制的时候，由于资源紧张，服务器的负载就会明显增加。例如由于服务器内存大小的限制，一些进程就要被交换到硬盘上，使得系统负载迅速增加。考虑了系统硬件限制，则服务器的负载可以表示为：

新增加的参数 Ll表示这个服务器普通负荷的限度，它要根据每个服务器本身的硬件能力来设置。而b表示超出正常负载时用来限制分配给服务器任务的权重，应该设置为大于Ll的数值，以表示硬件限制作用。通常在一个服务器集群中，硬件设置越差的服务器这个权重越要设置的大，以避免在所有的服务器都超负载运行时，硬件最差的服务器反而负载最高。因此b是和本服务器硬件限制Ll成反比的，则b可以设置为：

Llmax为服务器集群中最高硬件配置的服务器的Ll值。当确定了每个服务器的负载之后，中心控制负载分配的服务器就能将负载正确的分发给最空闲的服务器，从而不会象其他的负载分配策略那样会导致负载分配不均匀的情况。


3. 实现方法及实验结果

我们的服务器系统由使用快速以太网连接起来的多台FreeBSD系统组成。每台后端服务器上运行一个守护进程来动态获得自己的负载状态，而使用FreeBSD实现的中心控制网关就通过这些守护进程刷新各个服务器的负载，以进行正确的负载分配。

3.1支持负载均衡的网关

在FreeBSD系统下，提供了divert接口以支持网络地址转换能力。IP数据包通过系统内核的ipfw过滤功能被发送到divert接口中，以便外部守护进程natd能接收原始数据包，处理之后再发回系统内核进行正常的IP分发[5]。

因此根据FreeBSD的地址转换结构，可以创建自己的网络地址转换守护进程，以支持负载均衡功能，这样就能将FreeBSD系统作为一个支持负载均衡的网关。由于它是软件实现的方式，很容易支持非标准的协议及应用优化的负载均衡策略，具备很大的灵活性。

3.2实验及分析

为测试这种实现的可用性，我们针对最常见的HTTP协议进行我们的测试实验。为了区分不同的请求种类，设计了三个不同类型的测试，以测试不同方面的性能。



CGI程序产生的动态文档：用于测试在服务器的处理能力的负载均衡状态。


小型静态文档：使用尺寸较小的静态文档，用于测试频繁连接下负载均衡的状态；


大型静态文档：使用较大的文档，测试磁盘及网络I/O的负载均衡状态；


测试结果以单台服务器每秒钟完成请求的性能为基准，显示使用多台服务器进行负载均衡时每秒种完成的请求数与基准请求次数的比率。

........

晚起的小虫, 说到了问题的关键. 如果光是服务器访问方面的负载平均,那要好做点.

但问题的关键就是数据层面的问题. 如果每个服务器只有一部份数据,那这是最好的方法了.但这个我还没找到好的方法来实现它.好象难度还不小. 再找找资料

接受答案了.