1托呕、系統(tǒng)架構(gòu)圖如下：
2含蓉、系統(tǒng)各層介紹
以上采用五層的邏輯架構(gòu)，第一層客戶層项郊，第二層前端優(yōu)化層馅扣，第三層應(yīng)用層，第四層服務(wù)層着降，第五層數(shù)據(jù)存儲(chǔ)層差油，每層的介紹如下：
1、客戶層：支持PC瀏覽器和手機(jī)APP任洞，可以直接通過IP訪問蓄喇，反向代理服務(wù)器。
2交掏、前端層：使用DNS負(fù)載均衡妆偏，CDN本地加速及反向代理服務(wù)。
3盅弛、應(yīng)用層：網(wǎng)站應(yīng)用集群楼眷；按照業(yè)務(wù)進(jìn)行垂直拆分，比如應(yīng)用商城熊尉，產(chǎn)品服務(wù)等。
4掌腰、服務(wù)層：提供公共服務(wù)狰住，比如產(chǎn)品升級服務(wù)，搜索服務(wù)齿梁，賬號管理服務(wù)等催植。
5、數(shù)據(jù)層：支持關(guān)系型數(shù)據(jù)庫集群（支持讀寫分離）勺择，NOSQL集群创南，分布式文件系統(tǒng)集群，及分布式Cache
3省核、各部分技術(shù)介紹
3.1 基礎(chǔ)設(shè)施技術(shù)介紹：
分布式緩存
? ? ? ? 在高并發(fā)環(huán)境下稿辙，大量的讀、寫請求涌向數(shù)據(jù)庫气忠，磁盤的處理速度和內(nèi)存處理顯然不在一個(gè)數(shù)量級邻储，從減輕數(shù)據(jù)庫壓力和提高系統(tǒng)響應(yīng)速度兩個(gè)角度來考慮赋咽，一般都會(huì)在數(shù)據(jù)庫之前加一層緩存。由于單臺(tái)機(jī)器的內(nèi)存資源和承載能力有限吨娜，并且如果大量使用本地緩存脓匿，也會(huì)使相同的數(shù)據(jù)被不同的節(jié)點(diǎn)存儲(chǔ)多份，對內(nèi)存資源造成較大的浪費(fèi)宦赠，因此才催生出分布式緩存陪毡。
持久化存儲(chǔ)
? ? ? ? 隨著科技的不斷發(fā)展，越來越多的人參與到互聯(lián)網(wǎng)中勾扭，人們在網(wǎng)絡(luò)上的活動(dòng)毡琉，如發(fā)表心情動(dòng)態(tài)、微博尺借、購物绊起、評論等，這些信息最終被轉(zhuǎn)換為二進(jìn)制字節(jié)的數(shù)據(jù)存儲(chǔ)下來燎斩。面對并發(fā)訪問量的激增和數(shù)據(jù)幾何級的增長虱歪，如何存儲(chǔ)正在迅速膨脹并且不斷積累的數(shù)據(jù)，以及應(yīng)對日益增長的用戶訪問頻次栅表，成為亟待解決的問題笋鄙。
消息系統(tǒng)
? ? ? ? 在分布式系統(tǒng)中，消息系統(tǒng)應(yīng)用十分廣泛怪瓶，消息可以作為應(yīng)用間通信的一種方式萧落，消息被保存在隊(duì)列中，知道被接收者取出洗贰，由于消息發(fā)送者不需要同步等待消息接收者的響應(yīng)找岖，消息的異步接收降低了系統(tǒng)集成的耦合度，提升了分布式系統(tǒng)協(xié)作的效率敛滋，使得系統(tǒng)能夠更快地響應(yīng)用戶许布，提供更高的吞吐。當(dāng)系統(tǒng)處理峰值壓力時(shí)绎晃，分布式消息隊(duì)列還能夠作為緩沖蜜唾，削峰填谷，緩解集群的壓力庶艾，避免整個(gè)系統(tǒng)被壓垮袁余。
? ? ? ? 開源的消息系統(tǒng)有很多，包括Apache的ActiveMQ咱揍，Apache的Kafka颖榜、RabbitMQ、memcacheQ等。
搜索引擎
? ? ? ? ?這里說的垂直化搜索引擎朱转，與大家所熟知的Google和Baidu等互聯(lián)網(wǎng)搜索引擎存在著一些差別蟹地，垂直搜索引擎主要針對企業(yè)內(nèi)部的自由數(shù)據(jù)的檢索，而不像Google和Baidu等搜索平臺(tái)藤为，采用網(wǎng)絡(luò)爬蟲對全網(wǎng)數(shù)據(jù)進(jìn)行爬取怪与，從而建立索引并提供給用戶進(jìn)行檢索、模糊匹配的需求缅疟，解決數(shù)據(jù)庫like查詢效率低下的問題分别，又能夠解決分布式環(huán)境下，由于采用分庫分表或者使用NoSQL數(shù)據(jù)庫存淫，導(dǎo)致無法進(jìn)行多表聯(lián)合查詢或者進(jìn)行復(fù)雜查詢的問題耘斩。
其它
? ? ? ? 除了前面所提到的分布式緩存、持久化存儲(chǔ)桅咆、分布式消息系統(tǒng)括授、搜索引擎，大型的分布式系統(tǒng)的背后岩饼，還依賴于其他支撐系統(tǒng)荚虚，還包含實(shí)時(shí)計(jì)算、離線計(jì)算籍茧、分布式文件系統(tǒng)版述、日志收集系統(tǒng)、監(jiān)控系統(tǒng)寞冯、數(shù)據(jù)倉庫等渴析，還有CDN系統(tǒng)、負(fù)載均衡系統(tǒng)吮龄、消息推送系統(tǒng)俭茧、自動(dòng)化運(yùn)維系統(tǒng)等。
3.2 基礎(chǔ)設(shè)施技術(shù)技術(shù)特點(diǎn)
4漓帚、開發(fā)中的故障案例分析
（1）寫日志引發(fā)的故障：
故障分析：由于日志等級為info或debug母债，導(dǎo)致產(chǎn)生的日志異常多，磁盤被撐爆胰默。
實(shí)例： 在圖片服務(wù)器的Nginx服務(wù)器上，由于日志打印的過多漓踢，導(dǎo)致磁盤爆滿牵署，最終導(dǎo)致不能寫入數(shù)據(jù)信息。
解決方案： 需要將Nginx的配置信息修改為Error喧半，定時(shí)檢測磁盤空間是否滿奴迅，及時(shí)增加硬盤空間。
（2） 高并發(fā)訪問數(shù)據(jù)庫引發(fā)的故障：
故障分析：當(dāng)SQL的執(zhí)行頻率非常高時(shí)，會(huì)使得數(shù)據(jù)庫的Load持續(xù)升高取具，影響數(shù)據(jù)庫的性能脖隶。
解決方案：盡量增加表的索引，減少全表掃描暇检，嘗試使用分布式緩存和緩存設(shè)備产阱。
（3）高并發(fā)情況下，鎖引發(fā)的故障：
故障分析：由于鎖的使用块仆，某個(gè)操作构蹬，執(zhí)行時(shí)間較長（如遠(yuǎn)程過程調(diào)用），長期占有鎖悔据，導(dǎo)致程序阻塞庄敛，當(dāng)這個(gè)鎖被釋放時(shí)，其它? ? ? ? ? ? 線程得以執(zhí)行科汗。
解決方案：使用鎖操作時(shí)要謹(jǐn)慎藻烤，慎之又慎。
（4）緩存應(yīng)發(fā)的故障
故障分析：由于緩存服務(wù)器集群的關(guān)閉头滔，導(dǎo)致數(shù)據(jù)查詢的壓力全部都到數(shù)據(jù)庫層面怖亭，導(dǎo)致數(shù)據(jù)庫的壓力較大。
解決方案：緩存服務(wù)器是當(dāng)今網(wǎng)站中不可或缺的一部分拙毫，我們要像管理其他服務(wù)器一樣依许，認(rèn)真管理緩存服務(wù)器。
（5）應(yīng)用啟動(dòng)不同步引發(fā)的故障
故障分析：由于啟動(dòng)應(yīng)用服務(wù)器的不同步缀蹄，如 Apahce + Tomcat 應(yīng)用峭跳，服務(wù) Apache先啟動(dòng)，會(huì)導(dǎo)致過多的請求到Apache上缺前，導(dǎo)致Tomcat已啟動(dòng)后蛀醉，過多的請求壓力到Tomcat上，嚴(yán)重情況下導(dǎo)致Tomcat的崩潰衅码。
解決方案：要嚴(yán)格按照指定的順序進(jìn)行啟動(dòng)應(yīng)用拯刁，避免“姑娘還沒有穿好衣服，老鴇就把客人給領(lǐng)進(jìn)來了”逝段，所以老鴇領(lǐng)客人進(jìn)來時(shí)垛玻，要先確認(rèn)姑娘有沒有準(zhǔn)備好。
（6）大文件讀寫?yīng)氄即疟P引起的故障
故障分析：文件服務(wù)器中保存的有大文件和小文件奶躯，小文件有幾十K? 到上百K帚桩，大文件有幾十M到上百M(fèi)，會(huì)導(dǎo)致用戶下載大文件時(shí)嘹黔，獨(dú)占磁盤操作账嚎，影響小文件的讀寫操作。
解決方案：將圖片服務(wù)器小的文件，使用專用的存儲(chǔ)服務(wù)器如阿里的分布式文件服務(wù)器郭蕉，大的文件使用分布式文件服務(wù)器如HDFS服務(wù)器
（7）濫用生產(chǎn)環(huán)境引起的故障
故障分析：開發(fā)人員盡量不要對運(yùn)行環(huán)境進(jìn)行處理
解決方案：將正式庫的權(quán)限交給運(yùn)維人員疼邀，嚴(yán)禁開發(fā)人員對正式數(shù)據(jù)進(jìn)行處理。
（8）不規(guī)范流程引起的故障
故障分析：應(yīng)用發(fā)布后召锈，引起數(shù)據(jù)庫LOAD迅速飆升旁振，檢查用戶代碼是否有變化，是否緩存給注釋掉烟勋。如注釋掉緩存代碼规求。
解決方案：代碼提交前一定要對代碼進(jìn)行DIFF比較，確認(rèn)沒有提交不該提交的代碼（如測試注釋的代碼卵惦，正式部署需要使用的）
（9）不好的編程習(xí)慣引起的故障
故障分析：程序在處理一個(gè)輸入的對象時(shí)阻肿，不明確輸入的對象是否為空。
解決方案：要養(yǎng)成好的編碼習(xí)慣沮尿，輸入的對象盡量保證不為空丛塌，必要時(shí)構(gòu)造空對象。
5畜疾、開發(fā)過程中的心得體會(huì)
