来到公司接到项目，已有用户在1亿左右，日活跃用户可能在100W。这些对于我来说，都是一些天文数字。之前开发的应用最多也就是地区性的几千人用而已。所以接到这个项目总体还是很兴奋的，也有点怵。不过挑战只是机遇的另外一种说法。
项目立项：7月20号 ，集合了目前所有的技术骨干人员，都是组长级的去开会了。
项目提交：8月18号 包括产品经理设计 美工出图 测试
实际开发周期：14天左右 7天调试 然后提交
一切就是这么残酷。没办法，这是最大的老大的项目，不能说NO只能说YES。那就干吧。
开始记录一些心得，和成长的过程。
对于一个android前台来说，如果帮助后台减压。因为视频软件带宽资源有限，越好的优化越能提高软件的体验。这些对于有用户群的软件是非常重要的！
那么问题来了,即前台如何帮助后台减压。
现在的前端开发模式，都是前端想后端进行请求，后端返回数据。那么如果无同一时间，向服务器的一个接口发送10W条请求，对于小公司来说，那是一个灾难！肯定会蹦。
我感觉问题是这样的。
第一如果我的服务器每秒中数据吞吐量是100K每个请求2K那么我可以同时为50人服务。
但如果我把请求变成1K那么就是100人，那么要是0.5K就是200人。这就是从10->1很简单，但是从1->0却是无限难的！
C/0在高数里是无穷。即一台普通电脑可以完成任何计算和服务。
所以第一个方案是 请求体的精简 尽可能协议化，
如最常用的登录数据格式，通常为了数据的易读性，我们会设计成
username=”username”,password=”12345678” 数据总长度为39 那么如果变成协议形式那
1=”username”,”2”=”12345678” 数据长度为25
数据量减少了 36%
而大多数的时候我们的数据格式会是这样的 如 sex=”man”,num=”12”,type=”1”这样“长key短value”的形式。这时候如果使用协议数据的压缩率应该会高于之前的36%,而趋向于50%
这样做还有一个好处，不需要数据加密。因为传输的数据相当于加盐的数据，不知道盐是什么就有会随着数据长度的增加而产生几何数量的变化。去掉了数据加密解密，对于前端来说，影响不大，但是对于高并发的后端来说，确实有意义的，因为对于长数据的转码，是需要时间的！我曾经也看过RSA加密的原码，这是经过大量运算产生的。如果将问题的解决时间限定在1秒以内，那么我想效率提高率应该在20%以上。
以上综合起来服务器的服务效率应该可以提升20%以上。
第二个就是我查阅了资料，和看了乐视商城10W人同时购买的解决方案。
那就是负载均衡，如果我有10个服务器，那么我最主要的工作就是如何让这10个服务器均匀的承受压力，换句话说，也就是如果我的请求少时，10台服务器可以在最快的时间为我解决问题，而在请求多时，应为负载均衡，不会因为一台服务器瞬间爆炸的惨剧。那么我们这端的操作，是否可以认为成，我如果的设计访问算法，去随机的访问一些功能一样的端口来为我服务。就好比前端是一批游客，服务器是一个游乐场，如果每个游客的入场券是同一个门，那么不由说，肯定是会崩的。但是如果我把游客均匀的分散在每个门时，虽然不一定会不崩溃，但是肯定能将崩溃的概率极大的降低。
第三个就是缓存机制，如和让游乐场不忙，那就是没有游客了。设定一个协议，如一些广告页，我们每天换一次，而前台可以设计成，在12：00到6：00 或者任意一个空闲时间片上，主动缓存这些数据，那么在打开的时候，就不会因为软件使用的热时间性（如游戏开服的时候大量的人注册、晚上玩游戏的人会多等等 就是大量用户会在某一个时间片集中访问应用）而造成后端因为这些而增加压力。
第四就是实现P2P技术。这是我感觉比较好的解决方案。因为软件具有区域性，如一个公司的很多人用同一款软件，在某一个季度，大家都喜欢看一个电视剧，或者电影，那么放到我们android上也是一样的。就那视频来说，如果某一个电视剧特别火，那么一定是有大量的用户在看，那么在这个时候，我们就把用户变成我们的服务器。我们在后台建立一张表，好比A视频现在被张三看，那么张三已经开始缓存视频数据了，这时候李四在张三的附近也想看这个A视频，那么我们就将张三视为一个视频转发点，即张三一边接收我们传给他的视频，一边在不卡顿的情况下给李四传送一些数据。可以想象，如果只有张三和李四的话，这个好像并没有特别大的提升。那么我们将用户变成100人，做一个小概率推算，有10个人是网速很快的，他们在缓存完成这个视频之后会继续观看。那么这10个人的带宽就可以看成我们服务器的带宽，向其他90人传送数据。随着科技的发展，网速越快，对于我们的服务器越有利，基本上10M带宽可以轻松的为我们服务两个用户了。按照这个比例我们的视频数据应该可以减少50%吧。当然这个实现起来是有一定难度的。对于一个人来实现也是不太现实的。因为需要的知识有很多。
第五就是常用的视频清晰度拆分，把视频尽量压缩，因为我们毕竟是在手机上看，尽量将数据变成在手机上看清晰度较好即可，当然我们也要准备在其他更高分辨率设备上的视频源。
但是其实1和2是属于简单的优化，在整个应用的生命周期里并不会对后台的压力其决定性的作用。但是四方法，设计得到可以很大程度上的缓解服务器压力。当然五是提前准备，将数据精确化， 给予用户合适的数据。
一、二、三 实现起来比较简单，因为核心没变只是将形式变了。
四、实现起来有难度，我其是也不会只是有了这个想法。
五、是主流的视频网站都在做的事情