整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
問localStorage的3種方法：
1 Storage對象的setItem和getItem方法
存儲使用setItem方法,其格式如下
window.localStorage.setItem(key,value);
如：window.localStorage.setItem("userdata"," Hello!HTML5");
讀取使用getItem方法,其格式如下：
window.localStorage.getItem(key);
如：window.localStorage.getItem("userdata");
2 數組索引
存儲語法如下：
window.localStorage["userdata"]="Hello!HTML5";讀取語法如下：
var value=window.localStorage["userdata"];3 屬性
存儲語法如下：
window.localStorage.userdata="Hello!HTML5";讀取語法如下：
var value=window.localStorage.userdata;實例：
地存儲
1 本地存儲簡介
在客戶端存儲數據
HTML5 提供了兩種在客戶端存儲數據的新方法：
localStorage - 沒有時間限制的數據存儲
sessionStorage - 針對一個 session 的數據存儲
之前, 這些都是由 cookie 完成的。但是 cookie 不適合大量數據的存儲, 因為它們由每個對服務器的請求來傳遞, 這使得 cookie 速度很慢而且效率也不高。
HTML5 使用 JavaScript 來存儲和訪問數據。
2 語法
localStorage 方法存儲的數據沒有時間限制。第二天、第二周或下一年之后, 數據依然可用。
localStorage 和sessionStorage分別是本地存儲和會話存儲, 統稱本地存儲。
存儲數據：localStorage.setItem('key','value');
讀取數據：localStorage.getItem('key')
刪除指定數據：localStorage.removeItem('key');
清空所有數據：localStorage.clear()
<!DOCTYPE html>
<html lang="zh">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta http-equiv="X-UA-Compatible" content="ie=edge" />
<title>Document</title>
</head>
<body>
<!--
本地存儲存在自己電腦上了 他不能和服務器交互
一種：本地存儲(永久存儲不會過期)localStorage
一種：臨時會話(頁面關閉數據就沒了)sessionStorage
統稱本地存儲
二者的方法一毛一樣 咱們只以一個舉例子
cookie->可以喝服務器交互 是可以設置過期時間的
-->
<script type="text/javascript">
console.log(localStorage)
console.log(sessionStorage)
//寫入東西(隨便寫,你存儲的值)
//localStorage.setItem(key(小卡片),value(你存的包))
localStorage.setItem("key001","梁永燦");
localStorage.setItem("key002","迪麗熱巴");
localStorage.setItem("key003","楊穎");
localStorage.setItem("key004","大黃");
localStorage.setItem("key004","小黃");
//讀取
console.log(localStorage.getItem("key001"))
//console.log(localStorage)
//刪除
localStorage.removeItem("key001");
//全部刪除
localStorage.clear()
</script>
</body>
</html>本地存儲數據庫會自動的為每一個網站(IP地址)建立一個獨立的表格, 在同一個網站(IP地址)下數據是可以共享的, 但是不能跨域。
不能跨瀏覽器存儲, 每個瀏覽器都有自己的小數據庫, Chrome存儲的, 火狐看不見。
localStorage是簡單的數據庫, 沒有查詢功能, 不能用sql操作, 只能簡單的存儲、讀取k-v對。
sessionStorage 瀏覽器窗口一旦關閉, 數據就丟失了
localStorage存儲的數據, 永遠不丟失, 關機, 重啟都不會導致數據丟失, 除非清除了瀏覽器記錄
注意: 判斷localStorage和sessionStorage是否有數據使用if直接判斷
if(localStorage.getItem("key001")){
}不能使用
擊上方"java全棧技術"關注我們，每天學習一個java知識點
階段一、單機構建網站
網站的初期，我們經常會在單機上跑我們所有的程序和軟件。此時我們使用一個容器，如tomcat、jetty、jboos，然后直接使用JSP/servlet技術，或者使用一些開源的框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；最后再選擇一個數據庫管理系統來存儲數據，如mysql、sqlserver、oracle，然后通過JDBC進行數據庫的連接和操作。
把以上的所有軟件都裝載同一臺機器上，應用跑起來了，也算是一個小系統了。此時系統結果如下：
階段二、應用服務器與數據庫分離
隨著網站的上線，訪問量逐步上升，服務器的負載慢慢提高，在服務器還沒有超載的時候，我們應該就要做好準備，提升網站的負載能力。假如我們代碼層面已難以優化，在不提高單臺機器的性能的情況下，增加機器是一個不錯的方式，不僅可以有效地提高系統的負載能力，而且性價比高。
增加的機器用來做什么呢？此時我們可以把數據庫，web服務器拆分開來，這樣不僅提高了單臺機器的負載能力，也提高了容災能力。
應用服務器與數據庫分開后的架構如下圖所示：
階段三、應用服務器集群
隨著訪問量繼續增加，單臺應用服務器已經無法滿足需求了。在假設數據庫服務器沒有壓力的情況下，我們可以把應用服務器從一臺變成了兩臺甚至多臺，把用戶的請求分散到不同的服務器中，從而提高負載能力。多臺應用服務器之間沒有直接的交互，他們都是依賴數據庫各自對外提供服務。著名的做故障切換的軟件有keepalived，keepalived是一個類似于layer3、4、7交換機制的軟件，他不是某個具體軟件故障切換的專屬品，而是可以適用于各種軟件的一款產品。keepalived配合上ipvsadm又可以做負載均衡，可謂是神器。
我們以增加了一臺應用服務器為例，增加后的系統結構圖如下：
系統演變到這里，將會出現下面四個問題：
我們來看看解決問題的方案：
第一個問題即是負載均衡的問題，一般有5種解決方案：
1、http重定向。HTTP重定向就是應用層的請求轉發。用戶的請求其實已經到了HTTP重定向負載均衡服務器，服務器根據算法要求用戶重定向，用戶收到重定向請求后，再次請求真正的集群
2、DNS域名解析負載均衡。DNS域名解析負載均衡就是在用戶請求DNS服務器，獲取域名對應的IP地址時，DNS服務器直接給出負載均衡后的服務器IP。
3、反向代理服務器。在用戶的請求到達反向代理服務器時（已經到達網站機房），由反向代理服務器根據算法轉發到具體的服務器。常用的apache，nginx都可以充當反向代理服務器。
4、IP層負載均衡。在請求到達負載均衡器后，負載均衡器通過修改請求的目的IP地址，從而實現請求的轉發，做到負載均衡。
5、數據鏈路層負載均衡。在請求到達負載均衡器后，負載均衡器通過修改請求的mac地址，從而做到負載均衡，與IP負載均衡不一樣的是，當請求訪問完服務器之后，直接返回客戶。而無需再經過負載均衡器。
第二個問題即是集群調度算法問題，常見的調度算法有10種：
1、rr 輪詢調度算法。顧名思義，輪詢分發請求。
2、wrr 加權調度算法。我們給每個服務器設置權值weight，負載均衡調度器根據權值調度服務器，服務器被調用的次數跟權值成正比。
3、sh 原地址散列：提取用戶IP，根據散列函數得出一個key，再根據靜態映射表，查處對應的value，即目標服務器IP。過目標機器超負荷，則返回空。
4、dh 目標地址散列：同上，只是現在提取的是目標地址的IP來做哈希。
5、lc 最少連接。優先把請求轉發給連接數少的服務器。
6、wlc 加權最少連接。在lc的基礎上，為每臺服務器加上權值。算法為：（活動連接數*256+非活動連接數）÷權重 ，計算出來的值小的服務器優先被選擇。
7、sed 最短期望延遲。其實sed跟wlc類似，區別是不考慮非活動連接數。算法為：（活動連接數+1)*256÷權重，同樣計算出來的值小的服務器優先被選擇。
8、nq 永不排隊。改進的sed算法。我們想一下什么情況下才能“永不排隊”，那就是服務器的連接數為0的時候，那么假如有服務器連接數為0，均衡器直接把請求轉發給它，無需經過sed的計算。
9、LBLC 基于局部性的最少連接。均衡器根據請求的目的IP地址，找出該IP地址最近被使用的服務器，把請求轉發之，若該服務器超載，最采用最少連接數算法。
10、LBLCR 帶復制的基于局部性的最少連接。均衡器根據請求的目的IP地址，找出該IP地址最近使用的“服務器組”，注意，并不是具體某個服務器，然后采用最少連接數從該組中挑出具體的某臺服務器出來，把請求轉發之。若該服務器超載，那么根據最少連接數算法，在集群的非本服務器組的服務器中，找出一臺服務器出來，加入本服務器組，然后把請求轉發之。
第三個問題是集群模式問題，一般3種解決方案：
1、NAT：負載均衡器接收用戶的請求，轉發給具體服務器，服務器處理完請求返回給均衡器，均衡器再重新返回給用戶。
2、DR：負載均衡器接收用戶的請求，轉發給具體服務器，服務器出來玩請求后直接返回給用戶。需要系統支持IP Tunneling協議，難以跨平臺。
3、TUN：同上，但無需IP Tunneling協議，跨平臺性好，大部分系統都可以支持。
第四個問題是session問題，一般有4種解決方案：
1、Session Sticky。session sticky就是把同一個用戶在某一個會話中的請求，都分配到固定的某一臺服務器中，這樣我們就不需要解決跨服務器的session問題了，常見的算法有ip_hash法，即上面提到的兩種散列算法。
2、Session Replication。session replication就是在集群中復制session，使得每個服務器都保存有全部用戶的session數據。
3、Session數據集中存儲：session數據集中存儲就是利用數據庫來存儲session數據，實現了session和應用服務器的解耦。
4、Cookie Base：cookie base就是把session存在cookie中，有瀏覽器來告訴應用服務器我的session是什么，同樣實現了session和應用服務器的解耦。
值得一提的是：
nginx目前支持的負載均衡算法有wrr、sh（支持一致性哈希）、fair（本人覺得可以歸結為lc）。但nginx作為均衡器的話，還可以一同作為靜態資源服務器。
keepalived+ipvsadm比較強大，目前支持的算法有：rr、wrr、lc、wlc、lblc、sh、dh
keepalived支持集群模式有：NAT、DR、TUN
nginx本身并沒有提供session同步的解決方案，而apache則提供了session共享的支持。
好了，解決了以上的問題之后，系統的結構如下：
階段四、數據庫讀寫分離化
上面我們總是假設數據庫負載正常，但隨著訪問量的的提高，數據庫的負載也在慢慢增大。那么可能有人馬上就想到跟應用服務器一樣，把數據庫一份為二再負載均衡即可。
但對于數據庫來說，并沒有那么簡單。假如我們簡單的把數據庫一分為二，然后對于數據庫的請求，分別負載到A機器和B機器，那么顯而易見會造成兩臺數據庫數據不統一的問題。那么對于這種情況，我們可以先考慮使用讀寫分離的方式。
讀寫分離后的數據庫系統結構如下：
這個結構變化后也會帶來兩個問題：
解決問題方案：我們可以使用MYSQL自帶的master+slave的方式實現主從復制。
采用第三方數據庫中間件，例如mycat。mycat是從cobar發展而來的，而cobar是阿里開源的數據庫中間件，后來停止開發。mycat是國內比較好的mysql開源數據庫分庫分表中間件。
階段五、用搜索引擎緩解讀庫的壓力
數據庫做讀庫的話，常常對模糊查找力不從心，即使做了讀寫分離，這個問題還未能解決。以我們所舉的交易網站為例，發布的商品存儲在數據庫中，用戶最常使用的功能就是查找商品，尤其是根據商品的標題來查找對應的商品。對于這種需求，一般我們都是通過like功能來實現的，但是這種方式的代價非常大。此時我們可以使用搜索引擎的倒排索引來完成。
搜索引擎具有以下優點：
它能夠大大提高查詢速度。
引入搜索引擎后也會帶來以下的開銷：帶來大量的維護工作，我們需要自己實現索引的構建過程，設計全量/增加的構建方式來應對非實時與實時的查詢需求。需要維護搜索引擎集群搜索引擎并不能替代數據庫，他解決了某些場景下的"讀"的問題，是否引入搜索引擎，需要綜合考慮整個系統的需求。
引入搜索引擎后的系統結構如下：
階段六、用緩存緩解讀庫的壓力
1、后臺應用層和數據庫層的緩存
隨著訪問量的增加，逐漸出現了許多用戶訪問同一部分內容的情況，對于這些比較熱門的內容，沒必要每次都從數據庫讀取。我們可以使用緩存技術，例如可以使用google的開源緩存技術guava或者使用memcacahe作為應用層的緩存，也可以使用redis作為數據庫層的緩存。
另外，在某些場景下，關系型數據庫并不是很適合，例如我想做一個"每日輸入密碼錯誤次數限制"的功能，思路大概是在用戶登錄時，如果登錄錯誤，則記錄下該用戶的IP和錯誤次數，那么這個數據要放在哪里呢？假如放在內存中，那么顯然會占用太大的內容；假如放在關系型數據庫中，那么既要建立數據庫表，還要簡歷對應的java bean，還要寫SQL等等。
而分析一下我們要存儲的數據，無非就是類似{ip:errorNumber}這樣的key:value數據。對于這種數據，我們可以用NOSQL數據庫來代替傳統的關系型數據庫。
2、頁面緩存
除了數據緩存，還有頁面緩存。比如使用HTML5的localstroage或者cookie。
值得一提的是：緩存集群的調度算法不同與上面提到的應用服務器和數據庫。最好采用"一致性哈希算法"，這樣才能提高命中率。這個就不展開講了，有興趣的可以查閱相關資料。
加入緩存后的結構：
階段七、數據庫水平拆分與垂直拆分
我們的網站演進到現在，交易、商品、用戶的數據都還在同一個數據庫中。盡管采取了增加緩存，讀寫分離的方式，但隨著數據庫的壓力繼續增加，數據庫的瓶頸越來越突出，此時，我們可以有數據垂直拆分和水平拆分兩種選擇。
7.1 數據垂直拆分垂直拆分的意思是把數據庫中不同的業務數據拆分道不同的數據庫中，結合現在的例子，就是把交易、商品、用戶的數據分開。
解決問題方案：我們應該在應用層盡量避免跨數據庫的事物，如果非要跨數據庫，盡量在代碼中控制。我們可以通過第三方應用來解決，如上面提到的mycat，mycat提供了豐富的跨庫join方案，詳情可參考mycat官方文檔。垂直拆分后的結構如下：
7.2 數據水平拆分
數據水平拆分就是把同一個表中的數據拆分到兩個甚至多個數據庫中。產生數據水平拆分的原因是某個業務的數據量或者更新量到達了單個數據庫的瓶頸，這時就可以把這個表拆分到兩個或更多個數據庫中。
解決問題方案：我們還是可以通過可以解決第三方中間件，如mycat。mycat可以通過SQL解析模塊對我們的SQL進行解析，再根據我們的配置，把請求轉發到具體的某個數據庫。
我們可以通過UUID保證唯一或自定義ID方案來解決。
mycat也提供了豐富的分頁查詢方案，比如先從每個數據庫做分頁查詢，再合并數據做一次分頁查詢等等。
數據水平拆分后的結構：
階段八、應用的拆分
8.1 拆分應用
隨著業務的發展，業務越來越多，應用越來越大。我們需要考慮如何避免讓應用越來越臃腫。這就需要把應用拆開，從一個應用變為倆個甚至更多。
還是以我們上面的例子，我們可以把用戶、商品、交易拆分開。變成"用戶、商品"和"用戶，交易"兩個子系統。拆分后的結構：
問題： 這樣拆分后，可能會有一些相同的代碼，如用戶相關的代碼，商品和交易都需要用戶信息，所以在兩個系統中都保留差不多的操作用戶信息的代碼。如何保證這些代碼可以復用是一個需要解決的問題。
解決問題：通過走服務化的路線來解決
8.2 走服務化的道路
為了解決上面拆分應用后所出現的問題，我們把公共的服務拆分出來，形成一種服務化的模式，簡稱SOA。采用服務化之后的系統結構：·
解決方法：我們可以通過下面的引入消息中間件來解決
階段九、引入消息中間件
隨著網站的繼續發展，我們的系統中可能出現不同語言開發的子模塊和部署在不同平臺的子系統。此時我們需要一個平臺來傳遞可靠的，與平臺和語言無關的數據，并且能夠把負載均衡透明化，能在調用過程中收集調用數據并分析之，推測出網站的訪問增長率等等一系列需求，對于網站應該如何成長做出預測。
開源消息中間件有阿里的dubbo，可以搭配Google開源的分布式程序協調服務zookeeper實現服務器的注冊與發現。
引入消息中間件后的結構：
十、總結
以上的演變過程只是一個例子，并不適合所有的網站，實際中網站演進過程與自身業務和不同遇到的問題有密切的關系，沒有固定的模式。只有認真的分析和不斷地探究，才能發現適合自己網站的架構。
出處：https://www.jianshu.com/p/dc3db4402717
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
