減少用戶感知的響應時間，提高用戶滿意度，提高平臺或解決方案的可擴展性。盡可能地利用Ajax和緩存Ajax調用，可以提高用戶滿意度，提高可擴展性。
對于新人或者不熟悉常見的網絡術語的人來說，可以把Ajax看作隱藏在下拉式菜單后的“方法”，當你輸入字符串時，可以以給你提示，或者把它看作隱藏在地圖服務中的“方法”，讓你能夠無需再次調用遠程服務器，就能夠放大或縮小地圖。如果使用得當，利用Ajax不僅可以得到極好的與用戶互動的界面，而且由于無需額外的服務器端工作就能讓用戶處理數據和對象并與之交互，還能提高可擴展性。但是，如果使用不當，那么Ajax會極大地增加服務器需處理的請求數，從而制造出一些特有的擴展性約束。但要注意，雖然這些請求從瀏覽器端來看是異步的，卻可能在短時間內造成服務器群內的請求泛濫并造成服務器癱瘓。雖然常常被稱為一種技術，但最好的描述還是瀏覽器用于創建更豐富的更具有交互性的Web應用的一組技巧、語言、方法和技術的集合。雖然這個縮寫中的詞語描述了Ajax的實現方式，但真正的用戶交互可能不是異步的，不必只用XML作為數據交換的格式。例如，可以用JSON代替XML。但 Javascript是無可替代的。
Jesse James Garrett因在2005年發表的文章“Ajax:創建Web應用的新方法”?中創造了術語Ajax而廣泛被人提及。寬泛地說，Ajax具有用CSS和 DHTML實現的標準表達方式、用文檔對象模型(DOM)實現的交互和動態顯示能力、用XSLT或JSON實現的XML這樣的數據交換和操作機制，以及數據檢索機制。從終端用戶的角度看，數據檢索通常是異步的(但并不絕對必須是異步的)。 Javascript是用于實現客戶端瀏覽器內交互的語言。當使用異步數據傳輸時，要采用Xmlhttprequest對象。我們最初的因特網經驗是所有東西都是請求和應答這樣的交互，Ajax的目的就是終止這些復雜的交互。有了這些背景知識，讓我們看看與Ajax相關的擴展性方面需要注意的問題，最后看看緩存如何幫助我們解決這些問題。
顯然，我們一直想創建能夠提高用戶交互和滿意度的界面，這樣就能夠增加收益、利潤和股東的財富。Ajax就是這樣一種方法，利用它可以給最終用戶提供更豐富更實時的體驗。由于它能減少瀏覽器內不必要的交互，所以用戶交互可以發生得更快。用戶可以進行放大或縮小操作，而無需等待服務器的響應，可以用以前的條目預填充下拉式菜單，當用戶在搜索欄中輸人查詢字符串時，他們可以看得一些潛在搜索字符串，從中他們也許會找到更具有指導性的搜索條件。利用Ajax的異步性，無需讓用戶點擊“下一頁”，就可以根據某些用戶操作反復接收郵件，幫助我們把郵件結果載入客戶瀏覽器。
但是有些操作會不利于對平臺進行有效擴展。以用戶在Web站點輸搜察項搜索持定的產品為例。我們可能想在用人搜索項時，彈出一個下拉式菜單，列出一些建議的搜索項，這樣我們需要查詢產品目錄來填充菜單。Ajax響應后繼的擊鍵把請求發送給服務器器，基于迄今為止輸人的字符串返回一個結果填充下拉式菜單，而用戶在輸人時無需瀏覽器刷新頁面。否則，可能會由于用戶還沒有輸人完整的字符串，而返回不完整字符串的完整搜索結果。這兩種實現在許多搜索引和電子商務站點都很常見。但是，讓每個后繼的擊鍵都對服務器產生一個搜索查詢，對后臺系統來說，不僅成本高，而且是一種浪費。例如，用戶輸入“ beanie baby”會引發111次連續的搜索，而真正需要的只有一次。這樣的用戶體驗可能令人印象深刻，但是如果用戶輸人足夠快，那么在結束輸人前可能有8到10個搜索都不會真正返回結果。
還有一種方法，能夠在不增加10倍流量的情況下達到相同的目標，你也許能根據本章的主題猜到這種方法，那就是利用緩存。只需要很少的工作，就可以把上一次Ajax交互的結果緩存在客戶瀏覽器中、也可能是緩存在CDN(請參閱原則20)、頁面緩存(請參閱原則23)、應用緩存(請參閱原則24)中。首先，讓我們看看如何利用瀏覽器的緩存。三個能確保我們在瀏覽器中緩存內容的關鍵元素是HTTP響應中的cache- contro1頭、Expires頭和Last-Modified頭。我們在原則21中詳細討論過其中的兩個。對于 Cache-Contro1，要避免使用no- store，在可能的地方把它設置為 public，這樣我們的終端(客戶)和服務器之間的任何代理和緩存(如CDN)都可以保存結果集，向其他請求提供數據。當然，我們不想把私有數據設置為 public，但在可能的情況下，我們當然想利用pub1ic提供的高度緩存。
記住，我們的目標是減往而少服務器的負載。因此，應該把響應的 Expires頭的時間設置得足夠長，才能使瀏覽器在本地緩存第一個查詢的結果，以便之后的請求能夠從緩存中讀取它。對于靜態對象和半靜態對象，如用戶頭像或公司標志
可以把 Expires設置為幾天或時間更長一些。有些對象肯定對時間敏感，如讀取朋友博客上的狀態更新。對于這種情況，可以把 Expires頭設置為幾秒或幾分鐘，這樣既考慮到了實時性，又減少了全局負載。
使用Last- Modified頭可以處理有條件的GE請求。在這種情況下，為了與HTTP1.1協議保持一致，如果緩存中的數據項是正確的或仍然有效，服務器應該用狀態304響應。如Xmlhttpreuqest這個名字的Http部分所示，所有這些的關鍵在于，Ajax請求的表現與其他任何HTTP請求和響應的表現一樣。知道了這些，有助于確保支持這些請求的系統的緩存能力、可用性和可擴展性。
當我們的內容在瀏覽器端可以更改時，前面的方法很有效，但對于逐漸擴展的搜索字符串，問題就變得有點困難了，在用戶與搜索頁面交互，并輸入檢索字符串時，就會出現這種情況。對于這種特殊情況，沒有簡單的解決方案。但在 cache- ontic1頭中使用pub1iC參數可以確保把所有相近的搜索字符串都緩存到中間緩存和代理中。因此，被搜索字符串的常見開頭和常見的中間部分很可能在讀取它們之前就已經被緩存在某處了。這種特殊問題可以推廣到利用Ajax的頁面中的其他特定對象上。例如，請求拍賣中的物品的系統、請求社交網站站中的消息的系統或者郵件系統，在發出請求時，不應該使用相對位移量，而應該使用特定的消息ID。像"page=3&item=2”這樣的相對名字，標識的是系統的第三頁中的第二條消息，隨著系統的改變，可能會造成緩存一致性問題。較好的方法是使用id=124556”，這個ID表示一個原子項目，不會改變可以為這個用戶進行緩存，如果它的屬性是公共的，那么將來還可以被
較容易解決的情況是我們知道自己有哪些網站制作靜態或半靜態的項目集合，例如有限的或者上下文相關的產品目錄。從客戶端來看，我們可以異步獲取這些結果，把它們緩存起來，可以供同一個客戶將來使用，更重要的是確保CDN和中間緩存或代理程序緩存了它，以便其他用戶執行相近的搜索時使用。
本文地址：http://m.knowyourextract.com//article/3474.html
