克隆

通常來說，公共服務器上的一個可伸縮的web服務總是隱藏在一個Load Balancer（負載均衡器）之后。這個負載均衡器會將負載（來自用戶的請求）均勻的分配到一組服務器或者服務器集群。那意味著什么？舉個例子：某個用戶訪問你的服務，他第一次的請求可能會由第二臺服務器提供，第二次請求由第9臺服務器提供，第3次請求又再次由第二臺服務器提供。

成都創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都網(wǎng)站制作、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的常山網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

對于該用戶而言，他每次得到的結果應該是一樣的，不依賴服務到底是哪臺服務器提供的。這個正是可伸縮性的第一個黃金法則：每個服務器都包含完全相同的代碼庫，不在本地磁盤或內(nèi)存存儲任何與用戶相關的數(shù)據(jù)，如session或用戶信息。Session需要集中存儲，使得每一臺服務器都可以訪問到它。它可以是一個外部數(shù)據(jù)庫或外部持久緩存，比如Redis。相比外部數(shù)據(jù)庫，在持久化的緩存中存放session將會有更好的性能。這里提到的“外部”指的是數(shù)據(jù)存儲不放置在這些應用服務器上，而是在接近您的應用程序服務器的數(shù)據(jù)中心。

但是這要怎么部署呢？你如何確定當應用代碼發(fā)生了改變能夠發(fā)送到所有的服務器而沒有一臺服務器依舊使用之前的代碼？幸運的是，這個棘手的問題已經(jīng)被一個很好的工具capistrano解決了，你需要稍微學習了解下。

在解決了session和多臺服務器上新版本的同步更新問題之后，你需要做的就是克隆你的機器鏡像了，然后將你最新的代碼部署上去。可以參考Amazon提供的AMI服務（Amazon Machine Image）

現(xiàn)在你的服務器可以水平擴展，并且處理成千上萬的并發(fā)請求了。

數(shù)據(jù)庫

但是你發(fā)現(xiàn)應用程序變得越來越來最終崩潰。問題的原因：是MySql，不是嗎？
現(xiàn)在不是增加更多的機器可以解決的問題了，你有兩種辦法：

• 1，堅持使用MySql，并且讓它運行良好。做主從復制（從服務器負責讀取，主服務器負責寫入），并且升級主服務器，不斷加入更多的內(nèi)存。隨著不斷優(yōu)化，你會使用數(shù)據(jù)庫分片、反規(guī)模化、SQL調優(yōu)等常用手段。這時，對于數(shù)據(jù)庫的任何一個操作成本都會變得相當昂貴。

• 2，切換到一個更加容易擴展的NoSQL數(shù)據(jù)庫，比如 MongoDB或CouchDB，連接查詢現(xiàn)在需要在應用代碼層里去進行了。

現(xiàn)在，你的數(shù)據(jù)庫有了一個可擴展的解決方案了，你再也不用擔心存儲TB級的數(shù)據(jù)，世界看起來那么的美好。

緩存

當大量的數(shù)據(jù)請求發(fā)往到數(shù)據(jù)庫，你發(fā)現(xiàn)又變慢了，解決辦法是增加緩存。
這里說的緩存指的是內(nèi)存緩存，比如常見的內(nèi)存數(shù)據(jù)庫Memcached或者Redis ，千萬不要使用文件緩存，它會讓你服務器的克隆和自動伸縮很痛苦。

但是回到內(nèi)存緩存，緩存是一個簡單的鍵值存儲并且應該介于應用程序和數(shù)據(jù)存儲。任何時候當你的應用程序需要去讀取數(shù)據(jù)時，它首先應該嘗試從緩存里面獲取數(shù)據(jù)，只有無法從緩存中讀取數(shù)據(jù)時，才會嘗試從數(shù)據(jù)庫中讀到。為什么要這么做呢？因為緩存快如閃電，它將數(shù)據(jù)集存放在內(nèi)存中，并且可以快速的被處理。舉個例子：Redis沒秒鐘可以處理成千上萬的讀操作。

訪問流程：第一次訪問綠色，第二次和之后的藍色：

有兩種緩存數(shù)據(jù)的模式，一種是老的方式，一種是新的方式：

• 1，緩存數(shù)據(jù)庫查詢，這個仍然是最普遍的緩存方式，當你做一次查詢時，將數(shù)據(jù)集進行緩存，通過哈希后查詢串作為鍵。下一次查詢時，檢查緩存中是否有結果。這種方式存在一些問題，最主要的問題就是過期。當數(shù)據(jù)表中的一塊數(shù)據(jù)發(fā)生變化時，你需要刪除所有包含這個數(shù)據(jù)塊的查詢串的緩存。

• 2，緩存對象，我強烈推薦使用這種方式，這也是我經(jīng)常使用的。

一些適合緩存的對象：

• 用戶Session（永遠不存放在數(shù)據(jù)庫中）

• 完全呈現(xiàn)的博客文章

• 活動流

• 用戶<- -> 朋友 之類的關系

異步

請想象一下，你想在你最喜歡的面包店買面包，所以你走進面包店，向一個店員詢問購買面包，但是面包都賣光了。你被告知2個小時之后你訂的面包可以好，這個很惱人，不是嗎？
為了避免這種“請等片刻”的場景，需要采取異步。比如什么時候有面包了，店員會將面包派送給你的家里。通常來說，有兩種異步的范例：

• 1，讓我們回到普通的買面包的場景，第一種異步處理流程是：“晚上把面包都烹制好，第二天早上賣”，這個對于顧客來說不需要等待。對于一個web應用程序，這意味著提前做耗時的工作，這樣就可以在短時間處理完工作。通常這種模式用來將動態(tài)的內(nèi)容轉換為靜態(tài)內(nèi)容。比如提前渲染好CMS里面的一些網(wǎng)頁，并且本地存儲這些HTML文件。采用定時任務，可能是通過腳本叫做每小時的計劃。這種對通用數(shù)據(jù)預先計算可以極大的提升網(wǎng)站和web app的可伸縮性和性能。可以通過腳本將這些預先渲染好的HTML頁面發(fā)布至CDN。你的網(wǎng)站將能做到響應超快并且每小時可以處理成千上萬的游客!

• 2，回到面包店，有的時候顧客可能會有一些特殊的需求，不然在面包上加上“生日快樂”等裝飾。面包店并不能提前知道這種顧客類型的需求，所以當顧客來到店里后，必須馬上開啟一個任務并且告訴他：”你明天再來吧！“ 對于web而言，這意味著異步任務。這里有一個典型的工作流：一個用戶來到你的網(wǎng)站，開始一項計算密集型任務，這個任務需要花費幾分鐘來完成，所以網(wǎng)站前端會往任務隊列里面發(fā)送一個任務，并且告訴用戶你的任務已經(jīng)在處理中了，你可以繼續(xù)瀏覽網(wǎng)頁了。一個任務隊列會不斷的被處理任務的workers 檢查處理。如果有一個新任務，work會處理這個任務，過了幾分鐘之后會發(fā)送一個處理完畢的消息信號。前端會不斷的檢查（比如輪詢）這個任務是否已經(jīng)處理完，一旦處理完則通知用戶。如果你想更深入了解，推薦你去看看RabbmitMQ)，Rabbit MQ是一個實現(xiàn)了異步消息隊列的優(yōu)秀中間件。你也可以使用ActiveMQ或者一個簡單的Redis list，異步消息隊列看起來很復雜，但是它值得你花時間去學習和實現(xiàn)。

如果你做一些耗時的操作，試著采用異步。

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

分享名稱：可伸縮架構簡短系列-創(chuàng)新互聯(lián)
當前網(wǎng)址：http://chinadenli.net/article18/ddpsgp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供響應式網(wǎng)站、定制網(wǎng)站、靜態(tài)網(wǎng)站、網(wǎng)站導航、網(wǎng)站制作、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)