消息队列(mq)是什么?

是生产者先将消息投递一个叫队列的容器中，然后再从这个容器中取出消息，最后再转发给消费者。

消息队列是 Microsoft 的消息处理技术，它在任何安装 Microsoft Windows 的计算机组合中，为任何应用程序提供消息处理和消息队列功能，无论这些计算机是否在同一个网络上或者是否同时联机。

消息队列网络是能够相互间来回发送消息的任何一组计算机。网络中的不同计算机在确保消息顺利处理的过程中扮演不同的角色。它们中有些提供路由信息以确定如何发送消息，有些保存整个网络的重要信息，而有些只是发送和接收消息。

消息队列的类型介绍：

消息队列目前主要有两种类型：POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。每个消息队列都有一个队列头，用结构struct msg_queue来描述。队列头中包含了该消息队列的大量信息。包括消息队列键值、用户ID、组ID、消息队列中消息数目等等。

消息队列就是一个消息的链表，可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的。

网页的交互模式，基于HTTP实现与服务器的交互，这些游戏的后端可以使用任何Web开发语言来实现，比如PHP，Java，C#，Ruby，Python这些，都没有问题。

游戏的前端现在普遍依然使用Flash平台，开发语言就是ActionScript，比较前卫的游戏有使用HTML5的，就是JavaScript，还有一些社交平台上的游戏直接使用HTML页面来做交互，有一些传统游戏厂商转过来做网页游戏的也有采用ActiveX技术直接把现有的游戏移植过来的，这些游戏前端往往采用C＋＋这些来开发。

有些游戏需要实时与服务器交互（比如MMORPG），这些游戏的后端往往就是和传统的网游一样的架构，开发语言也一般会比较传统的采用C+＋，也有一些采用Erlang来搞定网络及分布式计算的平台部分。

值得一提的是Lua语言，Lua在网页游戏的客户端用的不多，但是在服务器端依然有不少采用，主要是用在游戏的实际逻辑部分。

在线更新，更新过程中可以正常进行游戏，不用停机。不停机更新一般都都是进行比较小规模的更新·，大规模的（比如版本的更迭）都是要停机更新。

停机维护的根本意义在于让服务器休息一下处理一下数据或者更新系统新文件和内容。

服务器就像一起玩局域网游戏一样，也是一台电脑，但能力很大，配置很高，开久了会影响运行程序速度。

在停机维护之前，服务商一般会发布公告、提示停机维护的时间段，以提醒用户做好相应准备。

停机维护期间用户无法使用服务商所提供的服务，停机维护经常会在公告的时间段之前进行完毕。

不仅仅是网游需要进行停机维护，一些大型的系统有时也要进行停机维护，以维持系统的正常运行。

扩展资料

不停机更新技术：

事实上，大多游戏服务器分为逻辑程序服务器和数据库服务器，如果是线上运营的服务器，基本上是在至少两台主机上。

在发现几个逻辑服务器中的bug，或者加了某些功能，比如少加了三个金币，多算了一点经验等，只需要在测试服测试完毕，上传覆盖执行文件(jar或php)，但是依然要重启逻辑服务器进程。

而Erlang的热升级技术，就带了更好的体验。Erlang原本脱胎于电信行业，Jow Armstrong 在描述Erlang的设计要求时期中就提到了“软件维护应该能在不停止系统的情况下进行”。

在实践中，因为这种不停服务的热更新获益良多，终于不用再等到半夜没人的时候再做更新了，对于一些紧急的bug修复，热更新实在是一把利器。

Erlang热更新的秘密其实都集中在code模块、code模块是Erlang Code Server暴露出来的对外接口，其职责就是把已经编译好的模块加载到Erlang的运行时环境。

代码版本有两个概念，当前版本代码“current”和老版本代码“old”,一旦模块被加载就变成“current”,再有一个版本过来被加载,之前的版本就变成“old”,新加载的变成“current”。

这时候,两个版本还是同时存在,新的请求执行的时候会使用新的版本,而老版本的代码还会被使用因为还有其他模块的调用“old”版本中。

再进行一次热更新,这时就有第三个实例被加载,code server就会终止掉还在驻留在“old”版本代码依赖的进程。然后第三个实例成为“current”,之前版本的“current”被标记成“old”。

这种方法有效降低了因版本升级而导致的用户流失。

-停机维护

英雄联盟-12月4日不停机版本更新公告

消息队列（Message Queue）是一种进程间通信或同一进程的不同线程间的通信方式。

Broker（消息服务器）

Broker的概念来自与Apache ActiveMQ，通俗的讲就是MQ的服务器。

Producer（生产者）

业务的发起方，负责生产消息传输给broker

Consumer（消费者）

业务的处理方，负责从broker获取消息并进行业务逻辑处理

Topic（主题）

发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅 者，实现消息的广播

Queue（队列）

PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收。

Message（消息体）

根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

点对点模型用于消息生产者和消息消费者之间点到点的通信。

点对点模式包含三个角色：

每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，可以放在内存 中也可以持久化，直到他们被消费或超时。

特点：

发布订阅模型包含三个角色：

多个发布者将消息发送到Topic，系统将这些消息传递给多个订阅者。

特点：

AMQP即Advanced Message Queuing Protocol，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。

优点：可靠、通用

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。

优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。

优点：命令模式（非topic\queue模式）

XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。

优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大

RabbitMQ 是实现 AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 RabbitMQ 主要是为了实现系统之间的双向解耦而实现的。当生产者大量产生数据时，消费者无法快速消费，那么需要一个中间层。保存这个数据。

RabbitMQ 是一个开源的 AMQP 实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

Channel（通道）

道是两个管理器之间的一种单向点对点的的通信连接，如果需要双向交流，可以建立一对通道。

Exchange（消息交换机）

Exchange类似于数据通信网络中的交换机，提供消息路由策略。

RabbitMq中，producer不是通过信道直接将消息发送给queue，而是先发送给Exchange。一个Exchange可以和多个Queue进行绑定，producer在传递消息的时候，会传递一个ROUTING_KEY，Exchange会根据这个ROUTING_KEY按照特定的路由算法，将消息路由给指定的queue。和Queue一样，Exchange也可设置为持久化，临时或者自动删除。

Exchange有4种类型：direct(默认)，fanout， topic， 和headers。

不同类型的Exchange转发消息的策略有所区别：

Binding（绑定）

所谓绑定就是将一个特定的 Exchange 和一个特定的 Queue 绑定起来。Exchange 和Queue的绑定可以是多对多的关系。

Routing Key（路由关键字）

exchange根据这个关键字进行消息投递。

vhost（虚拟主机）

在RabbitMq server上可以创建多个虚拟的message broker，又叫做virtual hosts (vhosts)。每一个vhost本质上是一个mini-rabbitmq server，分别管理各自的exchange，和bindings。vhost相当于物理的server，可以为不同app提供边界隔离，使得应用安全的运行在不同的vhost实例上，相互之间不会干扰。producer和consumer连接rabbit server需要指定一个vhost。

假设P1和C1注册了相同的Broker，Exchange和Queue。P1发送的消息最终会被C1消费。

基本的通信流程大概如下所示：

Consumer收到消息时需要显式的向rabbit broker发送basic。ack消息或者consumer订阅消息时设置auto_ack参数为true。

在通信过程中，队列对ACK的处理有以下几种情况：

即消息的Ackownledge确认机制，为了保证消息不丢失，消息队列提供了消息Acknowledge机制，即ACK机制，当Consumer确认消息已经被消费处理，发送一个ACK给消息队列，此时消息队列便可以删除这个消息了。如果Consumer宕机/关闭，没有发送ACK，消息队列将认为这个消息没有被处理，会将这个消息重新发送给其他的Consumer重新消费处理。

消息的收发处理支持事务，例如：在任务中心场景中，一次处理可能涉及多个消息的接收、处理，这应该处于同一个事务范围内，如果一个消息处理失败，事务回滚，消息重新回到队列中。

消息的持久化，对于一些关键的核心业务来说是非常重要的，启用消息持久化后，消息队列宕机重启后，消息可以从持久化存储恢复，消息不丢失，可以继续消费处理。

fanout 模式

模式特点：

direct 模式

任何发送到Direct Exchange的消息都会被转发到routing_key中指定的Queue。

如果一个exchange 声明为direct，并且bind中指定了routing_key，那么发送消息时需要同时指明该exchange和routing_key。

简而言之就是：生产者生成消息发送给Exchange， Exchange根据Exchange类型和basic_publish中的routing_key进行消息发送 消费者：订阅Exchange并根据Exchange类型和binding key(bindings 中的routing key) ，如果生产者和订阅者的routing_key相同，Exchange就会路由到那个队列。

topic 模式

前面讲到direct类型的Exchange路由规则是完全匹配binding key与routing key，但这种严格的匹配方式在很多情况下不能满足实际业务需求。

topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到binding key与routing key相匹配的Queue中，但这里的匹配规则有些不同。

它约定：

以上图中的配置为例，routingKey=”quickorangerabbit”的消息会同时路由到Q1与Q2，routingKey=”lazyorangefox”的消息会路由到Q1，routingKey=”lazybrownfox”的消息会路由到Q2，routingKey=”lazypinkrabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）；routingKey=”quickbrownfox”、routingKey=”orange”、routingKey=”quickorangemalerabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey。

RabbitMQ，部署分三种模式：单机模式，普通集群模式，镜像集群模式。

普通集群模式

多台机器部署，每个机器放一个rabbitmq实例，但是创建的queue只会放在一个rabbitmq实例上，每个实例同步queue的元数据。

如果消费时连的是其他实例，那个实例会从queue所在实例拉取数据。这就会导致拉取数据的开销，如果那个放queue的实例宕机了，那么其他实例就无法从那个实例拉取，即便开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，但得等这个实例恢复了，然后才可以继续从这个queue拉取数据， 这就没什么高可用可言，主要是提供吞吐量 ，让集群中多个节点来服务某个queue的读写操作。

镜像集群模式

queue的元数据和消息都会存放在多个实例，每次写消息就自动同步到多个queue实例里。这样任何一个机器宕机，其他机器都可以顶上，但是性能开销太大，消息同步导致网络带宽压力和消耗很重，另外，没有扩展性可言，如果queue负载很重，加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue。此时，需要开启镜像集群模式，在rabbitmq管理控制台新增一个策略，将数据同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

Kafka 是 Apache 的子项目，是一个高性能跨语言的分布式发布/订阅消息队列系统（没有严格实现 JMS 规范的点对点模型，但可以实现其效果），在企业开发中有广泛的应用。高性能是其最大优势，劣势是消息的可靠性（丢失或重复），这个劣势是为了换取高性能，开发者可以以稍降低性能，来换取消息的可靠性。

一个Topic可以认为是一类消息，每个topic将被分成多个partition(区)，每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量），offset为一个long型数字，它是唯一标记一条消息。它唯一的标记一条消息。kafka并没有提供其他额外的索引机制来存储offset，因为在kafka中几乎不允许对消息进行“随机读写”。

Kafka和JMS（Java Message Service）实现(activeMQ)不同的是:即使消息被消费，消息仍然不会被立即删除。日志文件将会根据broker中的配置要求，保留一定的时间之后删除；比如log文件保留2天，那么两天后，文件会被清除，无论其中的消息是否被消费。kafka通过这种简单的手段，来释放磁盘空间，以及减少消息消费之后对文件内容改动的磁盘IO开支。

对于consumer而言，它需要保存消费消息的offset，对于offset的保存和使用，有consumer来控制；当consumer正常消费消息时，offset将会"线性"的向前驱动，即消息将依次顺序被消费。事实上consumer可以使用任意顺序消费消息，它只需要将offset重置为任意值。(offset将会保存在zookeeper中，参见下文)

kafka集群几乎不需要维护任何consumer和producer状态信息，这些信息有zookeeper保存；因此producer和consumer的客户端实现非常轻量级，它们可以随意离开，而不会对集群造成额外的影响。

partitions的设计目的有多个。最根本原因是kafka基于文件存储。通过分区，可以将日志内容分散到多个server上，来避免文件尺寸达到单机磁盘的上限，每个partiton都会被当前server(kafka实例)保存；可以将一个topic切分多任意多个partitions，来消息保存/消费的效率。此外越多的partitions意味着可以容纳更多的consumer，有效提升并发消费的能力。(具体原理参见下文)。

一个Topic的多个partitions，被分布在kafka集群中的多个server上；每个server(kafka实例)负责partitions中消息的读写操作；此外kafka还可以配置partitions需要备份的个数(replicas)，每个partition将会被备份到多台机器上，以提高可用性。

基于replicated方案，那么就意味着需要对多个备份进行调度；每个partition都有一个server为"leader"；leader负责所有的读写操作，如果leader失效，那么将会有其他follower来接管(成为新的leader)；follower只是单调的和leader跟进，同步消息即可。由此可见作为leader的server承载了全部的请求压力，因此从集群的整体考虑，有多少个partitions就意味着有多少个"leader"，kafka会将"leader"均衡的分散在每个实例上，来确保整体的性能稳定。

Producers

Producer将消息发布到指定的Topic中，同时Producer也能决定将此消息归属于哪个partition；比如基于"round-robin"方式或者通过其他的一些算法等。

Consumers

本质上kafka只支持Topic。每个consumer属于一个consumer group；反过来说，每个group中可以有多个consumer。发送到Topic的消息，只会被订阅此Topic的每个group中的一个consumer消费。

如果所有的consumer都具有相同的group，这种情况和queue模式很像；消息将会在consumers之间负载均衡。

如果所有的consumer都具有不同的group，那这就是"发布-订阅"；消息将会广播给所有的消费者。

在kafka中，一个partition中的消息只会被group中的一个consumer消费；每个group中consumer消息消费互相独立；我们可以认为一个group是一个"订阅"者，一个Topic中的每个partions，只会被一个"订阅者"中的一个consumer消费，不过一个consumer可以消费多个partitions中的消息。kafka只能保证一个partition中的消息被某个consumer消费时，消息是顺序的。事实上，从Topic角度来说，消息仍不是有序的。

Kafka的设计原理决定，对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息。

Guarantees

Kafka就比较适合高吞吐量并且允许少量数据丢失的场景，如果非要保证“消息可靠传输”，可以使用JMS。

Kafka Producer 消息发送有两种方式(配置参数 producertype)：

对于同步方式(producertype=sync)？Kafka Producer 消息发送有三种确认方式(配置参数 acks)：

kafka的设计初衷是希望作为一个统一的信息收集平台，能够实时的收集反馈信息，并需要能够支撑较大的数据量，且具备良好的容错能力。

持久性

kafka使用文件存储消息，这就直接决定kafka在性能上严重依赖文件系统的本身特性。且无论任何OS下，对文件系统本身的优化几乎没有可能。文件缓存/直接内存映射等是常用的手段。因为kafka是对日志文件进行append操作，因此磁盘检索的开支是较小的；同时为了减少磁盘写入的次数，broker会将消息暂时buffer起来，当消息的个数(或尺寸)达到一定阀值时，再flush到磁盘，这样减少了磁盘IO调用的次数。

性能

需要考虑的影响性能点很多，除磁盘IO之外，我们还需要考虑网络IO，这直接关系到kafka的吞吐量问题。kafka并没有提供太多高超的技巧；对于producer端，可以将消息buffer起来，当消息的条数达到一定阀值时，批量发送给broker；对于consumer端也是一样，批量fetch多条消息。不过消息量的大小可以通过配置文件来指定。对于kafka broker端，似乎有个sendfile系统调用可以潜在的提升网络IO的性能:将文件的数据映射到系统内存中，socket直接读取相应的内存区域即可，而无需进程再次copy和交换。 其实对于producer/consumer/broker三者而言，CPU的开支应该都不大，因此启用消息压缩机制是一个良好的策略；压缩需要消耗少量的CPU资源，不过对于kafka而言，网络IO更应该需要考虑。可以将任何在网络上传输的消息都经过压缩。kafka支持gzip/snappy等多种压缩方式。

生产者

负载均衡: producer将会和Topic下所有partition leader保持socket连接；消息由producer直接通过socket发送到broker，中间不会经过任何“路由层“。事实上，消息被路由到哪个partition上，有producer客户端决定。比如可以采用“random““key-hash““轮询“等，如果一个topic中有多个partitions，那么在producer端实现“消息均衡分发“是必要的。

其中partition leader的位置(host:port)注册在zookeeper中，producer作为zookeeper client，已经注册了watch用来监听partition leader的变更事件。

异步发送：将多条消息暂且在客户端buffer起来，并将他们批量的发送到broker，小数据IO太多，会拖慢整体的网络延迟，批量延迟发送事实上提升了网络效率。不过这也有一定的隐患，比如说当producer失效时，那些尚未发送的消息将会丢失。

消费者

consumer端向broker发送“fetch”请求，并告知其获取消息的offset；此后consumer将会获得一定条数的消息；consumer端也可以重置offset来重新消费消息。

在JMS实现中，Topic模型基于push方式，即broker将消息推送给consumer端。不过在kafka中，采用了pull方式，即consumer在和broker建立连接之后，主动去pull(或者说fetch)消息；这中模式有些优点，首先consumer端可以根据自己的消费能力适时的去fetch消息并处理，且可以控制消息消费的进度(offset)；此外，消费者可以良好的控制消息消费的数量，batch fetch。

其他JMS实现，消息消费的位置是有prodiver保留，以便避免重复发送消息或者将没有消费成功的消息重发等，同时还要控制消息的状态。这就要求JMS broker需要太多额外的工作。在kafka中，partition中的消息只有一个consumer在消费，且不存在消息状态的控制，也没有复杂的消息确认机制，可见kafka broker端是相当轻量级的。当消息被consumer接收之后，consumer可以在本地保存最后消息的offset，并间歇性的向zookeeper注册offset。由此可见，consumer客户端也很轻量级。

对于JMS实现，消息传输担保非常直接:有且只有一次(exactly once)。

在kafka中稍有不同:

at most once: 消费者fetch消息，然后保存offset，然后处理消息；当client保存offset之后，但是在消息处理过程中出现了异常，导致部分消息未能继续处理。那么此后"未处理"的消息将不能被fetch到，这就是"at most once"。

at least once: 消费者fetch消息，然后处理消息，然后保存offset。如果消息处理成功之后，但是在保存offset阶段zookeeper异常导致保存操作未能执行成功，这就导致接下来再次fetch时可能获得上次已经处理过的消息，这就是"at least once"，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态。

exactly once: kafka中并没有严格的去实现(基于2阶段提交，事务)，我们认为这种策略在kafka中是没有必要的。

通常情况下“at-least-once”是我们首选。(相比at most once而言，重复接收数据总比丢失数据要好)。

kafka高可用由多个broker组成，每个broker是一个节点；

创建一个topic，这个topic会划分为多个partition，每个partition存在于不同的broker上，每个partition就放一部分数据。

kafka是一个分布式消息队列，就是说一个topic的数据，是分散放在不同的机器上，每个机器就放一部分数据。

在08版本以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。

08版本以后，才提供了HA机制，也就是就是replica副本机制。每个partition的数据都会同步到其他的机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。

写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。

kafka会均匀的将一个partition的所有replica分布在不同的机器上，从而提高容错性。

如果某个broker宕机了也没事，它上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性了。

写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。

消息丢失会出现在三个环节，分别是生产者、mq中间件、消费者：

RabbitMQ

Kafka

大体和RabbitMQ相同。

Rabbitmq

需要保证顺序的消息投递到同一个queue中，这个queue只能有一个consumer，如果需要提升性能，可以用内存队列做排队，然后分发给底层不同的worker来处理。

Kafka

写入一个partition中的数据一定是有序的。生产者在写的时候 ，可以指定一个key，比如指定订单id作为key，这个订单相关数据一定会被分发到一个partition中去。消费者从partition中取出数据的时候也一定是有序的，把每个数据放入对应的一个内存队列，一个partition中有几条相关数据就用几个内存队列，消费者开启多个线程，每个线程处理一个内存队列。

跨平台泛指程序语言、软件或硬件设备可以在多种作业系统或不同硬件架构的电脑上运作。

广义面言，一般的计算语言都可做到跨平台，开发商只需要提供各种平台下的Runtime/中间件环境即可。严格而言是指用某种计算机语言编制的程序只需要做小量的修改，编译之後即可在另外一种平台下运行，此时并不提供Runtime/中间件环境。例如Java是一种提供Runtime环境的跨平台解决方案，而C而是一种标准且严格的跨平台语言。

跨平台概念是软件开发中一个重要的概念，即不依赖于操作系统，也不信赖硬件环境。一个操作系统下开发的应用，放到另一个操作系统下依然可以运行。相对而言如果某种计算机语言不用修改代码即可做到高度跨平台，那么此语言就越抽象，硬件控制力就越低，只适合开发高度抽象的模型系统。诸如java,delphi和易语言，都已做到了跨平台。它们将可以在多种系统下开发，运行和维护。

大部分电脑语言从绝对意义而言，都是跨平台的：因为都是以高级的、人类可读的方式来对CPU发号指令，这样也就没必要依赖於任何作业系统。但如果要用系统的部件工具箱，来新建用户图形界面（GUI），就可能会用到开发员特定系统中的API函数或库类。虽然C++是跨平台的，但Windows下用到Win32 API的C++程式，一般就不能在Unix机器上编译。不同编译器对语言规范的解释也有所差异。这样的话，在针对不同系统进行构建之前，程式就得加以考虑。

一些如Java这样的语言，从一开始就意识到要在各个平台下运行，所以跨平台在其平台的本地语言环境中已经实现。例如，Java可以跨平台使用，正是由於Swing库在许多平台下的实现。类似的，能进行跨平台的文件存取，是因为有各自平台下文件存取的库。以此类推，各种跨平台问题，都需要各自的本地库来解决。wxWidgets框架就是这样的一个跨平台库，根据不同的跨平台问题，提供了许多不同的解决方案；类似的库有许多，可以根据不同语言的跨平台开发，而采用相应的库。

针对每种作业系统、CPU，而提供并测试各自的编译版本，这种做法的可行性很小；开源软体则允许用户自己来编译目的码（object code），这样在跨平台方面更好一些。类似的，那些解释型语言，或者需要虚拟机的语言，也更加符合跨平台的要求，因为用户也要自己进行编译。Sun公司的Java虚拟机Hotspot，只针对几种而不是全部平台，提供编译好的二进位文件。例如，Sun对於GNU/Linux，只支持i386平台，但如果谁在PowerPC或者SPARC电脑上运行Linux，就只好自己编译本地的机器码（machinecode），或者使用第三方软体，才能运行Java程式。

许多API（应用程式介面）依赖於平台。OpenGL可以看作是跨平台的，因为其不依赖於任何特定的作业系统、CPU构架或者某个牌子的图形设备。特定平台的API可以在其他系统上作为兼容层而新建，例如WINE的库，Windows程式就可以在UNIX系统上运行。

另外许多程式语言还有跨平台的扩展以及中间件，这样程式设计师对於同样的原始码，只要进行一点小修改，就可以在不同平台下编译/运行，例如Qt和wxWidgets。

支持多种作业系统的软体

1 资料库管理系统(DBMS)：

MySQL：Solaris、Linux、Windows、FreeBSD

Oracle：Solaris、Linux、Windows

2 网站伺服器、应用程式伺服器：

Apache：Solaris、Linux、Windows、FreeBSD

Tomcat：Linux、Windows、FreeBSD

3 网际网路浏览器：

Mozilla Firefox：Linux、FreeBSD、Solaris、AIX、Windows、

可在不同作业系统上进行软体开发的程式语言

C语言、C++、Java

Perl、Tcl、Erlang

Python、Delphi+Kylix、REALbasic

开发java应用的跨平台，包含五方面的内容：

一、跨应用服务器

二、跨数据库

三、跨操作系统

四、跨浏览器

五、多语言支持

下面分别来说一下。

■跨应用服务器

这一点，看起来好像有些多余，java的口号之一不就是“一次编译，到外运行”嘛，可实际经验告诉我们，这仅仅是一个口号而已。实际中是“一次编译，到处调试”。为什么会这样？从应用服务器来说，各个产品或多或少都在标准的java规范之上进行了一些拓展，小规模的应用开发，多以tomcat为基准；大规模的应用，多以weblogic/websphere为基准。

那么开发完成的应用，可否在所有的应用服务器上正常部署呢？答案是否定的。在tomcat5上部署没问题，在tomcat4上却可能有问题；在tomcat5/4上没问题，却可能在resin/jetty/weblogic/websphere上有问题。在我的经历中，在resin/jetty/weblogic为基准进行开发的应用，部署到tomcat上基本上没什么问题。但是以tomcat为基准的应用，部署到其他应用服务器中，却可能出现各种各样的问题。这与tomcat本身的定位和开发方式有关，它更像是一个学术产品，而不是一个商业产品。

小型的应用，我偏好resin，它的速度、稳定性、兼容性、中文处理，都是非常不错的。相比而言，以“纯java、快速”著称的jetty，就不太令人满意。jetty的4/5/6各个版本中，对session的存放位置、webxml的标准、struts的plugin的支持、log4j的处理，都各不相同。在最新的jetty6中，竟然会要命地“不能使用sessionvalidate()”方法，一使用此方法之后，就无法再使用set/getAttribute了。

也曾经在将一个应用转移到websphere5上时，费劲周折。这个应用跑在其他应用服务器上都没问题，但是一部署到ws5上，就无法正常加载struts的配置文件。本以为是struts配置文件写得有问题，但即便把所有的action/form配置均去掉，只保留一个空的配置文件，也无法正常启动。最后实在无法，只能乱碰运气，考虑是否是struts的几个jar包版本有问题，经检查，发现应用中使用的是struts12的jar包，换成struts11的jar包，再启动后就一切正常。这样的问题，可真的是折磨人呢。

所以，我认为跨应用服务器是很重要的。你不能告诉客户，俺们的系统只能跑在tomcat下面，至于您花重金购买的weblogic/websphere，对不起，我们暂时还不支持。客户会吐血的。

■跨数据库

经常看到某大公司产品，要求必须使用oracle或者sqlserver数据库，你想换个数据库来部署？没门，人家说了，我们的产品只支持这一种数据库，你就老实的用吧。但对于客户方来说，为了减少投资，并且保证内部系统尽可能使用同一种数据库以减少维护成本（总不能请一个oracle DBA，再请一个sqlserver DBA吧？），总会希望新系统使用的数据库是以前用过的吧。

现在有了hibernate，在此基础上开发的应用，基本上是能满足跨数据库要求的，个人认为这是hibernate最大的亮点。但也要注意，在开发中尽可能考虑到不同数据库的特性。诸如sqlserver的text/image字段上不能查distinct，oracle内的各种对象名称长度不得超过30等，尽量不要调用数据库的内部特性（如存储过程、视图等）

■跨操作系统

这一点，貌似没有什么可说的，很少有开发出的系统只能部署在一种操作系统上的。不过有一点也要注意，如果系统中某些功能依赖于通过JNI来调用windows本地组件的话，比如打印、word/excel操作，或与只能运行在windows下的报表组件(如国内的数巨报表、如意报表)集成的话。

■跨浏览器

窃以为，如果只是做国内的应用，这一点倒不重要，就以IE为标准来开发也未尝不可。

PS：完全支持IE也不是一件容易的事情，IE5/6本身就有不少的差异。

但如果产品本身想立足于世界，想与国外产品竞争，对浏览器的全面支持也必不可少。至少应该同时支持ie和firefox吧，如果对自身严格要求的话，我认为应以opera为标准，opera对html/css/javascript的标准是实现和支持得最好的浏览器。

■多语言支持

如果您的产品只想在中国卖，根本就不考虑世界市场，那这一条就pass好了。

Java程序跨平台需要注意什么

使用Java语言编写应用程序最大的优点在于“一次编译，处处运行”，然而这并不是说所有的Java程序都具有跨平台的特性，事实上，相当一部分的Java程序是不能在别的操作系统上正确运行的，那么如何才能编写一个真正的跨平台的Java程序呢下面是在编写跨平台的Java程序是需要注意的一些事情：

1编写Java跨平台应用程序时，你可以选择JDK10，11，12或支持它们的GUI开发工具如：Jbuilder,VisualAgeforJava等等，但是必须注意你的Java程序只能使用Java核心API包，如果要使用第三方的类库包，则该类库包也要由Java核心包开发完成，否则在发布你的程序的时候还得将支持该Java类库包的JVM发布出去。也就是说，你的程序需要是100%纯Java的。举一个例子，VisualJ++就不是纯Java的，由VisualJ++编写的程序也就不具有平台无关性。

2无论你使用的是JDK或其他开发工具，在编译时都要打开所有的警告选项，这样编译器可以尽可能多的发现平台相关的语句，并给出警告。虽然不能保证没有编译时警告错误的程序一定是跨平台的，但含有警告错误的程序却很有可能是非平台无关的。

3在程序中使用任何一个方法的时候，要详细察看文档，确保你使用的方法不是在文档中已经申明为过时的方法(Deprecatedmethod),也不是文档中未标明的隐含方法(Undocumentedmethod)。

4退出Java程序时尽量不要使用javalangSystem的exit方法。Exit方法可以终止JVM，从而终止程序，但如果同时运行了另一个Java程序，使用exit方法就会让该程序也关闭，这显然不是我们希望看到的情况。事实上要退出Java程序，可以使用destory()退出一个独立运行的过程。对于多线程程序，必须要关闭各个非守护线程。只有在程序非正常退出时，才使用exit方法退出程序。

5避免使用本地方法和本地代码，尽可能自己编写具有相应功能的Java类，改写该方法。如果一定要使用该本地方法，可以编写一个服务器程序调用该方法，然后将现在要编写的程序作为该服务器程序的客户程序，或者考虑CORBA(公共对象请求代理)程序结构。

6Java中有一个类似于Delphi中的winexec的方法，javalangruntime类的exec方法，作为该方法本身是具有平台无关性的，但是给方法所调用的命令及命令参数却是与平台相关的，因此，在编写程序时要避免使用，如果一定要调用其他的程序的话，必须要让用户自己来设置该命令及其参数。比如说，在windows中可以调用notepadexe程序，在linux中就要调用vi程序了。

7程序设计中的所有的信息都要使用ASCII码字符集，因为并不是所有的操作系统都支持Unicode字符集，这对于跨平台的Java中文软件程序不能不说是一大噩耗。

8在程序中不要硬性编码与平台相关的任何常量，比如行分隔符，文件分隔符，路径分隔符等等，这些常量在不同的平台上是不同的，比如文件分隔符，在UNIX和MAC中是“/”，在windows中是“\”，如果要使用这些常量，需要使用jdavautilProperties类的getProperty方法，如javautilPropertiesgetProperty(“fileseparator”)可以获得文件分隔符，getProperty(“lineseparator”)返回行分隔符，getProperty(“pathseparator”)返回路径分隔符。

9在编写跨平台的网络程序时，不要使用javanetInetAddress类的getHostName方法得到主机名，因为不同的平台的主机名格式是不同的，最好使用getAddress得到格式相同的IP地址，另外，程序中所有的主机名都要换成IP地址，比如www263net就要换成相应的IP地址。

10涉及文件操作的程序需要注意：不要在程序中硬性编码文件路径，理由和8中一样，只是这一点特别重要，因此单独提出。而且，不同平台对于文件名使用的字符及最大文件名长度的要求不同，编写你的程序的时候要使用一般的ASCII码字符作为文件的名字，而且不能与平台中已存在的程序同名，否则会造成冲突。

11如果您写的程序是GUI程序，在使用AWT组件时不能硬性设置组件的大小和位置而应该使用Java的布局管理器(layoutmanager)来设置和管理可视组件的大小和位置，否则有可能造成布局混乱。

12由于不同的操作系统，不同的机器，系统支持的颜色和屏幕的大小和分辨率都不同，如何获得这些属性呢使用javaawtSystemcolor类可以获得需要的颜色，如该类的inactiveCaption就是窗口边框中活动标题的背景颜色，menu则是菜单的背景颜色。使用javaawtToolkit的getScreenResolution可以以“象素每英寸”为单位显示屏幕的分辨率。该类的getScreenSize可以得到屏幕大小(英寸)，loadSystemColors可以列出所有的系统颜色。

编程语言的种类有：Python、Java到Objective-C等。

C：操作系统、嵌入式、驱动开发。

C++：图形图像、科研、通信、桌面软件、游戏、游戏服务器。

C#：Windows桌面软件、服务器。

Java：Java架构师/微服务/分布式/高并发/性能优化/源码解析-学习视频。

GO：高性能服务器应用，比较年轻。

Erlang：高并发服务器应用，多用于游戏。

Python：Web、科学计算、运维。

Perl：运维、文本处理，用的较少。

Lisp：科研，一种逻辑语言，用于人工智能。

Node：一个JavaScript运行环境。

Haskell：Haskell是一种标准化的、通用纯函数编程语言，数学逻辑方面。

各部分所占比例：

Java占比168％：最主要的原因是因为Java比C++或者其他语言相对其安全性、便携性、可维护性以及其他高级语言的并发性更好。同时Java是默认的软件行业的应用程序开发语言，在金融服务行业的大量使用，投资银行和电子商务应用空间也非常之大。

C语言占比149％：C语言是一门通用计算机编程语言，应用广泛。C语言的设计目标是提供一种能以简易的方式编译、处理低级存储器、产生少量的机器码以及不需要任何运行环境支持便能运行的编程语言。主要用于嵌入式开发，操作系统开发，文字处理程序开发等。它对编写程序限制少，灵活性大，功能强。

遇到服务器故障，问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手：

一、尽可能搞清楚问题的前因后果

不要一下子就扎到服务器前面，你需要先搞明白对这台服务器有多少已知的情况，还有故障的具体情况。不然你很可能就是在无的放矢。

必须搞清楚的问题有：

故障的表现是什么？无响应？报错？

故障是什么时候发现的？

故障是否可重现？

有没有出现的规律（比如每小时出现一次）

最后一次对整个平台进行更新的内容是什么（代码、服务器等）？

故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)

基础架构（物理的、逻辑的）的文档是否能找到

是否有监控平台可用 （比如Munin、Zabbix、 Nagios、 New Relic…

什么都可以）

是否有日志可以查看 （比如Loggly、Airbrake、 Graylog…）

最后两个是最方便的信息来源，不过别抱太大希望，基本上它们都不会有。只能再继续摸索了。

二、有谁在

代码如下:

$ w

$ last

用这两个命令看看都有谁在线，有哪些用户访问过。这不是什么关键步骤，不过最好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。（ne cook in

the kitchen is enough）

三、之前发生了什么

$

history查看一下之前服务器上执行过的命令。看一下总是没错的，加上前面看的谁登录过的信息，应该有点用。另外作为admin要注意，不要利用自己的权限去侵犯别人的隐私哦。

到这里先提醒一下，等会你可能会需要更新 HISTTIMEFORMAT

环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令，同样会令人抓狂的。

四、现在在运行的进程是啥

代码如下:

$ pstree -a

$ ps aux

这都是查看现有进程的。 ps aux 的结果比较杂乱， pstree -a 的结果比较简单明了，可以看到正在运行的进程及相关用户。

五、监听的网络服务

代码如下:

$ netstat -ntlp

$ netstat -nulp

$

netstat -nxlp

我一般都分开运行这三个命令，不想一下子看到列出一大堆所有的服务。netstat -nalp倒也可以。不过我绝不会用 numeric 选项

（鄙人一点浅薄的看法：IP 地址看起来更方便）。

找到所有正在运行的服务，检查它们是否应该运行。查看各个监听端口。在netstat显示的服务列表中的PID 和 ps aux 进程列表中的是一样的。

如果服务器上有好几个Java或者Erlang什么的进程在同时运行，能够按PID分别找到每个进程就很重要了。

通常我们建议每台服务器上运行的服务少一点，必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着，那还是做个记录，回头有空的时候清理一下，重新组织一下服务器。

六、CPU 和内存

 代码如下:

$ free -m

$ uptime

$ top

$

htop

注意以下问题:

还有空余的内存吗 服务器是否正在内存和硬盘之间进行swap

还有剩余的CPU吗 服务器是几核的 是否有某些CPU核负载过多了

服务器最大的负载来自什么地方 平均负载是多少

七、硬件

代码如下:

$ lspci

$ dmidecode

$

ethtool

有很多服务器还是裸机状态，可以看一下：

找到RAID 卡 (是否带BBU备用电池)、 CPU、空余的内存插槽。根据这些情况可以大致了解硬件问题的来源和性能改进的办法。

网卡是否设置好

是否正运行在半双工状态 速度是10MBps 有没有 TX/RX 报错

八、IO 性能

代码如下:

$ iostat -kx 2

$ vmstat 2 10

$ mpstat

2 10

$ dstat --top-io --top-bio

这些命令对于调试后端性能非常有用。

检查磁盘使用量：服务器硬盘是否已满

是否开启了swap交换模式 (si/so)

CPU被谁占用：系统进程 用户进程 虚拟机

dstat 是我的最爱。用它可以看到谁在进行 IO： 是不是MySQL吃掉了所有的系统资源 还是你的PHP进程

九、挂载点 和 文件系统

 代码如下:

$ mount

$ cat /etc/fstab

$ vgs

$

pvs

$ lvs

$ df -h

$ lsof +D / / beware not to kill your box

/

一共挂载了多少文件系统

有没有某个服务专用的文件系统 (比如MySQL)

文件系统的挂载选项是什么： noatime

default 有没有文件系统被重新挂载为只读模式了？

磁盘空间是否还有剩余

是否有大文件被删除但没有清空

如果磁盘空间有问题，你是否还有空间来扩展一个分区？

十、内核、中断和网络

 代码如下:

$ sysctl -a | grep

$ cat

/proc/interrupts

$ cat /proc/net/ip_conntrack / may take some time on busy

servers /

$ netstat

$ ss -s

你的中断请求是否是均衡地分配给CPU处理，还是会有某个CPU的核因为大量的网络中断请求或者RAID请求而过载了？

SWAP交换的设置是什么？对于工作站来说swappinness 设为 60 就很好,

不过对于服务器就太糟了：你最好永远不要让服务器做SWAP交换，不然对磁盘的读写会锁死SWAP进程。

conntrack_max 是否设的足够大，能应付你服务器的流量

在不同状态下(TIME_WAIT, …)TCP连接时间的设置是怎样的？

如果要显示所有存在的连接，netstat 会比较慢， 你可以先用 ss 看一下总体情况。

你还可以看一下 Linux TCP tuning

了解网络性能调优的一些要点。

十一、系统日志和内核消息

 代码如下:

$ dmesg

$ less /var/log/messages

$

less /var/log/secure

$ less /var/log/auth

查看错误和警告消息，比如看看是不是很多关于连接数过多导致？

看看是否有硬件错误或文件系统错误

分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。

十二、定时任务

 代码如下:

$ ls /etc/cron + cat

$ for user in

$(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done

是否有某个定时任务运行过于频繁

是否有些用户提交了隐藏的定时任务

在出现故障的时候，是否正好有某个备份任务在执行？

十三、应用系统日志

这里边可分析的东西就多了,

不过恐怕你作为运维人员是没功夫去仔细研究它的。关注那些明显的问题，比如在一个典型的LAMP（Linux+Apache+Mysql+Perl）应用环境里:

Apache & Nginx; 查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone 错误。

MySQL;

在mysqllog找错误消息，看看有没有结构损坏的表， 是否有innodb修复进程在运行，是否有disk/index/query 问题

PHP-FPM; 如果设定了 php-slow 日志, 直接找错误信息 (php, mysql, memcache, …)，如果没设定，赶紧设定。

Varnish; 在varnishlog 和 varnishstat 里, 检查 hit/miss比

看看配置信息里是否遗漏了什么规则，使最终用户可以直接攻击你的后端？

HA-Proxy;

后端的状况如何？健康状况检查是否成功？是前端还是后端的队列大小达到最大值了？

结论

经过这5分钟之后，你应该对如下情况比较清楚了：

在服务器上运行的都是些啥？

这个故障看起来是和 IO/硬件/网络 或者 系统配置 (有问题的代码、系统内核调优, …)相关。

这个故障是否有你熟悉的一些特征？比如对数据库索引使用不当，或者太多的apache后台进程。

你甚至有可能找到真正的故障源头。就算还没有找到，搞清楚了上面这些情况之后，你现在也具备了深挖下去的条件。继续努力吧！