中间件有多种类型，Java的RMI FJB 属于（）中间件。

答案：B

通常将中间件分为数据库访问中间件、远程过程 调用中间件、面向消息中间件、事务中间件、分布式对象中间件等。(1)数据库访问中间件：通过一个抽象层访问数据库，从而允许使用相同或相似的 代码访问不同的数据库资源。典型技术如Windows平台的ODBC和Java平台的JDBC等。(2)远程过程调用中间件（Remote Procedure Call，RPC):是一种分布式应用程序 的处理方法。一个应用程序可以使用RPC来“远程”执行一个位于不同地址空间内的过 程，从效果上看和执行本地调用相同。一个RPC应用分为服务器和客户两个部分。服务器提供一个或多个远程操作过程； 客户向服务器发出远程调用。服务器和客户可以位于同一台计算机，也可以位于不同的 计算机，甚至可以运行在不同的操作系统之上。客户和服务器之间的网络通讯和数据转 换通过代理程序（Stub与Skeleton)完成，从而屏蔽了不同的操作系统和网络协议。(3)面向消息中间件（Message-OrientedMiddleware，MOM):利用高效可靠的消息 传递机制进行平台无关的数据传递，并可基于数据通信进行分布系统的集成。通过提供 消息传递和消息队列模型，可在分布环境下扩展进程间的通信，并支持多种通讯协议、 语言、应用程序、硬件和软件平台。典型产品如IBM的MQSeries。(4)分布式对象中间件：是建立对象之间客户/服务器关系的中间件，结合了对象技 术与分布式计算技术。该技术提供了一个通信框:架，可以在异构分布计算环境中透明_ 传递对象请求。典型产品如OMG的CORBA、Java的RMI/FJB、Microsoft的DCOM[等。(5)事务中间件：也称事务处理监控器（Transaction Processing Monitor, TPM),提供特大规模事务处理的可靠运行环境。TPM位于客户和服务器之间，完成事务管理与 调、负载平衡、失效恢复等任务，以提高系统的整体性能。典型产品如IBM/BEA的 Tuxedo结合对象技术的对象事务监控器（object Transaction Monitor, OTM)如支持 EJB的JavaEE应用服务器等。

检查下网络连接是否通着，检查方式：

telnet IP 端口号 如果通着然后通过netstat -an|grep 你这个中间件域的端口进行查看网络

因为对方可能是双网卡，你到对方的请求是走的他的另一个网卡。

据说还有种查看方式是traceroute查看路由的，你找下资料可以看看，这个我也还不会呢。

由于应用范围和产品历史不同，这些通信子系统也就千差万别。关于几种常用的中间件产品，比如IBM MQSeries，CICS/TXSeries和BEA Tuxedo的通信机制，是经常被软件工程师们讨论的话题，因为许多产品特性都是与此息息相关的。我这里仅仅粗浅地介绍一下最表层的一些架构，希望能够抛砖引玉。首先，我想对比一下数据传输类中间件MQSeries与TPM类交易中间件CICS/TXSeries和BEA Tuxedo。MQSeries与CICS/TXSeries或BEA Tuxedo有很大的不同，因为MQSeries被设计为一个以异步数据通信为基础的中间件。MQSeries这类中间件的特点是“存储/转发”(对持久消息，直接保存到硬盘；对非持久消息，开始时先保存到共享内存)，而TPM中间件(包括TXSeries和Tuxedo)没有这个“存储”的功能，而侧重分布式的实时交易处理。数据传输类中间件MQSeries适于以下的应用场合：数据跨异种系统的可靠传输。 高速地传送数据或请求，接收方一般不会因为工作量大而导致溢出或丢弃。

这是因为数据传输中间件系统的接收器快速存储收到的数据而不急于进行处理和响应。 消耗时间长的交易，或消耗时间长短不定的交易，或者是批处理作业。

服务程序(MQ守护程序)可以高效率的执行批量交易和长时间交易，而完全不用考虑通信等待的问题，通信由相关的队列、通道和收听器来维护。 工作量按时间分布不均匀的服务器系统。

服务程序可以充分利用系统空闲的时间(比如夜间)工作。 分布式的复杂系统

分布式的复杂系统存在各种各样的意外事件和复杂情况，如果全部采用同步系统，一个工作点的失败可以导致整个系统的瘫痪。异步和“存储/转发”是解决相互等待的最佳途径。 相对数据传输中间件MQSeries，TPM类交易中间件(CICS/TXSeries和BEA Tuxedo)有以下的优势：针对高速且有返回信息的交易，有极快的响应速度。 强大的分布式事务处理的能力。

MQSeries也支持两阶段提交，但异步的性质决定了它不能支持分布式应用的统一交易处理。 完全屏蔽了通信层的工作，使开发更加简便，专注于业务系统。 MQSeries的通信机制的核心是通道和收听器。通道设置决定了通信的协议、参数和相关方法。MQSeries的收听器有两种机制：基于inetd的守护进程机制(amqcrsta)，和基于线程响应的机制(runmqlsr)。这两种机制各有优缺点。runmqlsr的性能更出色，但老版本的MQSeries在接收过多的连接时有一些问题。amqcrsta能支持更多的通道和客户访问，但可能造成系统资源更多的损耗。MQSeries v53以后，runmqlsr已经得增强，我个人认为这种方式更好。当然，无论如何，要接受更多客户机或通道的访问，必须调整qmini或Windows注册表的一些参数(MaxChannels, MaxActiveChannels, ListenerBacklog)，以及一些相关的操作系统的内核参数。以客户机访问方式为例，MQSeries的每个客户机都与收听器(amqcrsta或runmqlsr)建立Socket连接，而MQSeries收听器通过IPC机制通知Queue Manager Agent (amqzlaa0)读写消息和队列。客户机访问方式采用的是短连接，而通道连接方式采用的是长连接。关于短连接和长连接的比较，后面还要加以讨论。CICS/TXSeries的通信处理与MQSeries的通道连接方式类似，使用长连接的方式。CICS/TXSeries的TCP/IP收听器进程叫做cicsip，在v51以后，其功能大大增强。CICS/TXSeries使用一个LD:TCPProcessCount参数，其内部是用了Socket的SO_REUSEADDR选项，支持多个收听器进程是用相同的IP和端口。这个特性大大简化了多并发情况的客户机设置，可以采用相同的服务器收听器设置。当然这种特性会增加服务器收听器的设计难度。cicsip进程将请求写入请求队列，实际上是写入Region Pool中的共享内存。而每个应用服务器进程(cicsas)通过IPC机制读取请求，经过计算，返回信息到共享内存中的应答队列，再通过收听器返回客户机。可以看出，CICS/TXSeries在内部使用了一个异步处理的方式，其目的是充分利用系统资源，达到最高的吞吐效率。但对外仍然是一个同步通信的系统。但是与MQSeries不同，CICS/TXSeries没有任何存储数据或请求的操作，队列的容量和数据的生存期也远远小于MQSeries。在这些方面，CICS/TXSeries与Tuxedo没有什么不同。但Tuxedo的通信机制还是有很多不同于CICS/TXSeries的方面：CICS/TXSeries的通信设置很简单，只须设置一个收听器IP和端口就可以了。Tuxedo的通信设置可就多了，本地语言(C, COBOL等)客户访问(WSL)，Java Jolt访问(JSL)，域连接(T/DOMAIN)，集群等等都需要独立的网络设置，使用独立的收听器。而且还有很多看不见的端口被作为客户连接使用(WSH)，网络管理员在配置防火墙时要颇费一番脑筋。 Tuxedo使用短连接的方式，与MQSeries的客户机访问方式相似，但通信方式要复杂一些。以本地语言客户访问的收听器WSL为例：WSL在接收到客户请求后，立即释放连接，而客户机接着使用新建的连接与一个WSH进程继续通信。这种方式可以降低WSL的工作量。 Tuxedo的客户机程序直接与收听器建立Socket连接。CICS/TXSeries的客户机程序通过IPC与一个客户机守护程序(cclclnt)通信，该守护程序(cclclnt)与CICS/TXSeries的服务器建立一个Socket连接。 目前MQSeries和Tuxedo的收听器还不支持复用IP地址和端口，所以如果有太多的客户访问或通道连接，需要增加新的收听器端口。从上面的讨论可以看出：MQSeries的通道连接方式以及CICS/TXSeries采用长连接的通信方式，MQSeries的客户机访问方式以及Tuxedo采用短连接的通信方式。所谓长连接，就是一旦建立连接，一般的应用API不会中断该连接；所谓短连接，就是在一个完整的应用中先建立连接，最后结束该连接，而且程序退出时必然切断连接。这两种通信方式对应用系统有着深刻的影响。短连接灵活方便，避免了下述很多长连接面临的棘手的问题：客户机异常中断，网络中断，包括Windows 9x之类的操作系统正常关闭，都不会通知服务器，造成服务器保持闲置无用的连接，长连接通常要等待“tcp_keepidle”之类的时间，这个时间默认时一般是两个小时。这样会明显加重服务器的负载，无故占用相应的资源。MQSeries采用DISCINT和HBINT等通道参数来避免这个问题。 如果仅仅是少量访问，建立长连接浪费过多的资源。MQSeries也是通过DISCINT和HBINT等通道参数来避免这个问题。 网络相关的故障仅仅影响本次连接。短连接可以隔离故障的影响。

　　IBM有个家伙做了个测试，发现切换线程context的时候，windows比linux快一倍多。进出最快的锁（windows2k的 critical section和linux的pthread_mutex），windows比linux的要快五倍左右。当然这并不是说linux不好，而且在经过实际编程之后，综合来看我觉得linux更适合做high performance server，不过在多线程这个具体的领域内，linux还是稍逊windows一点。这应该是情有可原的，毕竟unix家族都是从多进程过来的，而 windows从头就是多线程的。

　　如果是UNIX/linux环境，采用多线程没必要。

　　多线程比多进程性能高？误导！

　　应该说，多线程比多进程成本低，但性能更低。

　　在UNIX环境，多进程调度开销比多线程调度开销，没有显著区别，就是说，UNIX进程调度效率是很高的。内存消耗方面，二者只差全局数据区，现在内存都很便宜，服务器内存动辄若干G，根本不是问题。

　　多进程是立体交通系统，虽然造价高，上坡下坡多耗点油，但是不堵车。

　　多线程是平面交通系统，造价低，但红绿灯太多，老堵车。

　　我们现在都开跑车，油（主频）有的是，不怕上坡下坡，就怕堵车。

　　高性能交易服务器中间件，如TUXEDO，都是主张多进程的。实际测试表明，TUXEDO性能和并发效率是非常高的。TUXEDO是贝尔实验室的，与UNIX同宗，应该是对UNIX理解最为深刻的，他们的意见应该具有很大的参考意义。

　　多线程的优点：

　　无需跨进程边界；

程序逻辑和控制方式简单；

所有线程可以直接共享内存和变量等；

线程方式消耗的总资源比进程方式好；

多线程缺点：

　　每个线程与主程序共用地址空间，受限于2GB地址空间；

线程之间的同步和加锁控制比较麻烦；

一个线程的崩溃可能影响到整个程序的稳定性；

到达一定的线程数程度后，即使再增加CPU也无法提高性能，例如Windows Server 2003，大约是1500个左右的线程数就快到极限了（线程堆栈设定为1M），如果设定线程堆栈为2M，还达不到1500个线程总数；

线程能够提高的总性能有限，而且线程多了之后，线程本身的调度也是一个麻烦事儿，需要消耗较多的CPU

　　多进程优点：

　　每个进程互相独立，不影响主程序的稳定性，子进程崩溃没关系；

通过增加CPU，就可以容易扩充性能；

可以尽量减少线程加锁/解锁的影响，极大提高性能，就算是线程运行的模块算法效率低也没关系；

每个子进程都有2GB地址空间和相关资源，总体能够达到的性能上限非常大

多线程缺点：

　　逻辑控制复杂，需要和主程序交互；

需要跨进程边界，如果有大数据量传送，就不太好，适合小数据量传送、密集运算

多进程调度开销比较大；

最好是多进程和多线程结合，即根据实际的需要，每个CPU开启一个子进程，这个子进程开启多线程可以为若干同类型的数据进行处理。当然你也可以利用多线程+多CPU+轮询方式来解决问题……

　　方法和手段是多样的，关键是自己看起来实现方便有能够满足要求，代价也合适。