來到公司接到項目，已有用戶在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是屬於簡單的優化，在整個應用的生命週期裏並不會對後臺的壓力其決定性的作用。但是四方法，設計得到可以很大程度上的緩解服務器壓力。當然五是提前準備，將數據精確化， 給予用戶合適的數據。
一、二、三 實現起來比較簡單，因爲核心沒變只是將形式變了。
四、實現起來有難度，我其是也不會只是有了這個想法。
五、是主流的視頻網站都在做的事情