2018-03-29-阿里菜鸟面试（电面一）

一、阿里面试题：

1、项目介绍，项目的难点在哪里？答、极光推送

2、大概的场景描述：客户有个需求就是想把黑色照片变成白色照片。（不知道我描述的问题有没有偏差）

首先客户把黑色照片发给了我（客户端和服务器端中间的），客户端的请求一直在继续，我把客户的图片发给服务器，服务器此时在处理照片将其变成白色，服务器在处理照片时需要处理一段时间。此时客户端应该怎么挂起请求？也就是说，怎样处理客户端的等待、挂起？使得，自从客户端发走后，还能接收到服务器发给我，我再发给客户端的信息。

答：极光推送的流程？（(⊙o⊙)…我也不知道对不对）

经过搜索好像还可以答：基于消息传递的异步协议（MQTT），实现异步通信。。（o(╥﹏╥)o，没有想起来这个协议，应该说自己没怎么了解）

我们将创建一个工作队列（Work Queue），它会发送一些耗时的任务给多个工作者（Worker）。 工作队列（又称：任务队列——Task Queues）是为了避免等待一些占用大量资源、时间的操作。当我们把任务（Task）当作消息发送到队列中，一个运行在后台的工作者（worker）进程就会取出任务然后处理。当你运行多个工作者（workers），任务就会在它们之间共享。 这个概念在网络应用中是非常有用的，它可以在短暂的 HTTP 请求中处理一些复杂的任务。

Callbacks will be called to allow the application to process events as necessary. These callbacks are described below.

（翻译为：将调用回调以允许应用程序根据需要处理事件。）

MQTT基础知识：

参考链接：https://mcxiaoke.gitbooks.io/mqtt-cn/content/mqtt/0301-CONNECT.html

3、现在用的是http为什么你们之后想使MQTT?说一说http和MQTT的区别

我的答案：举了个列子：就是补货APP推送给我消息的时候，我这边可能会有失败的时候，当我接收推送失败时，此时补货APP那边就可以不用再进行反复的推送。我失败的这边只要去缓存里面取推送的信息就好。

4、场景描述：

我这边有2000万用户，对于每个用户有积分机制，我想查看前多少名高的积分用户，怎么实现？不用数据库，就是单纯的在内存时！

答：快速排序算法（我也不知道对不对o(╥﹏╥)o）

紧接着描述快速排序。。。。。。。

二、经过搜索知识点总结

2.1、从HTTP到MQTT：一个移动后端案例概述

来自:http://www.infoq.com/cn/news/2016/11/HTTP-MQTT-Mobile-backend

在基于位置服务的移动应用领域，移动设备端和服务端之间总是存在大量的交互。设备向服务端发送它的位置信息和其它设备信息，服务端接收这些数据，对它们进行处理，并返回给设备端一些命令。设备端根据这些命令执行一些操作，比如GPS数据的收集和发送频率等。

设备端和服务端之间可以通过多种通信协议进行交互，比如HTTP（同步）或者基于消息传递的异步协议。因为移动网络的不稳定性，在选择通信协议时要综合考虑它的稳定性和性能。同时，考虑到移动设备对电池使用时间的敏感度，最好能够选择一个相对比较节省资源的协议，这样可以减少对电池的消耗。

HTTP是一种同步无状态的协议，不支持推送，设备端需要通过轮询模拟推送，反复的轮询需要耗费额外的资源。相比之下，另一种基于消息传递的协议MQTT在这种情况下似乎更有优势：

• MQTT可以保持设备与服务器之间的长连接，避免反复的轮询，减少资源消耗，所以更加省电
• MQTT可以在设备和服务器之间建立双向连接，从而可以使用推送

有一个基于位置服务的移动项目，最开始使用的是HTTP协议，但是基于上述的原因，需要使用MQTT来替换HTTP。下面来看看如何实现这个架构的演变。

首先，在EC2上安装一个Mosquitto代理。设备端把原先HTTP里的消息头和消息体合并到一个MQTT消息里，并发送到Mosquitto代理的一个主题上。后端的API端点对这个主题进行订阅，然后处理接收到的消息。API服务对消息进行处理后，把相应的响应消息发回Mosquitto代理，再推送给设备端。

不过在有多个API服务器的情况下，存在重复处理消息的问题。因为多个API服务器同时订阅相同的主题，它们会收到一个消息的多个拷贝。为了解决这个问题，在系统里引入了AWS的IoT。AWS IoT在它的内部使用了MQTT代理，同时包含了一个强大的规则引擎，可以利用这个引擎对Mosquitto的消息进行处理，比如把它们保存起来，发送通知或者使用lambda函数处理消息的响应。不过这里需要先把Mosquitto和AWS IoT桥接起来，这样消息就可以进入到AWS IoT。然后使用lambda函数对消息进行处理，抽取消息里的消息头和消息体，最后调用后端的HTTP API服务。

使用这套架构会涉及到：

• QoS - MQTT提供了三层QoS。这个是非常重要的，因为在底层网络不是很稳定的时候，MQTT仍然能通过重试等手段保证消息可以被正确送达。
• 消息保留 - MQTT可以为每个主题保留最后一个消息。这对客户端来说，可以反应主题的状态。
• 处理MQTT消息 - 设置一个Mosquitto代理并让消息流入这个代理是很容易的，但因为缺少第三方包，要让一般的规则引擎来出来这些消息有点棘手。所以最后选用了AWS IoT自带的规则引擎。
• 日志 - 需要对Mosquitto的日志进行捕捉，并保存起来，方便监控和问题定位。可以使用remote syslog来把日志传输到Papertrail。

除了服务器端，在客户端也需要使用MQTT的客户端包。MQTT有各种语言客户端，并支持Android、iOS平台。

2.2、从现有的移动端（Android）消息推送方案中，也可以看出MQTT协议和XMPP协议的优缺点

方案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字节），且极易扩展，适合二次开发