1).網路特性及解決方案
a.弱網路性
弱網路性指手機不斷移動(例如地鐵、汽車)的特性,處於快速移動中，出現訊號不穩、響應時間過長、出現丟包等情況。
因此針對弱網路環境,開發者設計協議的時候必須考慮儘量減少資料往返次數，降低耗時。
tcp half-open的危害:
伺服器記錄每個連線收到心跳包的最後時間，每隔一段時間檢查所有連線，若某個連線最後收到心跳包時間減去當前時間大於超時時間，斷開連線。這種方式主要缺點是需要同時檢查所有連線，如果連線數量過大，檢查連線是對系統的效能影響大。
伺服器為每乙個連線建立乙個定時器，到了規定的超時時間沒有收到心跳包定時器就觸發，把當前連線斷開，如果收到心跳包，就重置定時器，不斷重複過程。這種方法主要缺點，為每乙個連線設定獨立定時器，如果連線數量過大，會建立大量定時器，耗費系統資源。
b.對流量敏感性
非wi-fi環境下使用者使用手機流量上網，對流量敏感。
2).協議
a.協議要求
b.常用協議
query>
iq>
c.常用開源伺服器
d.tcp協議粘包問題及解決方案
問題案例：假設使用者快取區大小為15位元組，當第乙個資料報(10位元組)和第二個資料報(10個位元組)到達接收端，根據緩衝區大小取資料15位元組，這時候取出資料報含第乙個資料報和第二個資料報，產生粘包問題。(例如第乙個資料報為"1234567890"，第二個資料報為"0123456789"),取出資料為"123456789001234"
解決方案：制定合理的協議格式，在每個資料報中標明包的長度。
one. mysql協議格式
mysql協議中乙個資料報的前3個位元組是資料報長度，第4個位元組是資料報的序列號，剩下位元組是資料。
two. redis 協議格式(redis協議是以cr lf結尾的)
redis協議格式如下:
*引數個數 cr lf
$第乙個引數的字串占用位元組數 cr lf
引數資料 cr lf
......
$第n個引數的字串占用位元組數 cr lf
引數資料 cr lf
*3\r\n$3\r\n\set\r\n\$4\r\n\name\$4\r\n\jeff\r\n1.問題的由來：由於移動物聯網的弱網路性，經常出現丟包的情況。 需要處理的問題：
2.解決方案：
傳統的im協議是基於佇列的訊息傳送和反饋機制。
伺服器按照順序把佇列中的訊息依次發給客戶端,當客戶端收到訊息後給服務端傳送"確認收到"的應答,如果過了一段時間還沒有收到客戶端的應答,就重發該訊息。
這樣就存在兩個問題：
one.如果客戶端已收到訊息且傳送了"確認收到"的應答，網路中斷，造成伺服器收不到應答，伺服器重發，導致客戶端收到重複的訊息。
two.每條訊息都需要應答極其費時間，伺服器要維護每個訊息的狀態也容易出錯。
f.非文字檔案傳送
3).後台整體架構設計
a.連線層
b.業務層
c.持久層
該層提供資料訪問服務，資料報含使用者的身份資訊、訊息、統計資訊等。
根據不同資料對訪問速度的不同要求，可使用不同的軟體儲存不同的業務資料。例如使用者身份資訊這種高頻讀寫的資料，可儲存在redis、memcached等記憶體資料庫中。
d.工作流程(以老公向老婆傳送"我愛你"為例)
1).基本表結構
2).推拉模式
a.推模式
b.拉模式
c.推拉模式總結
d.微博中的應用
3).資料庫架構
a.自增id
b.分表分庫策略
4).快取架構
a.分布式快取
b.主從快取
c.防止快取失效措施
1).地理座標處理及座標系認識
2).查詢附件的人功能
a.mysql空間資料庫
b.geohash編碼
c.mongodb地理位置查詢功能
3).基於mongodb的lbs後台架構
a.副本集架構
b.分片架構
4.推送伺服器後台架構
1). android推送 (類似gopush-cluster架構)
2).ios推送(基於apns)
a.apns原理
b.apns推送協議分析
c.ios推送伺服器架構引用自：
推送平台架構
由於cc部門沒有乙個公共的推送平台，各個業務之間推送手機訊息會非常費勁，而且沿用了pc架構的侷限性，只有使用者建立連線到伺服器才會收到各種訊息，在當今移動為王的環境，如果使用者的手機進入了休眠或者退出應用之後就不能接收訊息的話，是非常被動非常滯後的。因此，乙個公共的推送平台就出現了。簡單解釋一下各個...
10040 微信與朋友圈後台架構
原文 視屏講解 伺服器的配置基本都是普通的伺服器，最好的伺服器也就是64g記憶體，這部分佔比不多，大部分是32g記憶體，也有很少一部分8g記憶體的。硬碟是ssd和sata都有。cpu以16核居多，有一部分新機器是32核。至於頻寬則是比較多的，對外頻寬很大。涉及朋友圈資料的有四個核心的表 在發布的表寫...
SOA平台架構解析
大家看到圖可能有點暈了，不怕現在我們一起梳理一下 從上面的圖，我們可以看出阿里巴巴將我們的應用進行了拆分 分成了服務提供者 provider 和服務消費者 consumer 註冊中心專心做自己的註冊工作並暴露服務位址 監控中心進行對服務呼叫的情況進行統計，分別用圖形的形式展現出來。具體乙個服務的呼叫...