[Android]关于用户并发访问下载初步探讨

今天单位开发了一款软件，反正用户量不是很多，大约也就1000人左右，Android客户端40MB左右，IOS客户端100MB左右，期间出现了很多问题。

PS：楼主是做J2EE网站的，然后对于Server高并发的处理也不是很精通，就大体说说我的理解和看法，希望大家可以给我批评指证。其实我发现部门开发的app存在以下问题：1.软件更新和登陆的顺序：我个人感觉，应该是在登录之后进行升级，这样儿做有很多好处，比方说如果传统的后台是用servlet开发，那么登陆的用户放到session，设置一个filter对资源访问权限做出控制，这样儿就能避免恶意下载带来的Server压力过大带来的问题。2.用户下载Server应该如何处理：之前用过迅雷和快播的人应该知道，在这两款曾经风靡一时的软件里面，下载的任务存在两个数据：DL和UL。DL -> DownloadUL-> Upload那么，为什么会出现两个数据：我们知道，如果说是Client下载一个文件的话，以Tomcat为例，我们需要直接访问域名然后加上相对于webapps目录下的文件的路径，也就是说，文件被先加载到内存然后再去占用带宽，返回到Client。这就是我为什么刚开始的时候强调一下部门开发app的大小。假设如果并发访问，10个人1G内存，那么毫无疑问，16G内存支持的访问量是百人左右。app刚在群里发布，肯定访问量会很大，大家都很新鲜，那么就出现了本来下载2MB/S变成了40MB下载了20多分钟。言归正传，为什么我要说快播和迅雷这两个公司的产品，大家都知道下载一个小电影最少1G，那么快播和迅雷拥有上亿的用户数量，为什么两款软件的使用情况和公司一千规模的用户量相差特别大。原因就出现在了UL。不得不说迅雷和快播的技术人员很聪明，用户下载的文件都保存在Server，但是处理用户的下载的方式却不一样。用户所需要的资源放在Server硬盘里面，当Client请求某一个资源的时候，因为之前的登录过程每一个Client都建立了一个长连接，那么下载的文件ID 和 你的Socket放到了数据库。这个时候这个长连接就起作用了。此时Server会把两个已经下载资源的Client和未下载资源的Client做一个Socket链接，那么Server完成的工作就是链接两个Client，让Client进行分享自己的资源，那么这就是UL（上传带宽的来源）。这个就很明显了吧，为什么快播和迅雷可以处理这么大的用户的访问量。因此我的解决思路是：更改登陆和验证的顺序，对于每一个登陆的用户做一个长连接，当还有用户需要更新的时候，直接对于这两个Client或者更多的Client做Socket通讯，这里面可能需要一些算法做支撑，因为没有实际写过代码，所以只是说一些大体的思路和意见，吴国以后转做app服务，可能更加深入的分析贴出一些关键代码出来，第一次入职，写的有点儿菜，大家凑合着看吧！