[挑戰年薪30萬]之NoSQL數據庫的前世今生

web系統的變遷歷史

web1.0

基本是一些簡單的靜態頁面的渲染，不會涉及太多複雜的業務邏輯，功能簡單單一，基本不會對服務器性能造成很大壓力

缺點：

Service數量不斷增加，調用關係日益複雜，構建本地環境的前端工作也不再簡單。在考慮團隊協作時，常常會考慮構建集中的開發服務器來解決問題。對於編譯型的後端開發，這個解決方案可能會很好，但是對於前端開發就不太好了。例如：我只是想調整按鈕的風格，卻要本地開發，代碼上傳，驗證生效等等幾個步驟都需要做。或許習慣了也不錯，但是開發服務器總是不太穩定，經常需要依靠後端開發來解決問題。表面上看，前端開發很難本地化，實際上這對研發效率的影響還很大。

JSP等代碼的可維護性越來越差。jsp非常強大，可以嵌入 Java代碼。這使得前後端的職責不明確， JSP也成了一塊灰色區域。通常為了趕項目進度，為了滿足各種緊急需求，會在 JSP中加入大量的業務代碼。積累到一定階段，常常會產生大量的維護成本。

web2.0

伴隨着 web2.0時代的到來，用户訪問大大增加，同時也產生了大量的用户數據。隨着智能移動設備的普及，所有互聯網平台都面臨着性能方面的巨大挑戰。包含了web服務器的 CPU和內存壓力，數據庫服務器IO壓力等....

有很多解決方案可以用來解決服務器的性能壓力問題，最典型的就是使用 MVC的體系結構，這是一種很好的協作模式，從體系結構層面上讓開發人員知道應該在哪裏編寫代碼。要使 View層變得更加簡單，您也可以選擇 Velocity、 Freemaker等模板，這樣就不會在模板中編寫 Java代碼。似乎功能變弱了，但是正是這種限制使得前後端的分工更加明確。不過，我們同樣面臨以下問題

前端開發嚴重依賴於一個開發環境。在該體系結構中，前、後端協作有兩種模式：前寫 demo，讓後端去套模板。包括目前仍然有大量的淘寶店鋪都是這種模式。優點是 demo可以在本地開發，而且非常高效。缺點是還需要後端套版模板，有可能套版出錯，套版之後還需要前端確定，來回溝通調整成本比較大。另一種協作模式是前端負責瀏覽器端的所有開發和服務器端的 View 層模板開發，支付寶是這種模式。優點是 UI相關的代碼在前端就可以全部寫完，後端不用太關注，缺點是前端開發嚴重束縛了後端環境，環境成為影響前端開發效率的重要因素。

前後端責任依然糾纏不清。Velocity模板還是相當強大的，其變量、邏輯、宏等特性，仍然能夠通過上下文變量實現多種業務邏輯。這樣一來，只要前端不夠薄弱，往往會被後端要求在模板層寫下大量的業務代碼。此外， Controller（控制器）也是灰色地帶，頁面路徑等功能本應是前端最關注的，但卻被後端所實現。Controller（控制器）本身也常常被 Model所纏繞，看到那些讓人咬牙的代碼時，Controller（控制器）層常常會出現它們。不能把所有問題都歸結為程序員的素養，否則 JSP就足夠了。

對於如何處理 Web服務器的負載壓力，最常用的方法之一是使用 nginx來實現 Web集羣的服務轉發和服務拆分等等

但這也有問題，如何在後端服務器的多個 tomcat之間解決 session共享以及 session存儲等問題。

對於解決 session存儲的問題，還可以使用多種解決方案：

第一種方法：保存在 cookie中。沒有保障，不安全！

第二種方法：存儲在文件或數據庫中。讀取速度慢！

第三種方法： session複製。過多的會話冗餘，節點浪費過大！

第四種方法：使用 NoSQL數據庫緩存。比如， redis或 memcache等，完美解決

NoSQL適用場景：

高併發對數據進行讀寫

海量數據讀寫

對數據高度可擴展性

速度夠快，能夠快速地存取數據

NoSQL不適用場景

要求事務支持（僅限於簡單的事務）

在 sql基礎上建立結構化的查詢存儲，處理複雜的關係，需要即席查詢（用户自定義查詢條件的查詢）。

總結：用不着sql的和用了sql也不行的情況，請考慮用NoSql