集群服务器如何通信

一、 集群通信系统的概念

集群(英文名为：Trunking),是一种多用户共用一组通信信道而不互相影响的技术。集群这一技术概念其实已在双向的无线通信领域中被广泛应用。

集群通信系统能使大量的用户共享相对有线的频率资源，即系统的所有可用信道可为系统内所有用户共用，具有自动识别用户，自动并动态地分配无线信道的功能，是一种多用途，高效率的移动调度通信系统

二、 集群通信系统的特点

1、 集群使用的频率

集群的工作频段为800兆频段，具体的：

· 上行频段为：806～821（MHz）;下行频段为：851～866(MHz);

· 邻道之间的频率间隔为：25KHz;

· 集群系统中，通信的双方（基站和用户终端）采用两个频率为一组，实现双向通信；

· 一组频点的上下行频率间隔为：45MHz;

2、 集群通信的工作方式

集群系统中基站采用双频全双工的工作方式，用户终端则根据不同的工作模式采用不同的工作方式：

调度模式下，采用双频半双工方式；

电话模式下，若用户终端为全双工类型的终端可采用双频全双工方式；若为单工用户机，则只能采用双频半双工方式；

双频全双工的定义：通信双方采用两个频率为一组，通信的任何一方在发射的同时也能接收，操作方便，无需进行按键通信。

双频半双工的定义：通信的双方采用两个频率为一组，通信的一方（基站）为全双工方式工作；另一方为单工方式，即在发射的同时无法接收，在接收的同时也无法发射，只能采用按键发话，松键收听的方式。

3、 集群系统的组网方式

模拟集群系统一般采用小容量大区制的覆盖（又称为单站结构），模拟联网的集群系统和数字集群系统一般采用大容量小区制的覆盖（又成为蜂窝网结构）；

所谓大区制是指用一个基站覆盖整个业务区，业务区半径一般为30km左右，以可大至60km。大区制一般可容纳几千至上万用户。

所谓小区制是将整个服务区话分为若干无线小区（有称基站区），每个小区服务半径为2～10km。采用该组网方式的系统中频率可以重复利用,而且根据小区分割模式不同可采用不同的频率复用方式。

4、 集群系统的基本功能

集群系统所共有的基本功能如下：

1、具有强劲的调度通信功能；

2、兼备有与公共电话网和公共移动通信网互联的电话通信功能；

3、智能化的用户移动行管理功能；

5、 智能化的无线信道分配管理、系统控制和交换功能；

三、 集群通信系统分类

1、按控制方式分

有集中控制和分布控制。集中控制是指一个系统中有一个独立的智能控制器统一控制、管理资源和拥护。分布式控制方式是指每个信道都有一个单独的控制起，这些控制器分别独立的控制、管理相应的系统资源和一部分用户。

2、按信令方式分

有共路信令和随路信令方式。共路信令是指基站或小区内设定了一个专门的信道作为控制信道，用以接收用户机发出的通信、入网等请求信号，同时传输系统的控制信令，向用户下达信道分配信息和用户通知信息。

3、按通话占用信道分

有信息集群、传输集群和准传输集群。信息集群是指用户完成一次通信后，该信道仍为该用户保留一段时间（一般为10秒左右），以确保该用户在这段时间内再次呼叫时仍能成功占用信道，如此来保证信息的完整性；传输集群是指当用户完成一次通信后，新道立即释放，以提供系统再次分配，如此来提高系统资源的利用率；准传输集群是介于以上两种之间的一种集群方式，即信道保留的时间略短于信息集群（一般为3秒左右）。

4、按信令占信道方式分

有固定式和搜索式。固定实是指信令信道（控制信道）是系统中固定的一个信道，用户在入网或业务请求式固定向该信道发起请求；搜索式是指信令信道不固定，由系统随机指定，用户每次入网或业务请求均必须搜索信令信道。

模拟集群

一、设备及组织结构

本公司三个集群基站均采用美国MOTOROLA公司生产的集群移动通信系统SMARTNETII，系统组成如图所示，主要由中央控制器、电话互联终端、集群信道机、收发天线共用器、天线、系统管理终端、系统监视终端、移动台和手机等设备组成。如图3-1

中央控制器：

负责控制和管理整个系统的运行，包括：选择和分配可用信道；监视话音信道活动；监测和报告告警情况；为系统管理提供接口等。

电话互联终端(CIT)：

是集群通信网与有线电话网的接口，供调度台和移动台自动接入有线电话网之用。

集群信道机：

分为控制信道和话音信道，提供中央控制器与用户设备间的接口。每个信道机要求一部发射机和一部收发信机全双工工作。

系统管理终端：

提供系统操作员输入或修改系统运行参数、设备状态及告警报告、调整系统定时及系统接续参数、报告信道工作状态及控制用户接入系统等。

天馈系统：

天馈系统包括从天线到传输线接头为止的所有匹配、平衡、移相或其他耦合装置，包括天线、发射机合路器、接收机多路耦合器、传输线、雷电保护和避雷器及塔顶放大器等。

模拟集群系统组织结构图

二、功能简介

1、 用户终端实现的功能：

组呼：通话小组是集群系统中最基本的通信组织。通过用户机编码可以将多个用户机编在一个通话小组中，用户机按键进行组呼，只有同一组码的用户机才能与本小组内的成员进行通信。

私线呼叫（单呼）：一个用户机能有选择性地指定用户与其建立单独通话。

呼叫提示：由一方用户机发起的对另一方用户机的寻呼，被叫的一方机器会间隔几秒钟发出"嘟嘟"的响声，直到被叫用户响应，同时被叫方的机器将会显示主叫方的用户ID；被叫用户此时若直接按键，会向主叫方发起一次私线呼叫。

电话互连：集群用户可以通过系统拨打有线电话（市话、长话），市话用户也可通过二次拨号与集群用户建立电话通信。

紧急呼叫：由用户按紧急呼叫键发起，紧急呼叫具有最高等级，当信道遇忙时，通常有两种方式：队首式和强拆式。

2、 系统管理实现的功能：

系统对用户机ID码的识别和管理

用户每一次申请，系统都必须对其ID码进行认别，以辨别其合法性及小组归属。

用户机功能的遥闭、授权、开启

系统可以根据需要对分散在各处的用户机进行空中关闭---遥闭或开启。系统也可以对用户机优先等级、电话功能等进行远程授权或取消。

遇忙排队

当用户发起呼叫申请时，系统内无空闲信道，则系统记录下用户机的ID码并进行排队，按一定的程序进行处理。

动态的信道分配

由系统中央控制器根据系统当前的状态按一定的顺序进行向用户提供动态的信道分配。

故障弱化模式

当中央控制器或所有的控制信道故障时，系统会工作在故障弱化模式下，这时所有用户机以常规模式工作，占用用户机编程时设定的故障弱化信道进行通信。

系统的故障诊断和处理、状态监视、系统参数的调整

· 系统能对于当前发生在信道机或控制器部件上的故障作出响应和处理，将故障的部件自动暂闭，以使系统不再将用户的通信分配上去。

· 系统对当前的运行状态进行不断的监视，如哪些/哪个信道机被占用，哪些空闲，哪些故障等，以便在信道分配时作出准确的处理。

· 系统内有大量的参数，可以通过系统管理终端进行及时的远程调整。

数字集群

IDEN(Integrated Digital Enhanced Networks)是美国MOTOROLA公司生产的800M数字集群移动通信系统，这个系统是利用了多项先进的数字话技术，能在一部iDEN用户机上集成了调度、电话、短信、数传四项功能。其先进的无线射频技术使得一个25kHz的载频上容纳6路话音，从而使得有限的频点得到了更大程度的利用。iDEN数字集群通信网具有大容量、大覆盖区、高保密和高通话清晰度的特点。

1、 组织结构及设备

iDEN的基本组织结构包含：调度子系统、互联子系统、操作维护子系统、计费及用户数据管理子系统和基站子系统；

运行管理中心（MSO）：是上层网络控制和交换设备所在的机房，负责执行系统的日常管理，为长期的网络工程系统监控和规划工具提供数据库资料。在MSO中包含的子系统为：调度子系统、互联子系统、OMC子系统、计费及用户数据管理子系统；

操作维护中心（OMC）:承担对全网设备的管理，对运行参数进行设置和修改，收集运行数据，监控系统运行情况。

计费及用户数据管理子系统（ADC）：实现对用户进行的开、关、授权、采集计费数据等功能。

基站子系统: 包含了分布在全市各个方向上的基站（EBTS-增强型基站传输系统）。各个基站通过E1数字中继线路与MSO设备联接。在本公司的iDEN基站系统中目前分布在外环线以内的基站均为3扇区的基站，分布在外环线以外的基站为全向基站。

调度子系统包含以下设备：

调度应用处理器（DAP）：为调度通信提供了总体的协调、控制和实时的调度呼叫处理，实现了调度通信时所需的资源管理、用户访问控制、位置跟踪和调度子系统内所有设备的网络管理，同时也为OMC子系统提供接口；DAP包含了D-HLR、D-VLR、i-HLR

· D-HLR：调度归属位置寄存器，是一个驻留在硬盘上的用户数据库。用以记录用户与调度通信相关的身份码、权限、通话组号、开设的调度业务类别等；

· D-VLR：调度访问位置寄存器，是一个驻留在内存上的用户数据库，用以记录在系统中当前一开机的调度用户状态、位置以及相关权限等；

· i-HLR：分组业务归属位置寄存器，是一个与分组数传业务相关的用户数据库，用以记录为用户的分组数传业务分配的IP地址；

快速分组交换机（MPS）:在DAP的控制下将来自基站的话音分组进行复制，根据DAP的指令在各个基站之间实现话音分组的交换。

移动数据网关（MDG）:是一个企业基叫环路由器，通过该接口网关可以建立起与其他intranet或internet的互联路由

互联子系统包括以下设备：

移动交换中心（MSC）:为iDEN用户的电话通信提供了控制管理和实时的呼叫处理和话音交换功能。另一方面，又为MSC与公共电话网（PSTN）之间的互联提供了接口。MSC包含了T-HLR和T-VLR

· T-HLR：电话归属位置寄存器，是一个集成在MSC交换机核心内的用户数据库。记录了所有用户与电话通信相关的身份码、业务类型和状态等。

· T-VLR:电话访问位置寄存器，是一个驻留在交换机核心内存上的用户数据库。记录了当前开机用户的位置、状态等。

短消息业务服务中心：（SMS-SC）为用户的短消息提供接收、存储和转发功能。

基站控制器（BSC）: 是基站与MSC之间的接口，又称为A接口。它一方面实现了将电话通信的话音从EBTS接续至MSC进行交换；另一方面也将公共有线电话网内的交换信令转换为移动电话应用信令，为移动用户与PSTN之间的通信建立信令握手。BSC包括BSC-CP,和BSC-XCDR

· BSC-CP（基站控制器-处理器）：承担呼叫处理，包括信令转换、话音接续等。

· BSC-XCDR(基站控制器-话音变码器): 提供PSTN网内使用的PCM话音编码和iDEN EBTS系统内使用的VSELP话音编码之间的转换

iDEN基本网络结构

二、关键技术

· 时分多址TDMA技术：是把时间分割成周期性的帧，每一帧在分割成若干个时隙。然后根据一定的时间分配原则，使各个移动台在每帧内只能按指定的时隙向基站发送信号，在满足定时和同步的条件下，基站可以分别在各时隙中接受各移动台的信号而不混扰。同时基站发向多个移动台的信号都按顺序安排在预定的时隙中传输，各移动台只要在指定的时隙内接收，就能在合路的时隙中把发给它的信号区分出来。

iDEN系统把每个25kHz信道分割为6个时隙，每个时隙占15ms。

· VESLP语音编码技术（矢量和激励线性预测编码技术）：将90ms的模拟话音压缩为15ms的数字信号。以适应其在一个15ms的时隙信道内传送。

· M-16QAM调制技术（多路复用-16点阵正交振幅调制技术）：这是一种专为集群系统设计的调制技术这种调制方式具有线形频谱，克服时间扩散产生的影响。

三、 承载业务

1、新增的用户机功能

新增的调度功能：

· 组呼

--本地呼叫（支持用户在其归属的Service Area的小区内进行呼叫）

--选区呼叫（支持用户选择某一Service Area进行呼叫）

--广域呼叫（支持用户在iDEN区域网络的任何位置进行呼叫）

· 单呼

--私线呼叫

--呼叫提示

· 紧急呼叫-在按下紧急呼叫按钮后，允许该用户强拆本组用户在用的通信，使本组内所有成员均收听到其话音；

· 单站操作模式（ISO）---- ISO功能支持当一个基站失去与MSO的链接后，仍能保持在该机站范围内的受限的调度功能

· 移动用户状态消息----允许有增强功能的MS单机向iDEN增强型调度台或其他有此功能的MS发送预定义的状态短信；

· 多组通信（MSTG）---- MSTG支持调度模式下可访问一个主要的通话组和3个辅助的通话组;

增强的电话功能：

· 蜂窝小区和双工漫游

· 呼叫等待、三方会谈、呼叫转移

· 自动漫游和越区切换

短消息收发功能-在用户机不具备接收短信的条件下（如:关机、不在服务区或手机存储器已满等），信息存储在短信中心内，在用户可以接受时（如开机并在服务区内等），信息发送给用户；

分组数传功能-在16QAM调制技术下，一个载频的传输速率为22Kbit/s;

2、新增的系统管理功能

（1） 配置管理，如：改变显示基站设备及系统网络管理设备的配置、改变和显示控制用户机的数据库、报告所有数据库的最新数据、确定用户机的使用功能等

（2） 计费管理：记录用户机在空中的使用时间和时长，输出记录的数据到计算机

（3） 错误诊断管理：显示各类设备的故障报告、告警报告、输出各设备的状态变化信息、进行环路反馈的测试等。

（4） 安全保密管理：控制有关人员对系统资源的访问、提供用户机的无线遥毙、开启功能等。

（5） 运行管理：对运行着的设备进行有针对性的监控、收集和处理各类运行数据。

四、用户机编码结构

· IMEI(international Mobile Equipment Identifier)-国际移动终端设备身份码，这是一台用户终端再生产过程中有生产厂家根据国际标准给移动台设立的，在国际范围内唯一的机器编号。该编码长15个字节，编写在移动台硬件芯片(如SIM卡)中。

· IMSI(International Mobile Station Identifier)- 国际移动台身份码，这是由服务提供商为移动台设立的，在国际范围内唯一的身份码。改编码长15个字节，系统首先在上层网络设备中进行分配，在数据库中建立并存储起IMEI于IMSI的唯一对应关系，移动台在首次开机注册时在通过了系统鉴定后，由控制信道上读取并自动存储在移动台内存中。

· TMSI(Temporary Mobile Station Identifier)-临时的移动台身份码，这是由系统在移动台每次的开机或更新位置区域时分配的编码，在VLR范围内唯一。该编码是为了防止用户身份的盗用，同时节省呼叫建立的时间。

· MSISDN(Mobile Station ISDN)-移动台ISDN号码，是一个电话号码，它唯一地标识了移动它在iDEN网和PSTN网内的身份，iDEN用户在电话通信时使用该号码。该号码长度部超过15个字节。

· FLEET & MEM-调度大组号及成员号，大组号在整个iDEN系统内唯一的标识了一个单位或团体；成员号则在该大组范围内唯一的标识了一个调度用户单机。

· Talkgroup-通话组号，在FLEET范围内唯一，它将FLEET范围内的成员组织为一个一个独立调度的小组。

五、 用户机与系统之间的部分叫呼过程

1、关于用户机的身份码分配过程

首先由管理员登录到系统管理终端连接到系统的HLR(归属位置登记器)，将记录在用户机CPU内存中的串号（IMEI-国际移动设备标识符）登记到HLR中，为其分配一个在系统中有效的且唯一的IMSI（国际移动用户标识），以及一系列的其他参数，包括编组情况。所有这些参数必须确保在HLR内正确地成功注册。

在HLR中IMEI和IMSI必须都保持唯一，即一个IMEI对应一个IMSI，一个IMSI也只能分配给一个用户机。

2、 用户机在系统中的登记过程

用户机的每次开机时与系统之间相互传递数据的过程为登记过程。

用户机在注册后的首次登记时将IMEI通过基站传送至系统中心设备，系统收到后与用户机之间执行鉴证过程。当鉴证通过后，将IMSI、Individual ID（一个半固定的身份码）等通过基站发送给用户机。

用户机以后每次的开机时所触发的登记过程向系统发送IMSI，在鉴证通过后收到Individual ID等。

用户机在成功地开机登记后到关机之前，每次位置更新和业务通信申请时，均向系统传递Individual ID。

用户机的鉴证过程：

系统HLR产生一个随机数，传送到系统的CPU上执行一次运算（特定的运算程序）得到与此随机数相应的结果值，保存在VLR（访问位置寄存器）中。随机数通过基站发送给用户机。

用户机收到随机数后由用户机的CPU进行相关的运算，并将其得到的结果数通过基站传送给VLR，VLR将此结果数与系统运算的结果数比较，两数相等，则鉴证正确，通过；反之则鉴证失败，系统拒绝该用户机入网。

1、集群是什么？

① 集群（cluster）技术是一种较新的技术，通过集群技术，可以在付出较低成本的情况下获得在性能、可靠性、灵活性方面的相对较高的收益，其任务调度则是集群系统中的核心技术。

② 集群是一组相互独立的、通过高速网络互联的计算机，它们构成了一个组，并以单一系统的模式加以管理。一个客户与集群相互作用时，集群像是一个独立的服务器。

③ 集群组成后，可以利用多个计算机和组合进行海量请求处理（ 负载均衡 ），从而获得很高的处理效率，也可以用多个计算机做备份（高可用），使得任何一个机器坏了整个系统还是能正常运行。集群在目前互联网公司是必备的技术，极大提高互联网业务的可用性和可缩放性。

2、负载均衡集群技术

① 负载均衡（Load Balance）：负载均衡集群为企业需求提供了可解决容量问题的有效方案。负载均衡集群使负载可以在计算机集群中尽可能平均地分摊处理。

② 负载通常包括应用程序处理负载和网络流量负载。这样的系统非常适合向使用同一组应用程序的大量用户提供服务。每个节点都可以承担一定的处理负载，并且可以实现处理负载在节点之间的动态分配，以实现负载均衡。对于网络流量负载,当网络服务程序接受了高入网流量，以致无法迅速处理，这时，网络流量就会发送给在其它节点上运行的网络服务程序。也可根据服务器的承载能力，进行服务请求的分发，从而使用户的请求得到更快速的处理。

3、负载均衡集群技术的实现

负载均衡（Load Balance）

负载均衡技术类型：基于 4 层负载均衡技术和基于 7 层负载均衡技术

负载均衡实现方式：硬件负载均衡设备或者软件负载均衡

硬件负载均衡产品： F5 BIG-IP 、Citrix Netscaler  、深信服 、Array 、Radware

软件负载均衡产品： LVS （Linux Virtual Server）、 Haproxy、Nginx、Ats（apache traffic server）

4、实现效果如图

5、负载均衡分类

负载均衡根据所采用的设备对象（ 软/硬件负载均衡 ），应用的OSI网络层次（ 网络层次上的负载均衡 ），及应用的地理结构（ 本地/全局负载均衡 ）等来分类。本文着重介绍的是根据应用的 OSI 网络层次来分类的两个负载均衡类型。

我们先来看一张图，相信很多同学对这张图都不陌生，这是一张网络模型图，包含了 OSI 模型及 TCP/IP 模型，两个模型虽然有一点点区别，但主要的目的是一样的，模型图描述了通信是怎么进行的。它解决了实现有效通信所需要的所有过程，并将这些过程划分为逻辑上的层。层可以简单地理解成数据通信需要的步骤。

根据负载均衡所作用在 OSI 模型的位置不同，负载均衡可以大概分为以下几类：

二层负载均衡（mac）

根据OSI模型分的二层负载，一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应。

三层负载均衡（ip）

一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应。

四层负载均衡（tcp）

在三层负载均衡的基础上，用ip+port接收请求，再转发到对应的机器。

七层负载均衡（http）

根据虚拟的url或IP，主机名接收请求，再转向相应的处理服务器。

在实际应用中，比较常见的就是四层负载及七层负载。这里也重点说下这两种负载。

6、四层负载均衡（基于IP+端口的负载均衡）

所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

layer4

1在三层负载均衡的基础上，通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。

2以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。

3对应的负载均衡器称为四层交换机（L4 switch），主要分析IP层及TCP/UDP层，实现四层负载均衡。此种负载均衡器不理解应用协议（如HTTP/FTP/MySQL等等）要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。

4实现四层负载均衡的软件有：

F5：硬件负载均衡器，功能很好，但是成本很高。

lvs：重量级的四层负载软件

nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活

haproxy：模拟四层转发，较灵活

7、七层的负载均衡（基于虚拟的URL或主机IP的负载均衡)

所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

layer7

1在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。

2以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个 代理服务器 。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。

3对应的负载均衡器称为七层交换机（L7 switch），除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载均衡。此种负载均衡器能理解应用协议。

4实现七层负载均衡的软件有：

haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；

nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；

apache：功能较差

Mysql proxy：功能尚可。

8、四层负载与七层负载的区别

举个例子形象的说明：四层负载均衡就像银行的自助排号机，每一个达到银行的客户根据排号机的顺序，选择对应的窗口接受服务；而七层负载均衡像银行大堂经理，先确认客户需要办理的业务，再安排排号。这样办理理财、存取款等业务的客户，会根据银行内部资源得到统一协调处理，加快客户业务办理流程。

总结：从上面的对比看来四层负载与七层负载最大的区别就是效率与功能的区别。四层负载架构设计比较简单，无需解析具体的消息内容，在网络吞吐量及处理能力上会相对比较高，而七层负载均衡的优势则体现在功能多，控制灵活强大。在具体业务架构设计时，使用七层负载或者四层负载还得根据具体的情况综合考虑。

2、Haproxy 实现四层负载

先说结论，对于容量和性能：

服务器资源： 8核16G内存， 6个机械磁盘，每个磁盘100G， 用于mongo分片，10MB带宽。

容量：用户容量10万以上，消息条数10亿条。

性能评估：同时在线用户10万，每秒钟发送消息900条，消息延时1秒（从发送者发出消息到接收到消息）

启动sdk，模拟50个用户在线、离线情况，消息可靠性100%。

发送10万消息，有3条失败，其他消息都能被对方精确收到，并成功落地本地db。对于失败的3条消息，接收方确实没有收到，系统消息是一致的。

OpenIM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包括IM服务端和客户端SDK，是一套整体的解决方案，代码开源，一切可控，

OpenIM可以实现全平台支持，目前支持Android，iOS，Flutter，Uni-app，react-native, JSSDK等。

OpenIM可以应用在企业内部办公，dating交友，在线客服等项目，也可以用于元宇宙。

github地址：https://githubcom/OpenIMSDK/Open-IM-Server

开发者中心: https://docrentsoftcn/#/

在单机的情况下，模拟线上用户发消息流程，在线用户量和消息量达到一定量级后，系统CPU、内存、磁盘占用、以及消息时延情况。以确定用户群体达到一定量级后，对服务器资源的预先评估。本次测试并不极限测试，一是因为生产环境本来都会有用户量和消息量的限制，二是因为OpenIM的消息模型，消息发送首先都会通过websocket入库kafka，理论上发送消息的写入性能是两者的组合，而消息发送的真正瓶颈实际在mongodb的随机读写。

服务器资源： 腾讯云主机（香港）1台：linux Ubuntu 18044系统，4核8G内存，单块机械硬盘。5Mb带宽。

测试条件：去掉消息入库mysql（因mysql仅用于管理后台，不影响线上用户服务）。日志级别调整为4或更低。kafka设置2个分区，msg_transfer 2个。

测试流程：1个客户端（成都，window pc，4核16G内存）启动1万个协程，模拟用户与服务器建立websocket长连接，间隔时间为随机50-100秒之间。两个客户端共模拟2万用户同时在线，发送消息，观察消息流转各个模块的处理能力，共计2500万条消息，观察系统内存、磁盘资源使用情况。

mongodb数据情况

redis数据情况

磁盘状态

资源占用分析

（1）redis内存消耗极小，一个用户一条数据（包括token和seq），和用户量成正比，3万用户占用几十M内存。

（2）mongodb如果去掉cache，内存消耗极小，每个document存放5000条消息，与用户量和消息量成正比，3万用户，2500万消息，索引才950K（更好的方式查看mongo消耗cache之外的内存）

（3）2500万消息，磁盘空间占用10G。

（4）每秒钟150条消息，cpu整体占用50%，即2核。

性能分析

（1）性能瓶颈在mongodb写入操作，1条消息，需要按照发送者和接收者拆分2次，mongodb写入2次，未来可以针对mongodb读写进一步优化。

（2）对于cpu消耗较大的模块，未来做一次整体优化。

（3）性能很平稳，不会随着数据量增加而降低。机械磁盘iops 达到200基本达到了设备的极限

服务器资源： 8核16G内存， 6个磁盘，每个磁盘100G， 用于mongo分片，10MB带宽。

性能评估：同时在线用户10万，每秒钟发送消息900条，消息延时1秒（从发送者发出消息到接收到消息）

（1）mongo集群部署，支持上亿用户同时在线，千亿级消息；

（2）简化集群部署；

（3）数据备份、恢复工具；

以上主要对服务端性能做了一个大致测试，但一套完整的IM解决方案，不仅仅是服务端的工作。实际上，客户端重要性毋庸置疑，具体包括如何利用seq和服务端同步消息，如果保证消息收发的时序，如何回调客户端（会话改变、新增，新消息），消息落地本地db，seq同步，消息推拉如何结合以确保消息收发可靠性。

相比于性能测试，实际上，消息的可达性（可靠性）更为重要。所以，我们在做性能测试的同时，也要对消息的可达性（可靠性）进行测试，如果不能保证消息收发的正确性，再高的性能也是徒劳。本文重点总结关于OpenIM对于消息可达性测试的方案、过程以及结果。先说结论，OpenIM消息可达率100%，大家可以放心使用在生产环境中。seq对齐和同步机制，保证了OpenIM的消息可达性是业界领先的。

IM消息系统的可靠性，通常就是指消息投递的可靠性，即我们经常听到的“消息必达”，通常用消息的不丢失和不重复两个技术指标来表示。确保消息被发送后，能被接收者收到。由于网络环境的复杂性，以及用户在线的不确定性，消息的可靠性（不丢失、不重复）无疑是IM系统的核心指标，也是IM系统实现中的难点之一。总体来说，IM系统的消息“可靠性”，通常就是指聊天消息投递的可靠性（准确的说，这个“消息”是广义的，因为还存用户看不见的各种指令和通知，包括但不限于进群退群通知、好友添加通知等，为了方便描述，统称“消息”）。

从消息发送者和接收者用户行为来讲，消息“可靠性”应该分为以下几种情况：

（1）发送失败，对于这种情况IM系统必须要感知到，明确反馈发送方。如果此消息没有发送成功，发送方可以选择重试或者稍后再试。

（2）发送成功，如果接收方处在“在线”状态，应该立即收到此消息。如果接收方处在“离线”状态不能收到消息，一旦上线则立刻收到消息。

（3）消息不能重复，用数学术语表示：“有且仅有这条消息”，如果重复了，可能表达的意思就变了。 总之，一个商用 IM系统，必须包含消息“可靠性”逻辑，才能谈基本可用，这是IM系统最基本也是最核心的逻辑。

互联网真实场景复杂，但客户端大体可以分为两种情况：（1）发送消息时，接收方在线，能收到消息；（2）发送消息时接收方不在线，登录后能收到离线消息。我们用测试程序模拟互联网客户端各种场景，按照登录、发送消息、接收消息的情况，把测试客户端分为以下2种类型：

（1）启动测试时离线，随机sleep 0-60 秒后登录，发送消息，且接收消息

（2）启动测试时离线，随机sleep 0-60 秒后登录，不发送消息，只接收消息

在实际测试中共计50个客户端，约25个（50%概率）客户端不发送只接收消息，约25个（50%概率）客户端发送且接收消息 。

发送模式：每个客户端随机选择其他客户端作为消息接收者；

测试预期： 每一条发送成功的MsgID，都能在接收的消息列表中找到，同样，每一条接收到的MsgID，都能在发送成功的消息列表中找到。

具体做法：（1）消息发送成功后，通过OnSuccess回调，记录MsgID； 收到新消息后回调OnRecvNewMessage，记录MsgID；（2）周期性对比两个消息列表，确认是否完全一致；

发送数据100000条，其中失败3条，9999997条成功，接收方成功接收9999997条消息（接收方成功接收到消息，写入本地db，并能触发消息回调）

每一条发送成功的消息，对方都能准确接收到，无论接收方在消息发送时的登录状态是在线还是离线。

每一条发送失败的消息，对方都不会收到。

注意事项：

（1）控制压力，因为sdk需要写本地db，客户端会成为压力瓶颈。

（2）压测客户端日志会影响测试性能。

此表格是某IM云平台的价格，如果按照10万月活，存储三年消息来算，大概每年需要支付15万。而采用OpenIM只需要采购云主机，每年成本约08万。

你可以直接买一台负载均衡交换机啊，何必要浪费1台服务器呢。

2 应该是每台都会有一个IP地址 外网 访问连接到的那个IP地址 是你的负载均衡交换机的IP地址 他随机把你的访问请求分配到你的3台服务器上

3 无主从关系，负载均衡交换机它会没2秒左右向你的服务器发送一个健康检查，如果发现你的服务器出现问题，它会自动屏蔽你这台服务器

4 你问的重复问题。

据我所知，在MSN系统中，Client首先会连接一个固定的服务器，此服务器会返回一个新的连接服务器地址给Client，而后Client会重新连接到新的务器地址并开始登录。我想这样做是服务器端做到一个负载平衡的功能，也就是说有一个负载平衡服务器，有多个登录服务器。最终Client保持连接的是登录服务鳌

但是如果ClientA连接的是登录服务器A，而CientB连接的是登录服务器B，而ClientA和ClientB是好友，他们的在线状态是怎么得到的？

如果Client的数量比较少，那么登录服务器之间可以传递消息告知对方。但是当上万或者更多的时候。就不应该这样处理了。

那么有什么方式来实现类似的服务器网络结构中Client之间在线状态的实时显示呢？

(wyu2000 AT gmailcom)

正是我现在要面对的问题

我现在准备采取的策略是:

由客户端主动通知好友。

A 连接到 Login Server A 后。

我们假设A已经从主服务器获得了 好友列表，以及好友状态。

那么A可以主动发送LoginServerA 通知 在线好友B。

LoginServer的通知过程可以用如下方法：

ServerA，检索到好友B的登陆服务器（可以向主服务器请求Client B的登陆服务器，或者可以采用特定的ID算法，根据用户的ID计算出用户B的登陆服务器）

ServerA 发送一个ClientA登陆的消息给Server B，要求ServerB将该消息，转发给 Client B

大家给点意见。

目前我做的IM系统是通过服务器之间转发实现的，想想也没什么更好的办法，理论上每个Server可以达到几万，不过现实中，只有几十个用户/台。

引用

我提个方案:

首先做以下假设:

(1)维护100万在线用户的状态需要多大的内存空间

(2)从100万在线用户中检索出自己需要的数据需要多少时间

第一个问题我们可以这样来定性:

设每用户占用的内存空间为:

SessionID会话标识(int)+AccountID用户账号ID(int)+loginTime登录时间(long)+其它状态(假设用4个byte型幢昝4个状态)=20字节

100万用户20字节=20,000,000(字节)=19,53125K==19M(约)

注:一条记录就表示一个在线用户；

(我靠,我的计算是不是有错误,一台386的内存都够了)

看上去,似乎用一台服务器做状态服务器是没有什么问题的；

第二个问题,我们这样来定性:

假设在服务器端的内存中使用如hashTable这样的存储结构来保存用户的会话状态,hashTable的读操作为0/m复杂度,从100万个记录中读取一条锹嫉难爸肥奔淠鞘窍嗟钡目斓,快到无法用毫秒来计算,只能用tick(一个CPU的时钟滴答)来计算。1个毫秒=10,000个tick(毫微秒),（has环Table的操作平均值是多少我没有统计过不好意思。我就猜个值吧：假设平均为100个tick)，如果每次存取hashtable要花费100Tick,另庠诩由弦恍┮滴翊淼氖奔洌桶床僮饕淮问荼硪1个毫秒来计算吧。

那么1秒钟的时间内就可以处理1000次用户的查询操作；

问题是如果100万用户同时来查询我们该怎么办？

我想可以做负载均衡及服务器集群，当然还要涉汲到网络接口的流量限制，说来就话很长了。

总之，第二个问题看起来，似乎是我们可以通过其它的手段将单台服务器无法处理的工作量分摊到多台服务器中去进行；

于是可以得出第一个背景结论：

设置一台服务器将其做为用户状态服务器，用于记录系统中所有用户是否在线等状态信息；通过对服务器制作集群来分摊访问压力；

现在我们就可以做以下比较形象的结论和假设了：

(1)一个用户要查询自己所有好友的在线状态，那么这个用户向刚才所说到的状态服务器发送一条查询消息，服务器可以很快的返回用户的状态给客户；

(2)用户在登录系统后通知状态服务器自己已经登陆了。

(3)用户如果从某台具体的功能服务器掉线后，则由这台服务器通知状态服务器用户掉线；

(4)用户可能会在多台功能服务器中来回切换，由客户端与服务器端共同协作以判断用户是为否掉线;

(5)用户定期向状态服务器报告自己的存活状态，如果长时间不报告，则状态服务器把用户从自己的内存状态表中删除；

以上我的瞎解，不一定对，必竞自己没有做过,仅供参考。