目錄
[編程語言和編譯優(yōu)化]
[圖片壓縮算法]
[多進(jìn)程服務(wù)器]
[圖片壓縮算法]
[高效分布式文件存儲系統(tǒng)選型]
[用分布式文件做存儲]
[架構(gòu)]
[何時處理縮略圖]
[如何處理縮略圖]
[安全]
[存儲]
互聯(lián)網(wǎng)公司經(jīng)常會有大量原始圖片上傳,而且一個原圖會在頁面以不同尺寸縮略圖顯示阴幌，一般有兩種策略生成縮略圖，一種在上傳圖片時，生成需要的多張不同縮略圖待笑，另一種是請求指定尺寸的圖片時實(shí)時生存縮略圖片，第一種方式有一定限制啤呼，就是需要提前知道所有尺寸的圖片状植，做雍余存儲优炬，無形中增加大量文件數(shù)量，如果文件系統(tǒng)設(shè)計(jì)不好境蔼，還有可能形成大量文件碎片灶平，而且會消耗大量存儲空間，如果前端ui設(shè)計(jì)改變了圖片大小箍土，需要重新生成逢享。而第二種方式更加靈活，但是更消耗cpu資源吴藻，屬于cpu密集計(jì)算型
大吞吐量服務(wù)端架構(gòu)設(shè)計(jì)要考慮四個技術(shù)點(diǎn)
**1編程語言和編譯優(yōu)化
技術(shù)選型瞒爬，是單進(jìn)程多線程模型(reactor事件機(jī)制)，還是多進(jìn)程模型.
**2圖片壓縮算法
高效分布式文件存儲系統(tǒng)選型沟堡。
Linux系統(tǒng)中sysctl參數(shù)優(yōu)化(TCP高級選項(xiàng)設(shè)置)
編程語言和編譯優(yōu)化
互聯(lián)網(wǎng)行業(yè)用java開發(fā)語言比較多侧但，而且開發(fā)人員成熟，而且經(jīng)驗(yàn)豐富航罗。
高性能網(wǎng)絡(luò)框架:netty禀横，mina等等，而且資料比較粥血，社區(qū)比較活躍柏锄。而且有大量內(nèi)置的圖像處理API和算法直接使用.對于jdk自帶的一套圖片處理庫，他的特點(diǎn)是穩(wěn)定簡單复亏，但是對圖片處理來說趾娃，性能確實(shí)很差！離實(shí)際線上要求差距很大缔御。不過java方面也提供了類似jni方式支持GraphicsMagick+im4java處理圖像抬闷，但是要原生態(tài)支持openmpi,tbb，opencv等就比較繁瑣了刹淌，要用jni方式調(diào)用大量動態(tài)或靜態(tài)庫饶氏。一個性能問題，二是如果出現(xiàn)內(nèi)存問題也不好控制有勾。
C語言:
1.有成熟圖像處理庫GraphicsMagick和opencv疹启，
2.有可以很容易實(shí)現(xiàn)多進(jìn)程模式。
3.容易用其他編譯器做優(yōu)化蔼卡，比如用intelicc編譯喊崖，可以大幅度提高性能。
4.多進(jìn)程中每個進(jìn)程方面綁定到每個cpu核上雇逞，實(shí)現(xiàn)操作系統(tǒng)每個cpu核上隊(duì)列相同荤懂，均衡調(diào)度，更容易發(fā)揮目前多核cpu性能塘砸！
下面說一下單進(jìn)程多線程模型
主線程負(fù)責(zé)偵聽listen节仿，注冊accept和新進(jìn)來連接,然后把連接socket轉(zhuǎn)交給workthreadpool進(jìn)行讀寫事件注冊，計(jì)算邏輯處理
reactor事件機(jī)制:
Reactor釋義“反應(yīng)堆”掉蔬，是一種事件驅(qū)動機(jī)制廊宪。和普通函數(shù)調(diào)用的不同之處在于：應(yīng)用程序不是主動的調(diào)用某個API完成處理，而是恰恰相反女轿，Reactor逆置了事件處理流程箭启，應(yīng)用程序需要提供相應(yīng)的接口并注冊到Reactor上，如果相應(yīng)的時間發(fā)生蛉迹，Reactor將主動調(diào)用應(yīng)用程序注冊的接口傅寡，這些接口又稱為“回調(diào)函數(shù)”.
Reactor模式的優(yōu)點(diǎn)
Reactor模式是編寫高性能網(wǎng)絡(luò)服務(wù)器的必備技術(shù)之一，它具有如下的優(yōu)點(diǎn)：1）響應(yīng)快北救，不必為單個同步時間所阻塞荐操，雖然Reactor本身依然是同步的；2）編程相對簡單珍策，可以最大程度的避免復(fù)雜的多線程及同步問題淀零，并且避免了多線程/進(jìn)程的切換開銷；3）可擴(kuò)展性膛壹，可以方便的通過增加Reactor實(shí)例個數(shù)來充分利用CPU資源驾中；4）可復(fù)用性，reactor框架本身與具體事件處理邏輯無關(guān)模聋，具有很高的復(fù)用性肩民；
**3多進(jìn)程服務(wù)器
1每個進(jìn)程處理多個connection，使用epoll事件驅(qū)動來管理這些連接,多個worker進(jìn)程之間是對等的链方，他們同等競爭來自客戶端的請求持痰，各進(jìn)程互相之間是獨(dú)立的。
2master由信號驅(qū)動祟蚀，worker由epoll驅(qū)動（當(dāng)然信號會讓epoll_wait返回）工窍，有更好的容錯性割卖，如果其中一個進(jìn)程掛了或產(chǎn)生core,master收到相關(guān)信號后，會同時重啟一個進(jìn)程患雏，并同時發(fā)送出相關(guān)監(jiān)控信息鹏溯，也不會導(dǎo)致不能提供服務(wù),。
3多進(jìn)程用來利用多CPU硬件淹仑，所以按照業(yè)務(wù)邊界來劃分進(jìn)程丙挽，或者就按CPU個數(shù)配置。
4每個進(jìn)程是單線程的：所有IO相關(guān)操作都是全異步處理方式匀借，避免多線程切換和鎖機(jī)制開銷颜阐。
5進(jìn)程之間搶占epoll資源時，僅用一個輕量級的共享內(nèi)存鎖吓肋，循環(huán)依次把連接事件放入隊(duì)列凳怨，然后循環(huán)處理每個客戶端的連接請求和邏輯處理。
6高性能：服務(wù)器若支持多CPU或超線程是鬼，多線程無法完全利用機(jī)器性能猿棉，多進(jìn)程則可以讓服務(wù)器滿載.
**4圖片壓縮算法(jpeg,png,gif)
目前圖像壓縮算法已經(jīng)成型，而且基本上都是搞數(shù)學(xué)方面的大牛發(fā)明的屑咳，
關(guān)于圖像處理方面可以參考如下:
圖片壓縮或處理是一個非常消耗cpu的操作計(jì)算量非常大萨赁，因?yàn)橐M(jìn)行大量矩陣,傅立葉變換、沃爾什變換兆龙、離散余弦變換,圖像噪聲處理等變換或計(jì)算.目前高性能圖像處理開源軟件有2種GraphicsMagick和opecv杖爽。
GraphicsMagick:
GraphicsMagick號稱圖像處理領(lǐng)域的瑞士軍刀。短小精悍的代碼卻提供了一個魯棒紫皇、高效的工具和庫集合慰安，來處理圖像的讀取、寫入和操作聪铺，支持超過88種圖像格式化焕，包括重要的DPX、GIF铃剔、JPEG撒桨、JPEG-2000、PNG键兜、PDF凤类、PNM和TIFF等等。
通過使用OpenMP可是利用多線程進(jìn)行圖片處理普气，增強(qiáng)了通過擴(kuò)展CPU提高處理能力谜疤。
注意：但是GraphicsMagick啟動多線程時，處理速度雖然加快了，但是cpu確大幅飆升夷磕。
Opencv:
OpenCV于1999年由Intel建立履肃，如今由WillowGarage提供支持。OpenCV是一個基于[1]（開源）發(fā)行的跨平臺計(jì)算機(jī)視覺庫坐桩，可以運(yùn)行在Linux尺棋、Windows和MacOS操作系統(tǒng)上。它輕量級而且高效——由一系列C函數(shù)和少量C++類構(gòu)成撕攒，同時提供了Python陡鹃、Ruby烘浦、MATLAB等語言的接口抖坪，實(shí)現(xiàn)了圖像處理和計(jì)算機(jī)視覺方面的很多通用算法。[2]最新版本是2.4.5闷叉。
OpenCV擁有包括300多個C函數(shù)的跨平臺的中擦俐、高層API。它不依賴于其它的外部庫——盡管也可以使用某些外部庫握侧。
注意：opencv目前支持jpeg,tiff,png,但是由于版權(quán)和法律方面原因不支持gif圖像處理蚯瞧，png只是有限支持，圖像壓縮時會變形或變模糊品擎。
GraphicsMagick與Opencv比較優(yōu)缺點(diǎn):
GraphicsMagick支持圖像多埋合，覆蓋面全，幾乎所有常見圖像格式.壓縮質(zhì)量高
Opencv支持有限的圖像處理萄传，覆蓋面不全甚颂，經(jīng)過大量壓力測試綜合比較，但是壓縮性能確比GraphicsMagick快一倍多秀菱。
綜合兩者的優(yōu)點(diǎn)：需要把兩者結(jié)合起來混合處理不同圖像振诬，以達(dá)到圖像處理最佳性能。
**5高效分布式文件存儲系統(tǒng)選型
互聯(lián)網(wǎng)圖片文件存儲衍菱，一般考慮帶寬赶么，存儲空間方面壓力，經(jīng)過壓縮大小不會2MB脊串。因此存儲方案就有多種選擇辫呻，既可以選擇傳統(tǒng)mysql數(shù)據(jù)庫，也可以用成熟的分布式文件系統(tǒng).下面就來說說他們的不同和優(yōu)缺點(diǎn)琼锋。
用mysql做存儲：
1.互聯(lián)網(wǎng)公司都用mysql的豐富經(jīng)驗(yàn)印屁，技術(shù)成熟，眾多人都會用mysql斩例，而且還有專業(yè)的DBA團(tuán)隊(duì)來維護(hù)雄人。
2.Mysq性能穩(wěn)定，單臺機(jī)器加上內(nèi)存，基本能滿足QPS性能要求础钠。
3.存儲圖片的表結(jié)構(gòu)屬性少恰力，結(jié)構(gòu)簡單，一般訪問時只需要查詢主鍵就可以了旗吁，不需求簡歷額外的索引踩萎。
4.去中心化設(shè)計(jì)，兩臺服務(wù)器為一組很钓，雙寫隨機(jī)讀(任意一臺服務(wù)器),服務(wù)器為raid5模式香府。
5.系統(tǒng)擴(kuò)容，每當(dāng)當(dāng)前服務(wù)器存儲空間不足码倦，需要增加服務(wù)器擴(kuò)容時企孩，都需要成倍增加服務(wù)器數(shù)量.
**6用分布式文件做存儲
1.一般是直接使用成熟開源產(chǎn)品或自主研發(fā)，使用開源產(chǎn)品袁稽，開發(fā)成本低勿璃，學(xué)習(xí)成本高，需要專門花費(fèi)一些進(jìn)行研究或?qū)W習(xí)推汽。還要自己來維護(hù)补疑。自主研發(fā)，時間周期長歹撒，投入成本更高莲组，但可控性更強(qiáng)。能進(jìn)行大量性能優(yōu)化和調(diào)整暖夭，或許能節(jié)省一些服務(wù)器資源锹杈。
2.同等條件下分布式文件系統(tǒng)性能一般會比mysql等關(guān)系型數(shù)據(jù)庫高3-5倍，因?yàn)樗恍枨筮M(jìn)行B+Tree（時間復(fù)雜度）分頁查找鳞尔，文件在上傳時嬉橙，其生成的文件名就包含了大量文件具體位置信息，一般o(1)時間就能準(zhǔn)備定位寥假。而且是順序一次性讀取市框。不想B+Tree按頁式存儲，可能要多次讀取多頁數(shù)據(jù)糕韧，而且每條記錄需求存儲額外信息枫振，進(jìn)行事物回滾處理，比較浪費(fèi)存儲空間萤彩。
3.中心化設(shè)計(jì)(一般為metaserver和dataserver兩類服務(wù)器組集群)粪滤，兩或三臺服務(wù)器為一組，雙寫隨機(jī)讀(任意一臺服務(wù)器),可以不用raid5模式雀扶。
4.系統(tǒng)擴(kuò)容杖小，每當(dāng)當(dāng)前服務(wù)器存儲空間不足肆汹，可以輕易做到線性擴(kuò)展，只需要增加一組服務(wù)器就可以了予权。明顯在成本上具有優(yōu)勢昂勉。
Linux系統(tǒng)中sysctl參數(shù)優(yōu)化(TCP高級選項(xiàng)設(shè)置)
服務(wù)器在高并發(fā)時，會創(chuàng)建大量連接扫腺，這就需要設(shè)置TCP相關(guān)參數(shù)來提供服務(wù)器性能岗照。
1.文件描述符最大數(shù)調(diào)整。
修改vi/etc/security/limits.conf值
在里面添加一行
*-nofile65535
保存重啟笆环，再用命令ulimit-n可發(fā)現(xiàn)文件描述符由默認(rèn)變成65535了
2.高負(fù)載linux服務(wù)器的內(nèi)核調(diào)優(yōu)
vi/etc/sysctl.conf,修改內(nèi)核參數(shù)：
kernel.shmall=268435456
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_keepalive_time=1200
net.ipv4.ip_local_port_range=102465000
net.ipv4.tcp_max_tw_buckets=5000
net.ipv4.tcp_max_tw_buckets=5000
net.ipv4.tcp_fin_timeout=30
net.ipv4.tcp_keepalive_time=300
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.ip_local_port_range=500065000
net.ipv4.tcp_mem=78643210485761572864
net.core.wmem_max=873200
net.core.rmem_max=873200
net.ipv4.tcp_wmem=8192436600873200
net.ipv4.tcp_rmem=32768436600873200
net.core.somaxconn=256
net.core.netdev_max_backlog=1000
net.ipv4.tcp_max_syn_backlog=2048
net.ipv4.tcp_retries2=5
net.ipv4.tcp_keepalive_time=500
net.ipv4.tcp_keepalive_intvl=30
net.ipv4.tcp_keepalive_probes=3
net.ipv4.conf.lo.arp_ignore=0
net.ipv4.conf.lo.arp_announce=0
net.ipv4.conf.all.arp_ignore=0
net.ipv4.conf.all.arp_announce=0
3.參數(shù)說明：net.ipv4.tcp_syncookies=1
表示開啟SYNCookies攒至。當(dāng)出現(xiàn)SYN等待隊(duì)列溢出時，啟用cookies來處理躁劣，可防范少量SYN攻擊迫吐，默認(rèn)為0，表示關(guān)閉习绢；
net.ipv4.tcp_tw_reuse=1
表示開啟重用渠抹。允許將TIME-WAITsockets重新用于新的TCP連接蝙昙，默認(rèn)為0闪萄，表示關(guān)閉；
net.ipv4.tcp_tw_recycle=1
表示開啟TCP連接中TIME-WAITsockets的快速回收奇颠，默認(rèn)為0败去，表示關(guān)閉。
net.ipv4.tcp_fin_timeout=30
表示如果套接字由本端要求關(guān)閉烈拒，這個參數(shù)決定了它保持在FIN-WAIT-2狀態(tài)的時間圆裕。
net.ipv4.tcp_keepalive_time=1200
表示當(dāng)keepalive起用的時候，TCP發(fā)送keepalive消息的頻度荆几。缺省是2小時吓妆，改為20分鐘。
net.ipv4.ip_local_port_range=102465000
表示用于向外連接的端口范圍吨铸。缺省情況下很行新！：32768到61000，改為1024到65000诞吱。
net.ipv4.tcp_max_tw_buckets=5000
表示系統(tǒng)同時保持TIME_WAIT套接字的最大數(shù)量舟奠，如果超過這個數(shù)字，
TIME_WAIT套接字將立刻被清除并打印警告信息房维。默認(rèn)為180000沼瘫，改為5000。
**7架構(gòu)
整體架構(gòu)如下：
可以看到咙俩，筆者采用了通用的分層架構(gòu)設(shè)計(jì)模式耿戚。
file storage存放著原始的圖片數(shù)據(jù)。
image server用于圖片的處理，同時進(jìn)行圖片的cache膜蛔。
nginx作為統(tǒng)一的入口晓锻，同時也作為cache。
當(dāng)用戶請求一張圖片的縮略圖的時候飞几，如果該圖片不存在于nginx的緩存中砚哆，則nginx根據(jù)圖片的fileid 通過consistent hash路由到對應(yīng)的image server上面去處理，如果image server仍然沒有該圖片屑墨，則會從file storage下載躁锁。
分層架構(gòu)有一個很好的地方在于系統(tǒng)的可擴(kuò)展性，同時我們也可以在加入一些中間層卵史，提高cache的命中率战转，譬如我們就可以在image server與nginx之間引入一個cache層。不過鑒于我們的系統(tǒng)主要用于企業(yè)內(nèi)部以躯，不會出現(xiàn)圖片數(shù)據(jù)量過大的情況槐秧，所以上面這套分層設(shè)計(jì)已經(jīng)足夠了。
nginx try_files
如果本地cache不存在忧设，則去后臺服務(wù)器取數(shù)據(jù)刁标。對于這套邏輯，nginx可以通過try_files很好的處理址晕，譬如:
location /abc.png { root /data/image/; try_files $uri @fetch;}location @fetch { proxy_pass http://up_imageserver$request_uri;}
首先try_files會嘗試在本地獲取對應(yīng)的文件膀懈，如果沒有找到，則會內(nèi)部跳轉(zhuǎn)到fetch這個location去遠(yuǎn)程獲取數(shù)據(jù)谨垃。
**8何時處理縮略圖
既然是縮略圖启搂，那么何時生成縮略圖就是需要考慮的問題了。通常來說刘陶，縮略圖的生成會有兩種方式：
上傳生成
當(dāng)用戶上傳一張圖片之后胳赌，系統(tǒng)自動為該圖片生成對應(yīng)的固定格式縮略圖，然后將原圖與縮略圖一起存放到file storage里面去匙隔。這方面主要有facebook的Haystack系統(tǒng)疑苫。
實(shí)時生成
當(dāng)用戶上傳一張圖片之后，只保留該圖片的原始數(shù)據(jù)牡直，當(dāng)請求該圖的縮略圖時缀匕，如果cache中不存在，由image server動態(tài)生成碰逸。這方面可以參考淘寶的圖片存儲介紹乡小。
對于筆者來說，實(shí)際使用的是第二種方法饵史，主要有以下幾個原因的考量：
對于實(shí)時生成的縮略圖我們可以靈活的指定其大小满钟，而不像上傳生成那樣只有預(yù)先定義的width和height胜榔。
存儲成本，額外存儲縮略圖會占用很大的存儲空間湃番，而且存放到file storage里面還會有冗余備份的問題夭织，更加浪費(fèi)。
協(xié)同圖片的冷熱性問題吠撮，最近最熱的圖片鐵定是最頻繁訪問的尊惰，尤其是在多人協(xié)同情況下面，而這些圖片縮略圖是有緩存的泥兰，不需要每次都通過原圖生成弄屡，性能有保證。
**9如何處理縮略圖
既然選擇實(shí)時生成縮略圖鞋诗，那么如何快速生成縮略圖就是筆者需要考慮的問題了膀捷。這里筆者使用graphicsmagick來生成縮略圖，網(wǎng)上有太多介紹削彬，這里不再累述全庸。
**10安全
生成縮略圖之后，如何保證該圖片的安全訪問也是一個需要關(guān)注的問題融痛。筆者考慮了如下解決方案：
簽名壶笼，任何縮略圖的url都是經(jīng)過簽名，因?yàn)楹灻峭ㄟ^登陸用戶自身的access id和security key進(jìn)行的酌心，并且有時效性拌消，所以外界很難偽造挑豌“踩或者，可以使用簡單的HttpAccessKeyModule來進(jìn)行訪問控制氓英。
nginx HttpRefererModule侯勉，只允許特定domain的請求訪問。
**11存儲
對于如何存儲大量的圖片小文件铝阐，筆者覺得可以如下考慮：
對于文件最終存放的file storage址貌，業(yè)界有很多好的分布式解決方案，譬如TFS徘键，mogilefs等练对，如果想自己造一個輪子，也很不錯吹害。
對于圖片的cache螟凭，因?yàn)閏ache的存儲文件量級我們是可以控制的，所以這里可以考慮直接使用通常的文件系統(tǒng)存儲它呀。
但需要注意的是螺男，單個目錄下面文件數(shù)量不能過多棒厘，目錄的層次也不能過深，不然會導(dǎo)致很嚴(yán)重的性能瓶頸下隧。為了解決上述問題奢人，筆者建立了三層目錄結(jié)構(gòu)，首層100個文件夾淆院，以1 - 100命名何乎，每個文件夾下面1000個文件夾，以1 - 1000命名土辩，對于任意的圖片文件宪赶，根據(jù)其實(shí)際的文件名通過兩次hash到特定的目錄下。
