消息中间件的设计思路

[newsunsmartlink]

由于工作的需要要写一个消息中间件，第一个版本是基本于Win32的，目前正在开发中，但遇到了一些困难，想的不是很通，不知有没有这样面经验的人给我点拨一二。

我现在思路是这样的：
消息服务器端(支持程序)处理模式

系统有多线程来完成(用线程池管理线程及任务)，设系统监听的端数为X个，那么线程池生成：X个临听线程 + 一个数据打包线程 + 一个消息转发线程，各线程对应一种工作(任务)，分别如下：

监听任务(监听线程)：负责监听一个TCP端口，接受客户的连接，如果有客户发送数据过来，还要负责接收，并将接收的数据交给数据打包线程进行数据打包；

数据打包任务：将监听线程得到的数据进行打包，形成一个完成的消息，并放置于安全消息队列中，为消息转发作好准备；

消息转发任务：从安全消息队列中取出消息，并将消息发送给消息接收者；

客户端程序(用户开发支持)目前实现了以下API接口:
int Connect(void);//连接消息服务器
int Disconnect(void);//断开与消息器的连接
bool IsConnected(void);//是否与消息服务器连通中
int PutMessage(char* lpszDenitation, char* pBuffer, int nLength, unsigned char bMsgType);//传送一条消息(向一目标应用)
int PutMessage(unsigned char bGroup, char* pBuffer, int nLength, unsigned char bMsgType);//收取一条消息(向一组目标应用)
int HaveMessage(void);//判断当前安全队列中是否有消息
int HaveMessage(int nTimeOut);//判断当前安全队列中是否有消息，带超时，如果在指定是时间内还有消息可取则返回
int GetMessage(char* lpszSource, char* lpszDenitation, unsigned char& cStatus, char* lpszBuff);//取一条消息
int GetErrorMessage(int nErrorCode, char* lpszErrorMessage);//根据错误号获取对应的错误信息

目前系统实现的功能是：
0、可靠消息队列；
1、消息的可靠传送；
2、异步通讯；
3、名子服务；
4、消息的发布与订阅(目前未实现)；
5、数据加密、数据压缩；
6、安全认证。
7、其它一些细小的功能；

我现在问题是：
1、我目前这种服务器处理模式是否合理，如果不合理，什么样的处理模式更好些？
2、用户开发接口定义的是否合理，如果不合理，怎修改较为合理？
3、在我目前实现的功能中，有没有落下什么消息中间件必备的功能？

无限期待中……

[wyly]

我做了个简单的在用，不过是用UDP的。
我用在一个非紧密连接的系统中，不要100%的可靠传送。但是要发布和广播。所以用了UDP。
如果系统中消息密集，经常连接断开，同时连接的终端很多（比如上千个），我觉得用 TCP是不是不太合适？
还有，你的系统中终端是怎么定义id的？一个字符串？
有没有可能要多个消息中心转发才能完成通信的情况？

[wyly]

对了，看了你对程序的描述，我觉得有些问题：
1.如果用TCP，一般监听线程只有一个，除非你用多个端口。
2.线程池只用于连接通信的线程。
3.整个消息的存储用什么数据结构？是在一个线程里统一管理还是分布式管理？消息线程和通信线程怎么交互？
4.打包和转发没必要单独开线程，线程多了不好。

[newsunsmartlink]

自己UP一下！

[szjay]

嗯，我刚做了一个东东，和你描述的功能差不多，就是一个服务器对应多个客户端，每个客户端收发信息都要经过服务器中转。
其实做出来并不难，难的是稳定性。当客户端非常多或是数据交换极频繁时如何保证服务器不崩溃才是难点。
据说用完成端口是较率最高的，但偶不懂，还请高手指点一下。

[newsunsmartlink]

To: wyly()
1.我的确用得是多端，可以定义要监听端品数量(一个为基准，其它根据数量依次加一)。
2.目前我的线程池其实是一个线程管理器，不能算是严格意义上的线程池，目的是为提高系统的通用性。线程池中有若干个线程，完成一项具体任务：线程数=监听端口数 + 2；
3.消息结构大致为：版本号+目标应用名+发送应用名+消息体长度+消息生存周期+消息类型+操作码+消息状态(定义为80字节，有预留)。
消息的整个处理过程是：
接收线程接收到数据(此时只是数据，不规则，不是消息)->数据缓冲区
消息打包线程从数据缓冲区取出数据进行打包->可靠消息队列
消息转发线程从可靠消息队列中取消息，判断是否在生存期内，如果是则转发之；
4.打包使用专门的线程主要是考虑如果客户数较多，而且数据量较大时，打包工作相对复杂，这样可以提高些响应时间，其实这样线程数量也不算太多：线程数=监听端口数 + 2

不知这样是否有不合理的地方，望多指教！

[newsunsmartlink]

To: wyly()
由于上面说要用TCP，所以没办法，至于如果连接数非常大，我目前也没有合适的处理方法，而且目前这个消息中心也没有经过大连接数的测试。

我的系统中终端是用名字服务来完成的，我认为一个终端（不论它是用作服务器还是客户端）是个网络节点，一个网络节点有系统中唯的标识。

目前我还没碰到需多个消息中转发才能完成的情况，但随着我目前从事的这个行业软件应用来看，以后一定会用到，但至于怎么做我现在还没想好。不知您是否有什么好的思路，大家共享一下！！

[wangyu4882]

我目前也在做，我使用UDP向SERVER发包，SERVER用一个接受端口。一个发送端口。
一个接受线程监视接受端口，一个发送线程监视发送端口，一个消息处理线程。
用了一个接受队列->消息处理->一个发送队列.
有没有更好的方法，在JAVA中，怎样设置这3个线程的SLEEP时间，能有高效率，

还有，CLIENT怎样刷新在线名单呢

[wyly]

我也在考虑转发怎么样做比较好？是不是象IP协议学习，搞个路由表，呵呵，会不会太复杂了？

[newsunsmartlink]

看来大家的思路有些类似的地方！

Client在线名单刷新我觉得可以用定时器做，但不知有没有更好办法，希望有的同志提供一下。

如果要十分合理的设置各个线程的Sleep时间，我觉得最好有一个专门的调度线程来管理。

[cheeryanhua]

关于消息中转，我现在的系统很类似：
需要注意信息的同步问题，如果消息中间件的地址发生变化，需要即时通知相关的中间件服务器。
我们现在准备做一个消息同步包，每个中间件都有相关的同步现成。需要同步则将数据加入相关的数据同步表中，通过同步线程将数据发送，和接受。

关于客户端接口，请问是客户端程序主动去调用还是，使用通知方式来处理的。
打包和取包，我是把取包给接收线城处理，应为TCP是流方式，由接收线程将数据包进行分析，从中取出合法数据包，而后加入到包处理模块中进行相关的路由处理。

是否考虑过支持多种通信方式 的中转，如PSTN等。
是否考虑过中间件服务器自己运行状态的管理。
是否需要考虑消息的重发

[mumu_yulin]

我觉得你用多个tcp端口不太好，为什么不用socket提供的select函数来避免这种方法呢？
另外的设计就看你的具体应用了。

[见招拆招]

强烈关注

[newsunsmartlink]

cheeryanhua：
“如果消息中间件的地址发生变化，需要即时通知相关的中间件服务器”，我对这句话的不是很清楚，能否说得详细些，谢谢！如何通知呢？

是否考虑过支持多种通信方式 的中转，如PSTN等：我目前没有考虑过，不知您有何好的方法，共享一下吧！

是否考虑过中间件服务器自己运行状态的管理：不是很明白，能否说得清楚些，中间件服务器是指消息服务器还是指应用服务器。

是否需要考虑消息的重发：如果可以做到可靠消息传输，我认为这项应该考虑到了。

多谢！

[cheeryanhua]

如果消息服务器的地址改变，如果通知同其协做的消息服务器。告知其IP地址改变。
或者是其它需要同步的信息。（可以使用一个共享数据库来或同步消息包来解决这个问题）

关于多种通信方式的传输，需要建立一个通信方式服务表，根据用户的设置启动不同的通信服务。
比如网络通信服务,PSTN通信服务，需要注意消息选择通信方式，根据消息的目的来判断需要使用的通信方式。

状态的监控指的是消息服务器的状态监控，比如当前在线用户数目，当前服务的线程数目，当前服务的类型，当前线程的CPU，内存等状态，当前计算机网络信息，通过这些相关信息使用户可以知道当前消息服务器的运行状态。从而可以采取不同的方式解决当前的问题。

[cheeryanhua]

是否考虑模式设计等相关问题，将通信服务与业务相关的问题进行隔离。
是否考虑过建立一个通信服务框架，可以根据不同的业务应用选择不同的框架模式。

[newsunsmartlink]

mumu_yulin(linest)：

用多个TCP端口不好，为什么呢？我现在也用得的select多路复用的，但不知您是不是有更好的办法，共享一下吧，谢谢！！

[himming]

关注。。。。。。