1.設(shè)計app架構(gòu)：

1.梳理app業(yè)務(wù)流程
2.整理業(yè)務(wù)流程可能遇到的問題
3.根據(jù)問題听系，探討可執(zhí)行的解決方案
4.把3中所有技術(shù)進行有機融合作谭，就是app后臺的初步架構(gòu)

api編寫：
1.api的作用（功能）
2.api需要輸入的參數(shù)
3.api返回的數(shù)據(jù)

2.服務(wù)器選擇

1.傳統(tǒng)的IDC
在傳統(tǒng)的IDC，要加cpu或內(nèi)存照捡，流程如下:
　　1.和客戶經(jīng)理商商談所需硬件的價格
　　2.匯款過去，等IDC的財務(wù)確認
　　3.確認后，等待IDC安排工作人員升級硬件
　　這個流程走一次灸芳，最少也要1至2天涝桅。延遲了1至2天升級硬件拜姿，怎么保證可以快速應(yīng)付爆發(fā)的業(yè)務(wù)

2.云服務(wù)器
升級硬件:
1.在用戶后臺選擇需要的硬件配置
　　2.通過網(wǎng)絡(luò)支付
　　3.重啟服務(wù)器，升級就完成了冯遂。如果只是升級帶寬蕊肥，甚至不用重啟。
　　整個過程合起來不用5分鐘，簡單壁却，快捷批狱，方便。
　　而且展东，現(xiàn)在的云服務(wù)器提供商赔硫，出了服務(wù)器外，還提供下面的服務(wù)：
　　負載均衡
　　云數(shù)據(jù)庫
　　云內(nèi)存存儲
　　這些服務(wù)在app上線初期盐肃，在一臺服務(wù)器上自己搭建就行了爪膊，但隨著app的發(fā)展，這些服務(wù)都需要部署在不同的服務(wù)器砸王。
　　規(guī)模的增大推盛，也要面對高可用，高并發(fā)谦铃，監(jiān)控報警等問題耘成。這些問題如果都要后端人員處理，那要瘋了驹闰，后端就那么一兩個人瘪菌，既要保證平時的開發(fā)任務(wù)，又要做復雜的運維管理疮方。后端人員也不是全能控嗜，一般后端人員是專注于開發(fā)，運維稍遜一籌骡显。
　　這時疆栏，就能體會到云服務(wù)的優(yōu)點，由云服務(wù)器的提供商來負責運維惫谤。高可用壁顶，高并發(fā)，監(jiān)控報警這些都靠云服務(wù)器的提供商來保障溜歪，就能大大減輕運維方面的壓力和人員的開支若专。

3.選擇
在網(wǎng)絡(luò)上經(jīng)常被問到，需要選擇什么樣的服務(wù)器配置蝴猪，這個問題调衰，沒法回答。這需要在綜合考慮用戶量自阱，業(yè)務(wù)邏輯綜合考慮的嚎莉。
給個建議，最初硬件配置可以差點沛豌，隨時監(jiān)控主機趋箩，發(fā)現(xiàn)負載高了，才升級硬件配置也不遲

3.app后臺

1.app后臺要慎重考慮網(wǎng)絡(luò)傳輸流量，主要做api設(shè)計叫确，圖片處理上
2.移動手機弱網(wǎng)絡(luò)環(huán)境
3.手機電量有限

4.app流程

1.項目業(yè)務(wù)邏輯
2.產(chǎn)品原型
3.UI效果圖
4.研發(fā)階段

* api設(shè)計
* api提供測試數(shù)據(jù)供前端開發(fā)
* 開發(fā)頁面及初級架構(gòu)設(shè)計
* 后端實現(xiàn)api接口功能

5.測試反饋

* bug修改人員
* bug描述說明與重現(xiàn)步驟
* bug提交版本與bug提交人

6.市場推廣與市場運營

* 潛在用戶如何發(fā)現(xiàn)應(yīng)用市場中的app跳芳？
* 怎么讓用戶了解app?
* 怎么讓用戶下載app?
* 怎么讓用戶使用app?怎樣增加用戶粘性?

5.項目開發(fā)管理

1.日常開發(fā)

* 開發(fā)計劃
* 開發(fā)規(guī)范
* 保證開發(fā)的進度和效率

2.每日例會

* 昨天做了哪些事情，還有哪些沒做竹勉，需要多長時間去完成
* 今天要做什么
* 有什么工作需要哪些人配合

3.測試和修復bug

* 可以交叉測試
* 問題描述和重現(xiàn)步驟
* 解決問題人員和提出問題人員

4.評審
使用評審整個app的功能及體驗

6.app后臺

1.api接口
從業(yè)務(wù)邏輯中提煉api接口

* 業(yè)務(wù)邏輯思維導圖
* 功能-業(yè)務(wù)邏輯思維導圖
* 基本功能模塊關(guān)系

* 功能模塊接口UML(設(shè)計出api)
* 在設(shè)計稿標記api
* 編寫api文檔

2.業(yè)務(wù)邏輯思維導圖

* 用思維導圖把結(jié)構(gòu)關(guān)系列出來飞盆，包含里面的功能
* 把相同的元素整理出來，如相同的推送次乓、評論桨啃、圖片上傳，然后用相同的顏色標起來

業(yè)務(wù)思維導圖.png

功能-業(yè)務(wù)邏輯導圖.png

功能模塊關(guān)系圖.png

功能模塊UML.png

3.api設(shè)計要點

* 根據(jù)對象設(shè)計api檬输，而不是根據(jù)頁面設(shè)計api（頁面修改會影響到api更改照瘾，維護較難）
* api命名(望名而知api)
* api安全
* api返回數(shù)據(jù)(注意空值的處理，不然易造成app閃退)

app后臺角度丧慈，api返回的數(shù)據(jù)中正確值和空值的類型必須一樣析命，禁止返回null值;
app客戶端，當api返回數(shù)據(jù)缺少某個數(shù)據(jù)時逃默，app客戶端自動補上這個數(shù)據(jù)并賦值鹃愤；
數(shù)據(jù)庫設(shè)計，所有字段都有默認值完域，不允許Null值软吐；
產(chǎn)品中常用的null值需求是用Null表示數(shù)據(jù)未填寫，如用“1”表示男性吟税，“0”表示女性凹耙，Null表示用戶未填寫性別；

4.圖片處理

* app客戶端緩存圖片肠仪，圖片不存在肖抱，才通過api獲取圖片;
* 當app客戶端需要某種尺寸的圖片，由app客戶端通知服務(wù)器所需要的尺寸，由服務(wù)器動態(tài)生成并緩存；

app后臺數(shù)據(jù)庫只保存原圖击困，需要什么尺寸，動態(tài)生成荤崇；

5.返回提示信息

* 提示用戶信息
* 提示程序員信息，參數(shù)問題潮针，格式問題

7.數(shù)據(jù)庫選擇

1.MySQL术荤、Redis、MongoDB讀寫數(shù)據(jù)區(qū)別
Redis是存放在服務(wù)器端內(nèi)存中然低，內(nèi)存用滿之后需要擴容喜每，就只能使用Redis的分布式方案，為防止丟失雳攘，可調(diào)整Redis配置文件带兜，按一定策略把數(shù)據(jù)持久化傳到硬盤中。

MongoDB同時使用了硬盤和內(nèi)存吨灭，其使用了操作系統(tǒng)提供的MMAP（內(nèi)存文件映射）機制進行數(shù)據(jù)文件的讀寫刚照，MMAP可以把文件直接映射到進程的內(nèi)存空間中，這樣文件就會在內(nèi)存中有對應(yīng)的地址喧兄，這時對文件的讀寫是可以操作內(nèi)存進行的无畔，而不需要傳統(tǒng)的如fread、fwrite文件操作方式吠冤。

MySQL的數(shù)據(jù)放在硬盤中浑彰，MySQL的緩存是查詢的結(jié)果，而不是緩存數(shù)據(jù)拯辙。

2.MySQL郭变、Redis、MongoDB查找數(shù)據(jù)的區(qū)別
Redis的數(shù)據(jù)基于“鍵值對”存儲涯保，查找數(shù)據(jù)诉濒，直奔主題，讀寫速度快夕春。

MongoDB和MySQL未荒，每組數(shù)據(jù)都有一個id（或者可以為每組數(shù)據(jù)建立索引），查找數(shù)據(jù)分兩種及志，知道id或索引片排，不知道id或索引，前者效率高速侈，后者效率低划纽。

3.MySQL、Redis锌畸、MongoDB查找數(shù)據(jù)的區(qū)別
Redis數(shù)據(jù)只存放在服務(wù)器端內(nèi)存中勇劣，由于內(nèi)存價格高，所以內(nèi)存存儲數(shù)據(jù)成本高潭枣，app后臺開發(fā)中比默，讀寫頻率高的數(shù)據(jù)一般放在Redis中（當然這部分數(shù)據(jù)也可放在MySQL或MongoDSB中，Redis中國的數(shù)據(jù)是以緩存的形式存在的盆犁，數(shù)據(jù)更新時命咐，兩部分數(shù)據(jù)都要更新以保持數(shù)據(jù)統(tǒng)一性）。

MongoDB使用場景：
網(wǎng)站數(shù)據(jù)：MongoDB非常適合實時的插入谐岁、更新與查詢醋奠，并具備網(wǎng)站實時數(shù)據(jù)存儲所需要的復制及高度伸縮性榛臼；
大尺寸、低價值的數(shù)據(jù)窜司；
高伸縮性的場景沛善；
存儲地理坐標的數(shù)據(jù)；

MongoDB不適用場景：
高度事物性的系統(tǒng)：如銀行或會計系統(tǒng)塞祈，涉及金錢的操作不支持金刁；
傳統(tǒng)的商業(yè)智能應(yīng)用；
需要SQL的問題：雖然MongoDB支持類似于SQL的查詢议薪，但它的查詢比起MySQL來有一定的差距尤蛮；

MySQL適用場景：
事物性的系統(tǒng)：如轉(zhuǎn)賬；
需要復雜的SQL問題斯议；

8.消息隊列

消息隊列把大量的并發(fā)請求變成串行的請求产捞，來減輕服務(wù)器的壓力。
app后臺中哼御，發(fā)送郵件轧葛、發(fā)送短信、推送消息等任務(wù)都適合在消息隊列中完成艇搀；

1.消息隊列的流程

* 隊列服務(wù)器
* 隊列生產(chǎn)者
* 隊列消費者

9.使用分布式服務(wù)實現(xiàn)業(yè)務(wù)復用

遠層服務(wù)：
把重復實現(xiàn)的模塊獨立部署為遠程服務(wù)尿扯，新增的業(yè)務(wù)調(diào)用遠程服務(wù)所提供的功能實現(xiàn)相關(guān)的業(yè)務(wù)，不依賴于里面的具體實現(xiàn)代碼焰雕。當遠程業(yè)務(wù)發(fā)生變化時衷笋，只要接口傳人的參數(shù)和返回值不變，就不會影響到調(diào)用遠程服務(wù)的業(yè)務(wù)矩屁。

1.遠層服務(wù)的實現(xiàn)

* REST
* RPC
* 開源的RPC庫

2.常見的搜索軟件

* Lucene
* Sold
* ElasticSearch
* Sphinx
* CoreSeek

3.定時任務(wù)

10.后臺核心技術(shù)

1.用戶驗證方案

* api請求必須使用HTTPS協(xié)議

傳統(tǒng)Web網(wǎng)站使用Cookie+Session保持用戶登錄狀態(tài)辟宗；

2.app通信安全

* URL簽名（改進：在傳遞參數(shù)中增加時間戳）
* AES對稱加密

AES加密（data，secretKey）

app后臺
* app后臺用時間戳生成HTTP請求頭Token-Param
* 取請求頭Token-Param的22位長度作為secretKey
* 用AES算法把個人信息用密鑰secretKey加密吝秕，在進行base64編碼泊脐，用HTTPS返回給app

客戶端
* 取HTTPS協(xié)議中HTTP請求頭Token-Param的值的22位作為secretKey
* 把HTTPbody的數(shù)據(jù)先進行base64算法解碼，用AES算法把解碼后的數(shù)據(jù)用密鑰secretKey解密烁峭，獲取個人用戶信息

3.更進一步的通信安全

* 使用自定義的通信協(xié)議傳輸敏感數(shù)據(jù)
* 使用RSA加強通信的安全性
* 涉及敏感信息（如支付密碼）容客，每次都需用戶輸入支付密碼確認，支付密碼永遠不在app端保存
* 使用自主開發(fā)的輸入控件輸入敏感信息

4.短信服務(wù)

* 發(fā)送短信只能依靠第三方短信平臺
* 短信的到達率和延時app后臺無法控制

短信平臺選擇（價格约郁，短信的到達率和延時）缩挑，先試用，在選用鬓梅！
為建立可靠的短信服務(wù)供置，app后臺必須要接入最少兩個短信平臺，當前短信平臺不可靠時绽快，切換到另一個平臺芥丧；

5.表情
Openfire中發(fā)送表情引起連接斷開的問題
xmpp斷開連接紧阔，是由Openfire中代碼引起的，app后臺加個codePoint判斷即可续担；

6.高效更新數(shù)據(jù)
推拉結(jié)合和數(shù)據(jù)增量更新是實現(xiàn)高效獲取數(shù)據(jù)的關(guān)鍵擅耽；

輪詢：
典型的拉模式，每隔一段時間赤拒，app向app后臺發(fā)送請求數(shù)據(jù)，耗網(wǎng)絡(luò)流量诱鞠，服務(wù)器壓力大挎挖；

推模式：
當app后臺有數(shù)據(jù)更新，通過推送系統(tǒng)通知app航夺，當app收到這個數(shù)據(jù)更新的通知后在調(diào)用api獲取相應(yīng)的數(shù)據(jù)蕉朵。

推模式.png

7.數(shù)據(jù)增量更新策略
使用app本地存儲，需考慮數(shù)據(jù)增量大更新方案阳掐；
當app從服務(wù)器獲取一次數(shù)據(jù)時始衅，記錄獲取最新數(shù)據(jù)的update_time，當再次獲取數(shù)據(jù)就只需要獲取update_time到訪問服務(wù)器這刻為止所更新的數(shù)據(jù)缭保。

8.獲取APK和IPA文件中的資源

11.文件系統(tǒng)

盡量使用成熟可靠的云服務(wù)和開源軟件汛闸，自身只專注于業(yè)務(wù)邏輯；

架設(shè)文件系統(tǒng)涉及文件的分布式存儲艺骂、圖片水印诸老、圖片縮放、及CDN等方面钳恕，小團隊可用第三方云存儲平臺别伏；

1.分布式文件存儲系統(tǒng)

* 擴容的時候，只需添加機器就能達到擴容效果忧额，不需重啟整個文件系統(tǒng)厘肮，甚至遷移文件
* 保證文件系統(tǒng)高可用、文件冗余備份睦番，避免以某臺機器宕機而造成文件服務(wù)停止

2.推薦使用FastDFS（開源的輕量級的分布式文件系統(tǒng)）
FastDFS對文件管理功能包過：文件存儲类茂、文件同步、文件訪問等托嚣，解決了大容量存儲和負載均衡的問題大咱。
FastDFS的基本原理可類比生活中的倉庫，有兩大角色注益，跟蹤器和存儲節(jié)點碴巾，跟蹤器就是倉庫管理員，負責調(diào)度工作丑搔，在訪問上起負載均衡的作用厦瓢，存儲節(jié)點就是貨柜提揍，工人就是向FastDFS存儲文件的客戶端；

3.圖片水印煮仇、縮減和裁剪
推薦使用GraphicsMagick作為圖片處理軟件劳跃；支持多語言、多平臺浙垫；

4.CDN
解決網(wǎng)絡(luò)擁擠情況刨仑；
傳統(tǒng)CDN服務(wù)商、阿里云夹姥、UCloud等提供CDN服務(wù)杉武；
另外很多CDN服務(wù)商提供了圖片水印、縮減辙售、裁剪的功能轻抱，開發(fā)者可以直接使用；

5.ELK日志分析平臺（分布式的日志收集和分析系統(tǒng)）

6.Docker構(gòu)建一致的開發(fā)環(huán)境
Docker是一個用于統(tǒng)一開發(fā)和部署的輕量級容器旦部，讓開發(fā)者打包其應(yīng)用及依賴包到另一個可移植的容器祈搜，發(fā)布該容器到其它機器，就能很容易的實現(xiàn)應(yīng)用的部署士八。

12.app后臺應(yīng)用最廣泛的系統(tǒng)

1.基本系統(tǒng)優(yōu)化
app后臺的Linux系統(tǒng)如果是采用默認安裝或機房工作人員幫忙安裝容燕，運維人員需要對其進行優(yōu)化，以獲得更高的性能和安全性婚度。

開啟自動服務(wù)優(yōu)化缰趋；

Linux的交換區(qū)：交換區(qū)是硬盤上的一塊空間，在內(nèi)存不足的情況下陕见，操作系統(tǒng)先把內(nèi)存中暫時不用的數(shù)據(jù)存儲到硬盤的交換區(qū)秘血，騰出內(nèi)存來讓別的程序運行。

阿里云服務(wù)器上的Linux系統(tǒng)是默認沒有設(shè)置交換區(qū)（Swap）评甜，由于開啟Swap分區(qū)會導致硬盤IO性能下降灰粮，因此阿里云服務(wù)器初始沒有設(shè)置Swap，如需要開啟Swap忍坷，可使用相應(yīng)的命令開啟粘舟。

2.故障案例分析

* 進程管理軟件引起的最大連接數(shù)設(shè)置（修改限制）
* 占滿磁盤空間引起網(wǎng)絡(luò)無法登陸問題（可能是由bug日志過多占空間，修復bug后要注意清楚）

13.Nginx-app后臺HTTP服務(wù)的利器

Nginx與Apache類似佩研，其是一個高性能的HTTP和反向代理服務(wù)器柑肴，也是一個imop／pop3/smtp代理服務(wù)器。

Nginx高性能主要是使用了epoll和kqueue網(wǎng)絡(luò)I／O模型旬薯，而Apache使用的是傳統(tǒng)的select模型晰骑。

處理大量請求時，epoll模型遠遠大于select模型绊序；
理解：select 模型處理（如客人進店點菜硕舆，服務(wù)員全程跟著）
epoll模型處理（如客人進店點菜秽荞，在需要的時候服務(wù)員才跟著）

http配置；

https配置：

生成證書：
* 繳費抚官，到證書服務(wù)商申請
* 用戶自己給自己頒發(fā)證書扬跋，即手動生成

location配置:主要針對靜態(tài)網(wǎng)頁；

sever虛擬機配置凌节；

負載均衡配置：保證服務(wù)的高可用钦听；

負載均衡.png

下載app配置：在瀏覽器下載；

性能統(tǒng)計：可開啟Nginx的統(tǒng)計模塊倍奢；

14.MySQL-app后臺最常用的數(shù)據(jù)庫

1.MySQL基本架構(gòu)

• 服務(wù)層：大多數(shù)基于網(wǎng)絡(luò)的客戶端／服務(wù)端工具都有這一層朴上，這一層主要處理連接和安全驗證；
• 核心層：這層處理MySQL的核心業(yè)務(wù)娱挨；
  查詢余指、分析捕犬、緩存和內(nèi)置的函數(shù)
  內(nèi)建的視圖跷坝，存儲過程，觸發(fā)器
• 存儲引擎層：存儲引擎負責數(shù)據(jù)的存儲和提取碉碉。

核心層通過存儲引擎的API與存儲引擎通信柴钻，這樣就遮蔽了不同存儲引擎的差異，使得這些差異對上層查詢是透明的垢粮。
存儲引擎之間不會相互通信贴届，只是簡單的響應(yīng)上層查詢。

建議選擇MySQL社區(qū)版蜡吧，足夠業(yè)務(wù)需求毫蚓；

2.軟件優(yōu)化

1.正確使用MyISAM和InnoDB存儲引擎
MyISAM和InnoDB存儲引擎是MySQL最常用的存儲引擎；

• MyISAM基于ISAM（索引順序訪問方法）昔善，支持全文索引元潘，但并非是事物安全，不支持外建君仆，使用表級鎖翩概。每個MyISAM存3個文件：FRM文件存放表結(jié)構(gòu)，MYD文件存放數(shù)據(jù)返咱，MYI存放索引钥庇。

• InnoDB是事務(wù)型存儲引擎，其支持行鎖咖摹，InnoDB的行鎖也不是絕對的评姨，如果他在執(zhí)行一個更新的語句是沒法確定更新的范圍，也會鎖表萤晴。InnoDB支持回滾参咙、崩潰恢復龄广、ACID事物控制，InnoDB存儲他的表和索引在一張表空間蕴侧，表空間可包含多個文件择同。
  支持外建，是事務(wù)安全型的净宵；

2.正確使用索引

* 給合適的列建索引
* 索引列的值盡不相同
* 使用短索引
* 利用最左前綴
* 使用like查詢時索引會失效敲才，盡量少使用like查詢
* 不能濫用索引

3.避免使用select*

• “select*”從數(shù)據(jù)庫中返回的數(shù)據(jù)更多，降低了查詢速度择葡；
• 過多的返回結(jié)果會增大服務(wù)器反給app端的數(shù)據(jù)的傳輸紧武，網(wǎng)絡(luò)不好的情況下，過大的傳輸會造成請求失斆舸ⅰ阻星；

4.建議數(shù)據(jù)庫上所有字段都設(shè)置為NOTNULL，必須有默認值已添；

3.硬件優(yōu)化

1.增加物理內(nèi)存
2.增加應(yīng)用緩存
3.用固態(tài)硬盤代替機械硬盤
4.SSD硬盤+SATA硬盤混合存儲方案

4.架構(gòu)優(yōu)化

1.分表
項目用戶增長妥箕，數(shù)據(jù)龐大，就要分表：將大表拆分為多個子表更舞，在更新或查詢數(shù)據(jù)的時候畦幢，壓力會分散到不同的表上。由于分表之后缆蝉，每張表的數(shù)據(jù)變小宇葱，查詢或更新會有很好的提升；

• 水平拆分：把一張表的數(shù)據(jù)分別保存在不同的表中刊头；
• 垂直拆分：把一張表的字段保存在不同的表中黍瞧；

2.數(shù)據(jù)庫優(yōu)化
使用數(shù)據(jù)庫讀寫分離策略；
讀寫分離是把對數(shù)據(jù)庫的讀和寫操作分開對應(yīng)于主／從數(shù)據(jù)庫服務(wù)器原杂；

讀寫分離架構(gòu).png

3.分庫
數(shù)據(jù)規(guī)模變大印颤，當讀寫分離也不能滿足系統(tǒng)性能要求的時候要考慮分庫，分庫即把不同的數(shù)據(jù)表部署在數(shù)據(jù)庫集群上污尉；

MyCat部署.png

4.SQL慢查詢分析
SQL慢查詢是指超過一定時間的SQL查詢語句膀哲，把這些語句記錄到查詢?nèi)罩荆员惴治銎湓虮煌耄赃M行優(yōu)化某宪。

5.云數(shù)據(jù)庫

* 配置高性能的SSD硬盤
* 備份機制
* 完善的監(jiān)控體系
* 彈性擴展

15.Redis-app后臺高性能的緩存系統(tǒng)

1.Redis

業(yè)務(wù)場景需求：

* 少量數(shù)據(jù)被經(jīng)常讀寫，同時對讀寫速度要求非常高锐朴；
* 能提供豐富的數(shù)據(jù)結(jié)構(gòu)
* 提供數(shù)據(jù)落地的功能

Redis就是滿足上面需求的開源Key-Value內(nèi)存存儲系統(tǒng)兴喂；
特點：

* 全部的數(shù)據(jù)操作在內(nèi)存，保證了高速的讀寫速度
* 提供豐富的數(shù)據(jù)類型，string衣迷、hash畏鼓、list、set壶谒、sorted set云矫、bitmap、hyperloglog
* 提供了AOF和RDB兩種數(shù)據(jù)的持久化方式汗菜，保證了Redis重啟后數(shù)據(jù)不丟失
* Redis所有操作都是原子性让禀，同時Redis還支持對幾個操作合并后的原子性操作，也即支持事務(wù)

2.Redis常用數(shù)據(jù)結(jié)構(gòu)及應(yīng)用場景

2.1string-存儲簡單的數(shù)據(jù)

特點：
* 可接受任何格式的二進制數(shù)據(jù)
* 是基本的Key-Value結(jié)構(gòu)

場景：
* 可存儲大量數(shù)據(jù)陨界，app后臺該類型經(jīng)常被用來緩存數(shù)據(jù)
* 頁面：訪問頻率高巡揍，數(shù)據(jù)不經(jīng)常變動（可能幾天）

緩存不常變數(shù)據(jù).png

2.2hash-存儲對象的數(shù)據(jù)

特點：
* hash的key是唯一值，value部分是個hashmap結(jié)構(gòu)

場景：
* 根據(jù)用戶id獲取用戶信息

2.3list-模擬隊列操作

特點：
* list是按照插入順序排序的字符串鏈表菌瘪，可在頭部和尾部插入新元素
* 鏈表中間插入效率低腮敌，首位插入效率高

場景：
* Redis被用來作為消息隊列

如短信發(fā)送：

短信發(fā)送.png

2.4set-無序且不重復的元素集合

特點：
* set類型可以看作是沒有排序、不重復的元素集合俏扩，可以在類型上添加糜工、刪除或判斷某一元素存在等操作

場景：
* 如社交中的共同好友

2.5sorted set - 有序且不重復的元素集合

特點：
* 和set 類似，不容許成員重復

場景：
* 各種類型的排行榜（如人氣排行）

3.內(nèi)存優(yōu)化

3.1監(jiān)控內(nèi)存使用情況（命令redis-cli info）

3.2優(yōu)化存儲結(jié)構(gòu)

* hash存儲动猬，當hashmap成員達到不同數(shù)時啤斗，采用不同的形式存儲數(shù)據(jù)（<512用ziplist存儲表箭，>512用hashmap存儲;）,hashmap成員長度（<64用ziplist存儲赁咙，>64用hashmap存儲）
* set使用了intest的結(jié)構(gòu)來節(jié)省內(nèi)存

3.3限制使用的最大內(nèi)存

• 設(shè)置maxmemory的參數(shù)來限制Redis使用的物理內(nèi)存
• 當Redis使用的內(nèi)存達到了限制值，任何write操作會觸發(fā)“數(shù)據(jù)清除策略”免钻，配置文件“maxmemory-policy”來采用特定的“數(shù)據(jù)清除策略”

3.4設(shè)置過期時間
可設(shè)置Key超時時間（命令EXPIRE key seconds）
超過超時時間后彼水，刪除不用的Key及數(shù)據(jù)，達到內(nèi)存優(yōu)化极舔；

刪除：
* 惰性刪除(發(fā)現(xiàn)key過期就刪除)
* 定期刪除（定期檢查凤覆，有過期的刪除）

4.集群

4.1客戶端分片
4.2Twemproxy

Twemproxy.png

優(yōu)劣.png

4.3Codis

Codis.png

4.4Redios3.0集群采用了p2p模式，完全去中心化

4.5云服務(wù)器上的集群服務(wù)

* 動態(tài)擴容
* 數(shù)據(jù)多備（數(shù)據(jù)保存在一主一備兩臺機器中）
* 自動容災(zāi)

4.6持久化
Redis是一個支持持久化操作的內(nèi)存數(shù)據(jù)庫拆魏，通過持久化機制把內(nèi)存中的數(shù)據(jù)保存在硬盤文件盯桦。當Redis重啟后通過把硬盤文件重新加載到內(nèi)存，就能達到恢復數(shù)據(jù)目的渤刃。

* RDB(按照一定的時間周期策略把內(nèi)存的數(shù)據(jù)以快照的形式寫入到硬盤的二進制文件)
* AOF（通過write函數(shù)追加到持久文件中）

4.7故障排除
查看Redis錯誤日志拥峦；

16.MongoDB-app后臺新興的數(shù)據(jù)庫

1.MongoDB

* 一種非關(guān)系型數(shù)據(jù)庫
* 支持的數(shù)據(jù)結(jié)構(gòu)非常松散，數(shù)據(jù)采用bson格式卖子，可存儲比較復雜的數(shù)據(jù)類型
* 讀寫性能高
* 水平擴展機制

高性能（MMAP和Journal日志）
* MMAP（內(nèi)存文件映射）
* Journal日志（所有數(shù)據(jù)更新操作都會記錄并保存在該日志中）

* MongoDB把關(guān)系模型轉(zhuǎn)變?yōu)槲臋n模型
* 可進行數(shù)組操作略号、文檔操作

2.高可集用群

2.1主從
MongoDB采用雙機主從備份，主節(jié)點的數(shù)據(jù)會自動同步到從節(jié)點，當主節(jié)點宕機后玄柠，切換到從節(jié)點繼續(xù)提供服務(wù)突梦。

主從.png

2.2副本集
副本集使用多臺機器做同一份數(shù)據(jù)的同步和異步，從而使多臺服務(wù)器擁有同一份數(shù)據(jù)的多個副本羽利。一臺服務(wù)器作為主節(jié)點提供寫入服務(wù)宫患，多臺服務(wù)器作為副本節(jié)點提供讀取服務(wù)，實現(xiàn)讀寫分離和負載均衡这弧。當主節(jié)點宕機后撮奏，可把副本節(jié)點提為主節(jié)點或?qū)⑵渌?jié)點改為主節(jié)點，繼續(xù)服務(wù)当宴。

副本集.png

2.3分片
集群中大量的數(shù)據(jù)讀寫請求分散到多個集群處理畜吊，在MySQL中稱為數(shù)據(jù)庫分片；

2.4.LBS- 地理位置查詢

2.5MongoDB3.0

* 靈活的存儲架構(gòu)（引入插件式存儲引擎api）
* 性能提升7-10倍
* 存儲空間最多減少80%（新增WiredTiger存儲引擎户矢，支持集合數(shù)據(jù)壓縮）
* 運維成本降低95%

17.app后臺架構(gòu)剖析

1.聊天app后臺架構(gòu)

1.1移動互聯(lián)網(wǎng)的網(wǎng)絡(luò)特性

* 弱網(wǎng)絡(luò)性
心跳機制防止TCP half-open（客戶端斷開連接玲献，服務(wù)器以為仍和app保持連接）
* 對流量敏感

1.2協(xié)議

* XMPP
* MQTT
* ActivitySync

基于隊列的消息協(xié)議

* 傳統(tǒng)的IM協(xié)議一般是基于隊列的消息發(fā)送和反饋機制

基于隊列消息協(xié)議.png

基于版本號的消息協(xié)議

基于版本號的協(xié)議.png

1.3文件發(fā)送

文件發(fā)送.png

1.4聊天架構(gòu)

聊天架構(gòu).png

連接層:
* 與app保持連接
* 把消息通過隊列轉(zhuǎn)發(fā)到邏輯層處理

業(yè)務(wù)層(處理業(yè)務(wù)邏輯):
* 驗證模塊（驗證用戶身份信息）
* 路由模塊（路由獲取用戶所在服務(wù)器，如實現(xiàn)群聊功能） 
* 統(tǒng)計模塊（統(tǒng)計各種信息梯浪，如連接數(shù)捌年、每秒發(fā)送消息數(shù)、每個端端連接數(shù)）
* 數(shù)據(jù)存儲模塊（存儲消息挂洛、統(tǒng)計信息礼预、用戶身份信息等）

持久層：
* 提供數(shù)據(jù)存儲服務(wù)

流程：

聊天后臺流程.png

2.社交app后臺架構(gòu)

社交的核心功能是Feed；

2.1基本表結(jié)構(gòu)
常見的Feed架構(gòu)就是把數(shù)據(jù)存儲在MySQL中虏劲，熱點數(shù)據(jù)（一般說最近3天數(shù)據(jù)）存儲在緩存（常見的緩存有Redis和Memcached托酸，微博用的Memcached），務(wù)必讓絕大數(shù)請求通過緩存直接返回柒巫，只有少量的請求穿透緩存落到數(shù)據(jù)庫励堡。

2.2推拉模式

推模式：
* 推送給粉絲（同時推送很多人，延遲嚴重堡掏，浪費存儲空間）
* 一個SQL可完成（顯示Feed）
* 變更成本高 （如刪除某一條內(nèi)容）

拉模式：
* 采用了時間換空間的策略
* 不推送
* 需要大量的聚合運算（顯示Feed）
* 沒有變更成本

微博中公開的微博采用了拉模式应结，私密性微博采用了推模式；

2.3數(shù)據(jù)庫的架構(gòu)演進
單機部署 ——> 讀寫分離泉唁，從一主一從到一主多從——>分表分庫

2.4社交app后臺數(shù)據(jù)庫在業(yè)務(wù)層實現(xiàn)分表分庫的方案

數(shù)據(jù)庫自增id
* 生成id算法

分表分庫策略
* 按hash拆分（適用于數(shù)據(jù)分表分庫前中期）
* 按時間拆分
* 綜合使用拆分

hash拆分.png

時間拆分.png

2.5緩存架構(gòu)的演進
分布式緩存

分布式緩存.png

主從緩存結(jié)構(gòu)

主從緩存.png

2.6防止緩存實效的措施

* 定期把主緩存的數(shù)據(jù)同步到從緩存
* 應(yīng)用層控制請求有一定的概率落在從緩存鹅龄，讓從緩存承擔部分請求，使從緩存的數(shù)據(jù)不過冷

3.LBS-app后臺架構(gòu)

3.1地理坐標
獲取

* GPS：精度高亭畜，初始化搜索衛(wèi)星的速度慢扮休，耗電
* 基站：速度快、精度低贱案，不同運營商的基站定位差別大
* AGPS：GPS+基站的結(jié)合
* WiFi定位：通過服務(wù)商收集的Wi-Fi數(shù)據(jù)定位肛炮，但WiFi的地理信息更新慢

app端建議使用地圖SDK止吐，后臺注意坐標偏移問題；

處理

* MySQL的空間數(shù)據(jù)庫(把地理坐標的數(shù)據(jù)當成一種獨立的數(shù)據(jù)類型)
* geohash（geohash編碼就是把地理坐標變換成一個值（字符串））
* MongoDB封裝了大量地理位置操作 

3.2基于MongoDB的LBS后臺架構(gòu)演進
副本集架構(gòu)——>分片架構(gòu)

副本集架構(gòu)

* 保證高可用

MongoDB副本集架構(gòu).png

分片架構(gòu)

* 每個分片都是副本集架構(gòu)

4.推送服務(wù)器的后臺架構(gòu)

4.1Android推送
由于android系統(tǒng)沒有限制侨糟，當app進入后臺也能運行服務(wù)碍扔，所以android可以基于長連接作推送；

app連接推送服務(wù)器流程：

后臺推送消息到app流程：

后臺推送消息到app.png

app獲取離線消息流程：

app獲取離線消息.png

4.2iOS推送
APNS原理：

APNS原理.png

18.app后臺架構(gòu)的演進

app后臺架構(gòu)核心：

* 高可用
* 高性能
* 安全性
* 可擴展
* 可伸縮

app發(fā)送請求后臺運行：

app請求后臺運行.png

1.高性能

app層：

app層.png

網(wǎng)絡(luò)傳輸層：

網(wǎng)絡(luò)傳輸層.png

應(yīng)用服務(wù)層：

文件服務(wù)層.png

文件服務(wù)層：

應(yīng)用服務(wù)層.png

緩存層：

緩存層.png

數(shù)據(jù)庫層：

數(shù)據(jù)庫層.png

2.高可用

應(yīng)用服務(wù)器高可用原理.png

宕機后的負載均衡：

宕機.png

高可用備份：

備份.png

數(shù)據(jù)服務(wù)器宕機：

數(shù)據(jù)服務(wù)器宕機.png

3.開發(fā)服務(wù)器秕重、工具

開發(fā).png

開發(fā)2.png

4.架構(gòu)演進

4.1單機部署
app后臺極簡化架構(gòu)：

app后臺極簡化架構(gòu).png

* 加入ULB(UCloud的負載均衡ULB是免費的)
* 一開始使用Redis（既能當緩存岭辣，又能當隊列服務(wù)丘喻，并發(fā)性能高，適用于初期項目）
* 架構(gòu)中不包含文件服務(wù)（運維成本高）

4.2分布式部署

分布式部署.png

4.3架構(gòu)拆分

架構(gòu)拆分.png

業(yè)務(wù)平穩(wěn)期：

業(yè)務(wù)平穩(wěn)期.png