本人菜鸟，初步接触物联网协议开发，要求从移动物联网上接入20000余只设备（可能以后更多），移动物联网HTTP实时推送设备上报的数据，服务收到数据后进行解析，并根据解析及时返回移动平台响应报文，移动平台收到报文后响应给设备，完成一次数据上报通信。有以下要求：①移动推送数据后必须及时返回移动响应，否则移动平台认为推送失败重复推送，多次失败后推送服务停止（耗时影响很大）。②收到推送的数据后，需要及时处理，并回复响应报文（设备集中上报时，并发影响很大）。③，响应给移动平台是需要调用http-post方式，并根据是否成功进行下一步操作（网络波动，api接口耗时影响很大）。
踩的坑第一版使用异步方式开发，使用tornado框架，但每条数据进行解析、生成响应报文、数据存储（已优化，基本不耗时），给平台发送设备响应报文，会消耗很多时间，造成不能及时给移动推送服务进行确认，移动判断推送失败，多次推送，一段时间后推送服务停止。
第二版使用tornado框架配合rabbitMQ消息中间件，将响应设备报文后调用api的步骤存放在消息消费者中处理，但启动少量的消费者时，不足以短时间消费大量的并发数据。启动大量消费者时，长时间没有数据时，造成资源浪费。
第三版则使用tornado框架配合twisted框架，设计两个服务，第一个服务主要接收推送的数据，并使用Tcp/Ip方式将数据推送到第二个服务，由于第一个服务使用tornado框架，采用异步模式，处理速度很快，能够并发大量数据并耗时很少。能够及时返回移动推送服务响应。第二个服务则使用twisted框架多线程方式。每次收到数据后增加一个线程进行处理，能够解决并发，每条数据不相互影响，出现耗时不会影响到其它线程。能够满足要求
第四版则使用tornado框架配合自带的线程的方式进行操作，因为该框架虽然是异步方式，但有一种情况会出现同步的效果。当某个接口短时间推送大量的数据过来，tornado进行处理时会判断是否为同一个（客户），如果是同一个则会先处理之前的请求，后来的请求挂起，当前一个请求处理完毕后才会处理后面的请求，不会异步处理，造成同步的效果，导致大量的数据阻塞。具体设计方法为，收到数据先向请求端发送接收成功的确认，提前结束推送请求：
# 接收到数据后立马给返回接收确认
self.write(json_encode({'code': 200, 'result': u'成功'}))
self.flush()
self.finish() # 提前刷新输出缓冲区
之后加入线程进行处理
