互聯(lián)網(wǎng)電商網(wǎng)站平臺(tái)框架設(shè)計(jì)

1、 互聯(lián)網(wǎng)電商網(wǎng)站平臺(tái)框架設(shè)計(jì)高可用高伸縮高性能架構(gòu)架構(gòu)師小秘圈 微信號(hào) seexmq功能介紹 架構(gòu)師小秘圈，聚集10萬(wàn)架構(gòu)師的小圈子！不定期分享技術(shù)干貨，行業(yè)秘聞，匯集各類(lèi)奇妙好玩的話(huà)題和流行動(dòng)向！禁止截圖，閱后即焚!一，應(yīng)用無(wú)狀態(tài)（淘寶session框架）俗話(huà)說(shuō)，一個(gè)系 統(tǒng)的伸縮性的好壞取決于應(yīng)用的狀態(tài)如何管理。為什么這么說(shuō)呢？咱們?cè)囅胍幌?，假如我們?cè)趕ession中保存了大量與客戶(hù)端的狀態(tài)信 息的話(huà)，那么當(dāng)保存狀態(tài)信息的server宕機(jī)的時(shí)候，我們?cè)趺崔k？通常來(lái)說(shuō)，我們都是通過(guò)集群來(lái)解決這個(gè)問(wèn)題，而通常 所說(shuō)的集群，不僅有負(fù)載均衡，更重要的是要有失效恢復(fù)failover,比如tomcat采

2、 用的集群節(jié)點(diǎn)廣播復(fù)制，jboss采 用的配對(duì)復(fù)制等session狀 態(tài)復(fù)制策略，但是集群中的狀態(tài)恢復(fù)也有其缺點(diǎn)，那就是嚴(yán)重影響了系統(tǒng)的伸縮性，系統(tǒng)不能通過(guò)增加更多的機(jī)器來(lái)達(dá)到良好的水平伸縮！因?yàn)榧汗?jié)點(diǎn)間session的 通信會(huì)隨著節(jié)點(diǎn)的增多而開(kāi)銷(xiāo)增大，因此要想做到應(yīng)用本身的伸縮性，我們需要保證應(yīng)用的無(wú)狀態(tài)性，這樣集群中的各個(gè)節(jié)點(diǎn)來(lái)說(shuō)都是相同的，從而是的系統(tǒng)更好的水平伸縮。OK， 上面說(shuō)了無(wú)狀態(tài)的重要性，那么具體如何實(shí)現(xiàn)無(wú)狀態(tài)呢？此時(shí)一個(gè)session框架就會(huì)發(fā)揮作用了。幸運(yùn)的是淘 寶已經(jīng)具有了此類(lèi)框架。淘寶的session框架采用的是client cookie實(shí)現(xiàn)，主要將狀態(tài) 保存到了co

3、okie里 面，這樣就使得應(yīng)用節(jié)點(diǎn)本身不需要保存任何狀態(tài)信息，這樣在系統(tǒng)用戶(hù)變多的時(shí)候，就可以通過(guò)增加更多的應(yīng)用節(jié)點(diǎn)來(lái)達(dá)到水平擴(kuò)展的目的.但 是采用客戶(hù)端cookie的 方式來(lái)保存狀態(tài)也會(huì)遇到限制，比如每個(gè)cookie一般不能超過(guò)4K的大小，同時(shí)很多瀏覽器都限制一個(gè)站點(diǎn)最 多保存20個(gè)cookie.淘 寶cookie框 架采用的是“多值cookie”， 就是一個(gè)組合鍵對(duì)應(yīng)多個(gè)cookie的 值，這樣不僅可以防止cookie數(shù) 量超過(guò)20， 同時(shí)還節(jié)省了cookie存 儲(chǔ)有效信息的空間，因?yàn)槟J(rèn)每個(gè)cookie都會(huì)有大約50個(gè)字節(jié)的元信息來(lái)描述cookie。除了淘寶目前的session框 架的實(shí)

4、現(xiàn)方式以外，其實(shí)集中式session管理來(lái)完成，說(shuō)具體點(diǎn)就是多個(gè)無(wú)狀態(tài)的應(yīng)用節(jié)點(diǎn)連接一個(gè)session 服 務(wù)器，session服 務(wù)器將session保 存到緩存中，session服 務(wù)器后端再配有底層持久性數(shù)據(jù)源，比如數(shù)據(jù)庫(kù)，文件系統(tǒng)等等。二 有效使用緩存（Tair）做互聯(lián)網(wǎng)應(yīng)用的兄弟應(yīng)該都清楚，緩存對(duì)于一個(gè)互聯(lián)網(wǎng)應(yīng)用是多么的重要，從瀏覽器緩存，反向代理緩存，頁(yè)面緩存，局部頁(yè)面緩存，對(duì)象緩存等等都是緩存應(yīng)用的場(chǎng) 景。一般來(lái)說(shuō)緩存根據(jù)與應(yīng)用程序的遠(yuǎn)近程度不同可以分為：local cache 和 remote cache。 一般系統(tǒng)中要么采用local cache，要么采用remote cac

5、he,兩者混合使用的話(huà)對(duì) 于local cache和remote cache的數(shù)據(jù)一致性處理會(huì)變 大比較麻煩.在大部分情況下,我 們所說(shuō)到的緩存都是讀緩存,緩存還有另外一個(gè)類(lèi)型:寫(xiě)緩存. 對(duì) 于一些讀寫(xiě)比不高，同時(shí)對(duì)數(shù)據(jù)安全性需求不高的數(shù)據(jù)，我們可以將其緩存起來(lái)從而減少對(duì)底層數(shù)據(jù)庫(kù)的訪(fǎng)問(wèn),比如 統(tǒng)計(jì)商品的訪(fǎng)問(wèn)次數(shù),統(tǒng) 計(jì)API的 調(diào)用量等等,可 以采用先寫(xiě)內(nèi)存緩存然后延遲持久化到數(shù)據(jù)庫(kù)，這樣可以大大減少對(duì)數(shù)據(jù)庫(kù)的寫(xiě)壓力。OK， 我以店鋪線(xiàn)的系統(tǒng)為例，在用戶(hù)瀏覽店鋪的時(shí)候，比如店鋪介紹，店鋪交流區(qū)頁(yè)面，店鋪服務(wù)條款頁(yè)面，店鋪試衣間頁(yè)面，以及店鋪內(nèi)搜索界面這些界面更新不是非 常頻繁，因此適合放到緩

6、存中，這樣可以大大減低DB的負(fù)載。另外寶貝詳情頁(yè)面相對(duì)也更新比較 少，因此也適合放到緩存中來(lái)減低DB負(fù)載。三 應(yīng)用拆分（HSF）首先，在說(shuō)明應(yīng)用拆分之前，我們先來(lái)回顧一下一個(gè)系統(tǒng)從小變大的過(guò)程中遇到的一些問(wèn)題，通過(guò)這些問(wèn)題我們會(huì)發(fā)現(xiàn)拆分對(duì)于構(gòu)建一個(gè)大型系統(tǒng)是如何的重要。系統(tǒng)剛上線(xiàn)初期，用戶(hù)數(shù)并不多，所有的邏輯也許都是放在一個(gè)系統(tǒng)中的，所有邏輯跑到一個(gè)進(jìn)程或者一個(gè)應(yīng)用當(dāng)中，這個(gè)時(shí)候因?yàn)楸容^用戶(hù)少，系統(tǒng)訪(fǎng)問(wèn)量低，因此 將全部的邏輯都放在一個(gè)應(yīng)用未嘗不可。但是，兄弟們都清楚，好景不長(zhǎng)，隨著系統(tǒng)用戶(hù)的不斷增加，系統(tǒng)的訪(fǎng)問(wèn)壓力越來(lái)越多，同時(shí)隨著系統(tǒng)發(fā)展，為了滿(mǎn)足用戶(hù) 的需求，原有的系統(tǒng)需要增加新的功能進(jìn)

7、來(lái)，系統(tǒng)變得越來(lái)越復(fù)雜的時(shí)候，我們會(huì)發(fā)現(xiàn)系統(tǒng)變得越來(lái)越難維護(hù)，難擴(kuò)展，同時(shí)系統(tǒng)伸縮性和可用性也會(huì)受到影響。那 么這個(gè)時(shí)候我們?nèi)绾谓鉀Q這些問(wèn)題呢？明智的辦法就是拆分（這也算是一種解耦），我們需要將原來(lái)的系統(tǒng)根據(jù)一定的標(biāo)準(zhǔn)，比如業(yè)務(wù)相關(guān)性等分為不同的子系統(tǒng)， 不同的系統(tǒng)負(fù)責(zé)不同的功能，這樣切分以后，我們可以對(duì)單獨(dú)的子系統(tǒng)進(jìn)行擴(kuò)展和維護(hù)，從而提高系統(tǒng)的擴(kuò)展性和可維護(hù)性，同時(shí)我們系統(tǒng)的水平伸縮性scale out大 大的提升了。因?yàn)槲覀兛梢杂嗅槍?duì)性的對(duì)壓力大的子系統(tǒng)進(jìn)行水平擴(kuò)展而不會(huì)影響到其它的子系統(tǒng)，而不會(huì)像拆分以前，每次系統(tǒng)壓力變大的時(shí)候，我們都需要對(duì)整 個(gè)大系統(tǒng)進(jìn)行伸縮，而這樣的成本是比較大的，

8、另外經(jīng)過(guò)切分，子系統(tǒng)與子系統(tǒng)之間的耦合減低了，當(dāng)某個(gè)子系統(tǒng)暫時(shí)不可用的時(shí)候，整體系統(tǒng)還是可用的，從而整 體系統(tǒng)的可用性也大大增強(qiáng)了。因此一個(gè)大型的互聯(lián)網(wǎng)應(yīng)用，肯定是要經(jīng)過(guò)拆分，因?yàn)橹挥胁鸱至?，系統(tǒng)的擴(kuò)展性，維護(hù)性,伸 縮性，可用性才會(huì)變的更好。但是拆分也給系 統(tǒng)帶來(lái)了問(wèn)題，就是子系統(tǒng)之間如何通信的問(wèn)題，而具體的通信方式有哪些呢？一般有同步通信和異步通信，這里我們首先來(lái)說(shuō)下同步通信，下面的主題“消息系 統(tǒng)”會(huì)說(shuō)到異步通信。既然需要通信，這個(gè)時(shí)候一個(gè)高性能的遠(yuǎn)程調(diào)用框架就顯得非?？傄?，因此咱們淘寶也有了自己的HSF框 架。上面所說(shuō)的都是拆分的好處，但是拆分以后必然的也會(huì)帶來(lái)新的問(wèn)題，除了剛才說(shuō)的

9、子系統(tǒng)通信問(wèn)題外，最值得關(guān)注的問(wèn)題就是系統(tǒng)之間的依賴(lài)關(guān)系，因?yàn)橄到y(tǒng)多了， 系統(tǒng)的依賴(lài)關(guān)系就會(huì)變得復(fù)雜，此時(shí)就需要更好的去關(guān)注拆分標(biāo)準(zhǔn)，比如能否將一些有依賴(lài)的系統(tǒng)進(jìn)行垂直化，使得這些系統(tǒng)的功能盡量的垂直，這也是目前淘寶正 在做的系統(tǒng)垂直化，同時(shí)一定要注意系統(tǒng)之間的循環(huán)依賴(lài)，如果出現(xiàn)循環(huán)依賴(lài)一定要小心，因?yàn)檫@可能導(dǎo)致系統(tǒng)連鎖啟動(dòng)失敗。OK， 既然明白了拆分的重要性，我們看看隨著淘寶的發(fā)展，淘寶本身是如何拆分系統(tǒng)的。首先我們來(lái)看以下這個(gè)圖：從上面的圖可以看出淘寶系統(tǒng)的一個(gè)演變過(guò)程，在這個(gè)演變的過(guò)程中，我們所說(shuō)的拆分就出現(xiàn)V2.2和V3.0之 間。在V2.2版 本中，淘寶幾乎所有的邏輯都放在(Dena

10、li)系統(tǒng)中，這樣導(dǎo)致的問(wèn)題就是系統(tǒng)擴(kuò)展和修改非常麻煩，并且更加致命的是隨 著淘寶業(yè)務(wù)量的增加，如果按照V2.2的架構(gòu)已經(jīng)沒(méi)有辦法支撐以后淘寶的快速發(fā)展，因此大家決定對(duì)整個(gè)系統(tǒng)進(jìn)行拆分，最 終V3.0版 本的淘寶系統(tǒng)架構(gòu)圖如下：從 上圖可以看出V3.0版 本的系統(tǒng)對(duì)整個(gè)系統(tǒng)進(jìn)行了水平和垂直兩個(gè)方向的拆分，水平方向上，按照功能分為交易，評(píng)價(jià)，用戶(hù)，商品等系統(tǒng)，同樣垂直方向上，劃分為業(yè)務(wù)系統(tǒng)，核心業(yè)務(wù) 系統(tǒng)以及以及基礎(chǔ)服務(wù)，這樣以來(lái)，各個(gè)系統(tǒng)都可以獨(dú)立維護(hù)和獨(dú)立的進(jìn)行水平伸縮，比如交易系統(tǒng)可以在不影響其它系統(tǒng)的情況下獨(dú)立的進(jìn)行水平伸縮以及功能擴(kuò) 展。從上面可以看出，一個(gè)大型系統(tǒng)要想變得可維 護(hù)，可

11、擴(kuò)展，可伸縮，我們必須的對(duì)它進(jìn)行拆分，拆分必然也帶來(lái)系統(tǒng)之間如何通信以及系統(tǒng)之間依賴(lài)管理等問(wèn)題，關(guān)于通信方面，淘寶目前獨(dú)立開(kāi)發(fā)了自己的高性 能服務(wù)框架HSF， 此框架主要解決了淘寶目前所有子系統(tǒng)之間的同步和異步通信（目前HSF主要用于同步場(chǎng)合，F(xiàn)utureTask方 式的調(diào)用場(chǎng)景還比較少）。至于系統(tǒng)間的依賴(lài)管理，目前淘寶還做的不夠好，這應(yīng)該也是我們以后努力解決的問(wèn)題。四 數(shù)據(jù)庫(kù)拆分（TDDL）在前面“應(yīng)用拆分”主題中，我們提到了一個(gè)大型互聯(lián)網(wǎng)應(yīng)用需要進(jìn)行良好的拆分，而那里我們僅僅說(shuō)了”應(yīng)用級(jí)別”的拆 分，其實(shí)我們的互聯(lián)網(wǎng)應(yīng)用除了應(yīng)用級(jí)別的拆分以外，還有另外一個(gè)很重要的層面就是存儲(chǔ)如何拆分的。因

12、此這個(gè)主題主要涉及到如何對(duì)存儲(chǔ)系統(tǒng)，通常就是所說(shuō)的RDBMS進(jìn) 行拆分。好了，確定了這個(gè)小節(jié)的主題之后，我們回顧一下，一個(gè)互聯(lián)網(wǎng)應(yīng)用從小變大的過(guò)程中遇到的一些問(wèn)題，通過(guò)遇到的問(wèn)題來(lái)引出我們拆分RDBMS的 重要性。系統(tǒng)剛開(kāi)始的時(shí)候，因?yàn)橄到y(tǒng)剛上線(xiàn)，用戶(hù)不多，那個(gè)時(shí)候，所有的數(shù)據(jù)都放在了同一個(gè)數(shù)據(jù)庫(kù)中，這個(gè)時(shí)候因?yàn)橛脩?hù)少壓力小，一個(gè)數(shù)據(jù)庫(kù)完全可以應(yīng)付的了，但是 隨著運(yùn)營(yíng)那些哥們辛苦的吶喊和拼命的推廣以后，突然有一天發(fā)現(xiàn)，oh,god,用戶(hù)數(shù)量突然變多了起來(lái)，隨之而 來(lái)的就是數(shù)據(jù)庫(kù)這哥們受不了，它終于在某一天大家都和愜意的時(shí)候掛掉啦。此時(shí)，咱們搞技術(shù)的哥們，就去看看究竟是啥原因，我們查了查以后，發(fā)

13、現(xiàn)原來(lái)是數(shù)據(jù) 庫(kù)讀取壓力太大了，此時(shí)咱們都清楚是到了讀寫(xiě)分離的時(shí)候，這個(gè)時(shí)候我們會(huì)配置一個(gè)server為master節(jié) 點(diǎn)，然后配幾個(gè)salve節(jié) 點(diǎn)，這樣以來(lái)通過(guò)讀寫(xiě)分離，使得讀取數(shù)據(jù)的壓力分?jǐn)偟搅瞬煌膕alve節(jié)點(diǎn)上面，系統(tǒng)終于又恢復(fù)了正常，開(kāi) 始正常運(yùn)行了。但是好景還是不長(zhǎng)，有一天我們發(fā)現(xiàn)master這哥們撐不住了，它負(fù)載老高了，汗 流浹背，隨時(shí)都有翹掉的風(fēng)險(xiǎn)，這個(gè)時(shí)候就需要咱們垂直分區(qū)啦（也就是所謂的分庫(kù)），比如將商品信息，用戶(hù)信息，交易信息分別存儲(chǔ)到不同的數(shù)據(jù)庫(kù)中，同時(shí)還 可以針對(duì)商品信息的庫(kù)采用master，salve模式，OK， 通過(guò)分庫(kù)以后，各個(gè)按照功能拆分的數(shù)據(jù)庫(kù)寫(xiě)壓力被分

14、擔(dān)到了不同的server上面，這樣數(shù)據(jù)庫(kù)的壓力終于有恢復(fù) 到正常狀態(tài)。但是是不是這樣，我們就可以高枕無(wú)憂(yōu)了呢？NO,這個(gè)NO， 不是我說(shuō)的，是前輩們通過(guò)經(jīng)驗(yàn)總結(jié)出來(lái)的，隨著用戶(hù)量的不斷增加，你會(huì)發(fā)現(xiàn)系統(tǒng)中的某些表會(huì)變的異常龐大，比如好友關(guān)系表，店鋪的參數(shù)配置表等，這個(gè)時(shí)候 無(wú)論是寫(xiě)入還是讀取這些表的數(shù)據(jù)，對(duì)數(shù)據(jù)庫(kù)來(lái)說(shuō)都是一個(gè)很耗費(fèi)精力的事情，因此此時(shí)就需要我們進(jìn)行“水平分區(qū)”了（這就是俗話(huà)說(shuō)的分表，或者說(shuō)sharding）.OK,上面說(shuō)了一大堆，無(wú)非就是告訴大家一個(gè)事實(shí)“數(shù)據(jù)庫(kù)是系統(tǒng)中最不容易scale out的一層”，一個(gè)大型的互聯(lián)網(wǎng) 應(yīng)用必然會(huì)經(jīng)過(guò)一個(gè)從單一DB server,到Maste

15、r/salve,再到垂直分區(qū)（分 庫(kù)），然后再到水平分區(qū)（分表，sharding）的過(guò)程，而在這個(gè)過(guò)程中，Master/salve 以 及垂直分區(qū)相對(duì)比較容易，對(duì)應(yīng)用的影響也不是很大。但是分表會(huì)引起一些棘手的問(wèn)題，比如不能跨越多個(gè)分區(qū)join查 詢(xún)數(shù)據(jù)，如何平衡各個(gè)shards的 負(fù)載等等，這個(gè)時(shí)候就需要一個(gè)通用的DAL框架來(lái)屏蔽底層數(shù)據(jù)存儲(chǔ)對(duì)應(yīng)用邏輯的影響，使得底層數(shù)據(jù)的訪(fǎng)問(wèn)對(duì)應(yīng)用透明化。拿淘寶目前的情況來(lái)說(shuō)，淘寶目前也正在從昂貴的高端存儲(chǔ)（小型機(jī)+ORACLE）切換到MYSQL,切 換到MYSQL以 后，勢(shì)必會(huì)遇到垂直分區(qū)（分庫(kù)）以及水平分區(qū)（Sharding）的問(wèn)題，因此目前淘寶根據(jù)自

16、己的業(yè)務(wù)特點(diǎn)也開(kāi)發(fā)了自己的TDDL框架，此框架主要解決了分庫(kù)分表對(duì)應(yīng)用的透明化以及異構(gòu)數(shù)據(jù)庫(kù)之間的數(shù)據(jù)復(fù)制。五 異步通信（Notify）在”遠(yuǎn) 程調(diào)用框架”的 介紹中,我 們說(shuō)了一個(gè)大型的系統(tǒng)為了擴(kuò)展性和伸縮性方面的需求,肯定是要進(jìn)行拆分,但是 拆分了以后,子 系統(tǒng)之間如何通信就成了我們首要的問(wèn)題,在”遠(yuǎn)程調(diào)用框架”小節(jié) 中,我 們說(shuō)了同步通信在一個(gè)大型分布式系統(tǒng)中的應(yīng)用,那么這一小節(jié)我們就來(lái)說(shuō)說(shuō)異步通信.好了,既 然說(shuō)到了異步通信,那 么”消 息中間件”就 要登場(chǎng)了,采 用異步通信這其實(shí)也是關(guān)系到系統(tǒng)的伸縮性,以及最大化的對(duì)各個(gè)子系統(tǒng)進(jìn)行解耦.說(shuō)到異步通信，我們需要關(guān)注的一點(diǎn)是這里的異步一定

17、是根據(jù)業(yè)務(wù)特點(diǎn)來(lái)的，一定是針對(duì)業(yè)務(wù)的異步，通常適合異步的場(chǎng)合是一些松耦合的通信場(chǎng)合，而對(duì)于本身業(yè)務(wù) 上關(guān)聯(lián)度比較大的業(yè)務(wù)系統(tǒng)之間，我們還是要采用同步通信比較靠譜。OK,那 么下一步我們說(shuō)說(shuō)異步能給系統(tǒng)帶來(lái)什么樣子的好處。首先我們想想，假如系統(tǒng)有A和B兩個(gè) 子系統(tǒng)構(gòu)成，假如A和B是 同步通信的話(huà)，那么要想使得系統(tǒng)整體伸縮性提高必須同時(shí)對(duì)A和B進(jìn)行 伸縮，這就影響了對(duì)整個(gè)系統(tǒng)進(jìn)行scale out.其次，同步調(diào)用還會(huì)影響到可用性，從數(shù)學(xué)推理的角度來(lái)說(shuō)，A同 步調(diào)用B， 如果A可 用，那么B可 用，逆否命題就是如果B不 可用，那么A也 不可用，這將大大影響到系統(tǒng)可用性，再次，系統(tǒng)之間異步通信以后可以

18、大大提高系統(tǒng)的響應(yīng)時(shí)間，使得每個(gè)請(qǐng)求的響應(yīng)時(shí)間變短，從而提高用戶(hù)體驗(yàn)，因此異步在 提高了系統(tǒng)的伸縮性以及可用性的同時(shí)，也大大的增強(qiáng)了請(qǐng)求的響應(yīng)時(shí)間（當(dāng)然了，請(qǐng)求的總體處理時(shí)間也許不會(huì)變少）。下面我們就以淘寶的業(yè)務(wù)來(lái)看看異步在淘寶的具體應(yīng)用。交易系統(tǒng)會(huì)與很多其它的業(yè)務(wù)系統(tǒng)交 互，如果在一次交易過(guò)程中采用同步調(diào)用的話(huà)，這就要求要向交易成功，必須依賴(lài)的所有系統(tǒng)都可用，而如果采用異步通信以后，交易系 統(tǒng)借助于消息中間件Notify和 其它的系統(tǒng)進(jìn)行了解耦，這樣以來(lái)當(dāng)其它的系統(tǒng)不可用的時(shí)候，也不會(huì)影響到某此交易，從而提高了系統(tǒng)的可用性。六 非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)(TFS,NOSQL)在一個(gè)大型的互聯(lián)網(wǎng)應(yīng)用當(dāng)中

19、，我們會(huì)發(fā)現(xiàn)并不是所有的數(shù)據(jù)都是結(jié)構(gòu)化的，比如一些配置文件，一個(gè)用戶(hù)對(duì)應(yīng)的動(dòng)態(tài)，以及一次交易的快照等信息，這些信息一般不 適合保存到RDBMS中， 它們更符合一種Key-value的 結(jié)構(gòu)。另外還有一類(lèi)數(shù)據(jù)，數(shù)據(jù)量非常的大，但是實(shí)時(shí)性要求不高，此時(shí)這些數(shù)據(jù)也需要通過(guò)另外的一種存儲(chǔ)方式進(jìn)行存儲(chǔ)，另外一些靜態(tài)文件，比如各個(gè)商品的圖 片，商品描述等信息，這些信息因?yàn)楸容^大，放入RDBMS會(huì)引起讀取性能問(wèn)題，從而影響到其它 的數(shù)據(jù)讀取性能，因此這些信息也需要和其它信息分開(kāi)存儲(chǔ)。而一般的互聯(lián)網(wǎng)應(yīng)用系統(tǒng)都會(huì)選擇把這些信息保存到分布式文件系統(tǒng)中，因此淘寶目前也開(kāi)發(fā)了自己的 分布式文件系統(tǒng)TFS，TFS目 前

20、限制了文件大小為2M， 適合于一些小于2M數(shù) 據(jù)的存放。隨著互聯(lián)網(wǎng)的發(fā)展，業(yè)界從08年 下半年開(kāi)始逐漸流行了一個(gè)概念就是NOSQL。我們都知道根據(jù)CAP理論，一致性，可用性和分區(qū)容錯(cuò)性3者 不能同時(shí)滿(mǎn)足，最多只能同時(shí)滿(mǎn)足兩個(gè)，我們傳統(tǒng)的關(guān)系數(shù)據(jù)采用了ACID的事務(wù)策略，而ACID的 事務(wù)策略更加講究的是一種高一致性而降低了可用性的需求。但是互聯(lián)網(wǎng)應(yīng)用往往對(duì)可用性的要求要略高于一致性的需求，這個(gè)時(shí)候我們就需要避免采用數(shù)據(jù)的ACID事 務(wù)策略，轉(zhuǎn)而采用BASE事 務(wù)策略，BASE事 務(wù)策略是基本可用性，事務(wù)軟狀態(tài)以及最終一致性的縮寫(xiě)，通過(guò)BASE事務(wù)策略，我們可以通過(guò)最終一致性來(lái)提 升系統(tǒng)的可用性。這也是目前很多NOSQL產(chǎn)品所采用的策略，包括facebook 的cassandra,apache hbase,google bigtable等，這些產(chǎn)品非常適合一些非結(jié)構(gòu)化的數(shù)據(jù)，比如key-value形 式的數(shù)據(jù)存儲(chǔ)，并且這些產(chǎn)品有個(gè)很好的優(yōu)點(diǎn)就是水平伸縮性。目前淘寶也在研究和使用一些成熟的NOSQL產(chǎn)品。七 監(jiān)控、預(yù)警系統(tǒng)對(duì)于大型的系統(tǒng) 來(lái)說(shuō)，唯一可靠的就是系統(tǒng)的各個(gè)部分是不可靠。因?yàn)橐粋€(gè)大型的分布式系統(tǒng)中勢(shì)必會(huì)涉及到各種各樣的設(shè)備，比如網(wǎng)絡(luò)交換機(jī)，普通PC機(jī)，各種型號(hào)的網(wǎng)卡，硬盤(pán)，內(nèi)存等等，而這 些東東都在數(shù)量非常多的時(shí)候，出現(xiàn)