mqtt协议原理(MQTT协议详解)

可以。 XMPP是一种基于标准通用标记语言的子集XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。 所以制作移动IM是没有任何问题的。
MQTT是一个轻量级的消息发布/订阅协议，它是基于手机客户端的消息推送服务器的实现一个理想的解决方案。我们可以从项目下载示例代码，您可以找到一个用PHP实现的服务器。“ 架构如下：wmqtt.jar MQTT协议是由IBM提供。您可以从以下网站下载。您可以添加jar包到自己的Android应用程序。真的消息代理（RSMB），他是一个简单的MQTT剂，由IBM提供小也。默认情况下，1883端口负责接收来自服务器的消息并将它们转发到指定的移动设备。山姆是一个PHP库编写MQTT。你可以从这下载它。send_mqtt.php是后通过山姆接收消息和发送消息到RSMB PHP脚本。<例代码：<> > >> > > > > > >使用Android推XMPP协议>这是我的项目的项目。事实上，官方C2DM服务器谷歌也是XMPP协议包的基础上。XMPP（可扩展通信和表示协议）是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）和在线检测。这项协议可能最终允许互联网用户发送即时消息给任何人在互联网上。androidpn是一个基于java的开源Android的推送通知实现XMPP协议。它包含一个完整的客户端和服务器。研究发现，源代码后，服务器改为基于openfire的另一个开源项目的实现，但更令人沮丧的是androidpn文件写的是韩语，所以整个研究过程是基本的阅读源代码。它的实现原理图如下：androidpn客户端需要使用一个aSmack java开源XMPP协议，这个包是另一个开源项目，基于openfire的味道，但我们不需要自己编译，可以直接使用androidpn客户端asmack.jar里面。xmppconnection的建立和aSmack服务器提供与客户的持久连接，并连接用户的注册和登录认证一样，通过这个连接，接收服务器发送的通知。androidpn服务器也是java语言，基于openfire开源项目，但它的Web部件中使用Spring框架，它不同于openfire。Androidpn服务器主要分为两个部分，一是监听5222端口的XMPP服务，对xmppconnection类的客户沟通，是用户的注册和认证，并发送推送通知消息。Web服务器的另一部分，使用轻量级HTTP服务器，负责接收用户的web请求。服务器架构如下： 上包含四个组成部分，即SessionManager，授权经理，presencemanager和通知经理。SessionManager负责客户端和服务器的会话管理、认证经理负责用户认证客户端的管理，存在经理负责客户端用户登录管理，NotificationManager负责服务器到客户端的消息推送功能的实现。服务器接口如下，分别对应于上述几个功能模块：发送后，可以看到手机端收到的消息：

消息队列（Message Queue）是一种进程间通信或同一进程的不同线程间的通信方式。Broker（消息服务器）Broker的概念来自与Apache ActiveMQ，通俗的讲就是MQ的服务器。Producer（生产者）业务的发起方，负责生产消息传输给brokerConsumer（消费者）业务的处理方，负责从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）进行交互。优点：命令模式（非topicqueue模式）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=”quick.orange.rabbit”的消息会同时路由到Q1与Q2，routingKey=”lazy.orange.fox”的消息会路由到Q1，routingKey=”lazy.brown.fox”的消息会路由到Q2，routingKey=”lazy.pink.rabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息将会被丢弃，因为它们没有匹配任何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"均衡的分散在每个实例上，来确保整体的性能稳定。ProducersProducer将消息发布到指定的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将无法得到消息。GuaranteesKafka就比较适合高吞吐量并且允许少量数据丢失的场景，如果非要保证“消息可靠传输”，可以使用JMS。Kafka Producer 消息发送有两种方式(配置参数 producer.type)：对于同步方式(producer.type=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的数据，是分散放在不同的机器上，每个机器就放一部分数据。在0.8版本以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。0.8版本以后，才提供了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中间件、消费者：RabbitMQKafka大体和RabbitMQ相同。Rabbitmq需要保证顺序的消息投递到同一个queue中，这个queue只能有一个consumer，如果需要提升性能，可以用内存队列做排队，然后分发给底层不同的worker来处理。Kafka写入一个partition中的数据一定是有序的。生产者在写的时候 ，可以指定一个key，比如指定订单id作为key，这个订单相关数据一定会被分发到一个partition中去。消费者从partition中取出数据的时候也一定是有序的，把每个数据放入对应的一个内存队列，一个partition中有几条相关数据就用几个内存队列，消费者开启多个线程，每个线程处理一个内存队列。

android消息推送GCM、XMPP、MQTT三种方案的优劣： 1、GCM服务（Google Cloud Messaging）优点：Google提供的服务、原生、简单，无需实现和部署服务端。缺点：Android版本限制，该服务在国内不够稳定、需要用户绑定Google帐号，受限于Google。2、XMPP协议（Openfire + Spark + Smack）优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。3、MQTT协议优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域，且已有C++版的服务端组件rsmb。缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。d消息推送可以去了解一下极光，极光是个不错的平台。极光紧密围绕移动开发者需求，打造的开发者服务平台，可以提供一站式SaaS服务，通过全面覆盖PC、手机、传感器、无线路由器等多种设备数据，打造全域数据平台。当前，不断更新的SaaS产品及服务已深受国内百万开发者的认可和信赖。
Android推送方案分析（MQTT/XMPP/GCM） 蜗牛TT 发布于 4个月前，共有 11 条评论本文主旨在于，对目前Android平台上最主流的几种消息推送方案进行分析和对比，比较客观地反映出这些推送方案的优缺点，帮助大家选择最合适的实施方案。方案1、使用GCM服务（Google Cloud Messaging）简介：Google推出的云消息服务，即第二代的G2DM。优点：Google提供的服务、原生、简单，无需实现和部署服务端。缺点：Android版本限制（必须大于2.2版本），该服务在国内不够稳定、需要用户绑定Google帐号，受限于Google。方案2、使用XMPP协议（Openfire + Spark + Smack）简介：基于XML协议的通讯协议，前身是Jabber，目前已由IETF国际标准化组织完成了标准化工作。优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。方案3、使用MQTT协议（更多信息见：http://mqtt.org/）简介：轻量级的、基于代理的“发布/订阅”模式的消息传输协议。优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域（参考：http://mqtt.org/software），且已有C++版的服务端组件rsmb。缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。方案4、使用HTTP轮循方式简介：定时向HTTP服务端接口（Web Service API）获取最新消息。优点：实现简单、可控性强，部署硬件成本低。缺点：实时性差。对各个方案的优缺点的研究和对比，推荐使用MQTT协议的方案进行实现，主要原因是：MQTT最快速，也最省流量（固定头长度仅为2字节），且极易扩展，适合二次开发。接下来，我们就来分析使用MQTT方案进行Android消息的原理和方法，并架设自己的推送服务。如果还不明白的 话，要看分析的话，给你个网址：http://m.oschina.net/blog/82059自己看看。
使用GCM服务（Google Cloud Messaging）简介：Google推出的云消息服务，即第二代的G2DM。优点：Google提供的服务、原生、简单，无需实现和部署服务端。缺点：Android版本限制（必须大于2.2版本），该服务在国内不够稳定、需要用户绑定Google帐号，受限于Google。使用XMPP协议（Openfire + Spark + Smack）简介：基于XML协议的通讯协议，前身是Jabber，目前已由IETF国际标准化组织完成了标准化工作。优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。使用MQTT协议（更多信息见：http://mqtt.org/;）简介：轻量级的、基于代理的“发布/订阅”模式的消息传输协议。优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域，且已有C++版的服务端组件rsmb。缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。使用HTTP轮循方式简介：定时向HTTP服务端接口（Web Service API）获取最新消息。优点：实现简单、可控性强，部署硬件成本低。缺点：实时性差。对各个方案的优缺点的研究和对比，推荐使用MQTT协议的方案进行实现，主要原因是： MQTT最快速，也最省流量（固定头长度仅为2字节），且极易扩展，适合二次开发 。接下来，我们就来分析使用MQTT方案进行Android消息的原理和方法，并架设自己的推送服务

消息推送（Push）就是通过服务器把内容主动发送到客户端的过程。运营人员通过自己的产品或第三方工具对用户移动设备进行主动消息推送。完成推送后，消息通知会展示在移动设备的锁定屏幕及通知栏上，用户点击通知即可去往相应页面。现在流行的消息推送实现方式，主要为长链接方式实现。其原理是客户端主动和服务器建立TCP长链接，长链接建立之后，客户端定期向服务器发送心跳包用于保持链接，当有消息要发送的时候，服务器可以直接通过这个已经建立好的长链接，将消息发送到客户端。个推作为国内移动推送领域的早期进入者，于2010年推出个推消息推送SDK产品，十余年来持续为移动开发者提供稳定、高效、智能的消息推送服务，成功服务了人民日报、新华社、CCTV、新浪微博等在内的数十万APP客户。个推消息推送，也是运用的长链接方式实现消息推送的，其长链接稳定性高、存活好，消息送达率高。开发者通过集成个推消息推送SDK，即可简单、快捷地实现Android和iOS平台的消息推送功能，有效提高产品活跃度、增加用户留存。如果您对个推消息推送感兴趣，欢迎点击前往了解详情。个推消息推送工作原理
安卓消息推送的实现方案有下面几种: MQTT协议实现XMPP协议实现C2DM云端推送功能(google官方提供,系统内置,但是国内用不了......)中国统一推送(工信部牵头成立,但是目前只是开了几次会议,并没有什么实际的接口出来,不过以后应该会是中国境内的首选方案)选择第三方消息推送平台，例如极光，个推等，极光成立于2011年，是国内最早开始做开发者服务的一批公司，极光推送的稳定性和送达率一直是业内做的比较好的，具体可以到极光官网了解
要实现APP消息推送，要么自己开发，要么用第三方。我建议选择第三方消息推送平台，比如个推等，APP自己开发技术实现难，而且费钱、费时，个推做消息推送10多年了，在技术和服务上都是受到大大认可的。

采用MQTT协议实现Android推送功能是一种解决方案。MQTT是一个轻量级的消息发布/订阅协议，是实现基于手机客户端的消息推送服务器的理想解决方案。常见的解决方案实现原理：1、轮询(Pull)方式：客户端定时向服务器发送询问消息，一旦服务器有变化则立即同步消息。2、SMS(Push)方式：通过拦截SMS消息并且解析消息内容来了解服务器的命令，但这种方式一般用户在经济上很难承受。3、持久连接(Push)方式：客户端和服务器之间建立长久连接，这样就可以实现消息的及时行和实时性。扩展资料：推送消息注意事项：1、支持第三方推送内容，是要客户端和服务器都支持的，客户端和服务器都导入推送SDK。2、服务器推送内容，可以精确指定推送时间，推送的具体接收人，用户群，位置。3、即推送的维度可以使时间，位置，人群。4、极光使用了两种不同的通知方式，一种是推送通知，一种是推送消息。5、如果要使用androidpn，则还需要做大量的工作，需要理解XMPP协议、理解Androidpn的实现机制，需要调试内部存在的BUG。参考资料来源：百度百科-服务器参考资料来源：百度百科-Android客户端参考资料来源：百度百科-信息推送
一、消息推送基础 消息推送，就是在互联网上通过定期传送用户需要的信息来减少信息过载的一项新技术。推送技术通过自动传送信息给用户，来减少用于网络上搜索的时间。它根据用户的兴趣来搜索、过滤信息，并将其定期推给用户，帮助用户高效率地发掘有价值的信息当我们开发需要和服务器交互的移动应用时，基本上都需要和服务器进行交互，包括上传数据到服务器，同时从服务器上获取数据。一般情况下，客户端与服务器之间通讯客户端是主动的，但这就存在一个问题就是一旦服务器数据有更新或者服务器要下发通知给客户端只能等客户端连接的时候才能实现。这种方式使消息失去了实时性。如何使客户端能够实时的收到服务器的消息和通知，总体来说有两种方式，第一种是客户端使用Pull（拉）的方式，就是隔一段时间就去服务器上获取一下信息，看是否有更新的信息出现。第二种就是 服务器使用Push（推送）的方式，当服务器端有新信息了，则把最新的信息Push到客户端上。这样，客户端就能自动的接收到消息。虽然Pull和Push两种方式都能实现获取服务器端更新信息的功能，但是明显来说Push方式比Pull方式更优越。因为Pull方式更费客户端的网络流量，更主要的是费电量，还需要我们的程序不停地去监测服务端的变化。二、几种常见的解决方案实现原理1）轮询(Pull)方式：客户端定时向服务器发送询问消息，一旦服务器有变化则立即同步消息。2）SMS(Push)方式：通过拦截SMS消息并且解析消息内容来了解服务器的命令，但这种方式一般用户在经济上很难承受。3）持久连接(Push)方式：客户端和服务器之间建立长久连接，这样就可以实现消息的及时行和实时性。三、消息推送解决方案概述A、C2DM云端推送方案在Android手机平台上，Google提供了C2DM（Cloudto Device Messaging）服务。Android Cloud to Device Messaging (C2DM)是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。该服务提供了一个简单的、轻量级的机制，允许服务器可以通知移动应用程序直接与服务器进行通信，以便于从服务器获取应用程序更新和用户数据。该方案存在的主要问题是C2DM需要依赖于Google官方提供的C2DM服务器，由于国内的网络环境，这个服务经常不可用。B、MQTT协议实现Android推送采用MQTT协议实现Android推送功能也是一种解决方案。MQTT是一个轻量级的消息发布/订阅协议，它是实现基于手机客户端的消息推送服务器的理想解决方案。wmqtt.jar 是IBM提供的MQTT协议的实现。我们可以从这里（https://github.com/tokudu/AndroidPushNotificationsDemo）下载该项目的实例代码，并且可以找到一个采用PHP书写的服务器端实现（https://github.com/tokudu/PhpMQTTClient）。C、RSMB实现推送功能Really Small Message Broker (RSMB) ，是一个简单的MQTT代理，同样由IBM提供，其查看地址是：http://www.alphaworks.ibm.com/tech/rsmb。缺省打开1883端口，应用程序当中，它负责接收来自服务器的消息并将其转发给指定的移动设备。SAM是一个针对MQTT写的PHP库。我们可以从这个http://pecl.php.net/package/sam/download/0.2.0地址下载它.D、XMPP协议实现Android推送Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。XMPP(可扩展通讯和表示协议)是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。androidpn是一个基于XMPP协议的java开源Android push notification实现。它包含了完整的客户端和服务器端。但也存在一些不足之处：1） 比如时间过长时，就再也收不到推送的信息了。2）性能上也不够稳定。3）如果将消息从服务器上推送出去，就不再管理了，不管消息是否成功到达客户端手机上。如果我们要使用androidpn，则还需要做大量的工作，需要理解XMPP协议、理解Androidpn的实现机制，需要调试内部存在的BUG。E、使用第三方平台目前国内、国外有一些推送平台可供使用，但是涉及到收费问题、保密问题、服务质量问题、扩展问题等等，又不得不是我们望而却步。四、消息推送完美方案综合以上论述，在建立Android消息推送方面可谓方案多多，但每一款方案都有其优缺点。但无论如何，还是自己搭建一个推送平台是上策。因为你有、他有不如自己有。举个例子，在搭建自有推送平台上建议使用《某某Android消息推送组件》。该组不仅可以拿来即用，并且还可以提供源码以便扩展，实现自己的特殊需求。A、推送原理 Android消息推送组件基于XMPP协议实现Android推送。XMPP（可扩展通讯和表示协议）是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。
楼主你好！根据你的描述，让我来给你回答！ 可以考虑下集成第三方的推送服务，百度推送极光推送之类的。 希望能帮到你，如果满意，请记得采纳哦~~~
1、打开应用时向服务器发申请 2、如果应用一直打开，或者有后台服务，可以定时向服务器发申请 Google本身就有一个推送demo可以用，Google Cloud Message，你可以参考一下，不过国内用Google推送不太稳定，但是我测试的时候基本上都能推送成功。详细的搭建你可以参考我的微博，有什么问题你再问吧
无非就是两种实现方式:客户端定时去服务器查询一下客户端与服务器建议长连接, 一发现数据立即发送给客户端现在有很多这种推送框架, 百度云推送, 极光推送,个推等等.