菜鸟的五个疑问：出租打车司机版（抢单）APP的网络实现等问题

问题描述

通信框架：netty4
协议：tcp
客户端：android   
备注：android client 通过rpc 调用 java server端方法。server 通过调用 android client（也可以说推送）
大概需求：
        出租打车司机版（抢单）
                功能：抢单、车位置上传(5秒一次)、订单统计等等。。。
        服务器：
                功能：逻辑后台实现 、订单推送
      备注：用户量2000人左右   订单量8000~20000  白天多  晚上少   
疑问1：
        server端往client端推送语音的时候，如果没推送完，client端还能请求server么？
疑问2：
        netty  一个连接是对应得一个Channel管道么？  如果交互频繁，单管道会不会处理不过来？
疑问3：
        上传司机车辆所在位置，是用tcp协议呢还是用udp协议，tcp我在心跳里做的，每次心跳我吧经纬度带着给server去 （但用udp是不是更好？考虑流量和速度）
疑问4：
        使用netty4时，server往client推送数据的时候，响应需要3~8秒，网络没问题的情况下，需要排查哪些问题？
疑问5：
        如果网络不好的情况下，传输必然低，如果服务器推送的话或上传司机位置的话，就有可能造成队列堆积？ 我该如何解决这类问题？
        
同时也希望作者给我们讲讲做这类项目的经验，应该怎么做等等问题，对于我们这种菜鸟来说，没什么头绪。以前我们做的时候，android端用的http与后台server交互，响应慢、费流量，所以想换成tcp这种来解决问题。由于经验不足，做的时候很纠结！  
        
由于刚接触这块，了解不多，问题问的可能菜了些，表达能力也差，望作者见谅！

补充

关于“使用netty4时，server往client推送数据的时候，响应需要3~8秒（局域网内也一样）的问题”，已经找到原因，见下图：

如果是全新做这么个系统，以你现在的积累，显然要解决的技术、业务层的东西不是一点点。

我建议你先别慌着下结论：
1）显然这整个系统不只有司机端吧，如果整个架构需要你来考虑，你需要从用户端、到服务端、到司机端进行整体的架构设计，从整体到局部逐一梳理技术点；
2）现在像滴滴打车这样的类似应用已经非常成熟和成功了，建议先下载类似应用详细的有针对性的研究（包括括大的方面有业务形态，细的方面有功能原理，再细到技术的有心跳策略、数据交互方式等），网上已经有很多公开的资料，好好研究下，争取站在前人的肩膀上是降低实现风险的最佳方式。

另外，你的问题目前还过于纠结技术细节，但现在看来，你对整个应有的理解，还需要更深入地进行技术选型和梳理，参考上面的建议，做完后相信都能找到确切的答案。

还有一个你问的问题里，说服务端推送给android端需要3到8秒，这显然太不正常了，在最差的2g窄带下，这样的速度有这种可能性，但你局域网是这样显然极不合理，建议逐行排查代码。我说个我遇到的类似的问题（不确定你会不会也是这个问题，仅供参考）：当初我在写MobileIMSDK时，为了打印客户端的ip和端口信息用于log调试，调用了java的SocketAddress.getHostName()这个方法，导致需要反查DNS，而将每次请求阻塞将近10秒之久。你看看你会不会是这种不良代码导致的。

以上意见仅供参考，如有不妥还请见谅。

引用：JackJiang 发表于 2016-04-05 21:44
如果是全新做这么个系统，以你现在的积累，显然你要解决的技术、业务层的东西不是一点点。
我建议你先别慌 ...

我这个很简单，跟滴滴业务不一样，业务我这边很熟悉了已经，现在就是用netty  那几个疑问让我很纠结，希望作者给解答一下

你的问题里关于语音留言的处理，你可以看看这个帖子里的回复，http://www.52im.net/thread-175-1-1.html
不知是否是你要的答案。

引用：JackJiang 发表于 2016-04-05 21:59
你的问题里关于语音留言的处理，你可以看看这个帖子里的回复，http://www.52im.net/thread-175-1-1.html
...

语音对于我来说不太重要 ，我现在最关心的是通道，疑问1-5也是对这个tcp协议和channel ，我害怕引起队列导致堵塞，之后软件就给人感觉非常慢、卡

引用：xiaojiazu 发表于 2016-04-05 22:02
语音对于我来说不太重要 ，我现在最关心的是通道，疑问1-5也是对这个tcp协议和channel ，我害怕引起队列 ...

你如果对TCP没有太多技术经验，建议找到开源或者可靠的类似实现，不然后面可能会因你并不熟练的代码实现导致的网络拥塞、粘包等（对于新手来说，这很容易出现，而且没有技术积累的话并不容易处理），你会非常郁闷。

另外，你不要被这所谓的2000人在线给迷惑了，如果这是个普通的信息系统类APP，这2000人用根本就不是问题，现成的服务端高并发解决方案。但现在你的业务里已经非常接近即时通讯应用，而且可以想像的出来，这个应用能够搞到的软硬件资源，撑死一到两台入门服务端，那么从总体负载来说，加上网络通讯、db存储等业务逻辑，处理不当的话，你的系统实现实际上挑战并不小。

看看有关滴滴出行的这个帖子，或许会有所启发：http://www.52im.net/thread-254-1-1.html