1、 NoSQL數據庫的發展歷史簡介
1、web系統的變遷歷史
web1.0時代簡介
基本上就是一些簡單的靜態頁面的渲染，不會涉及到太多的複雜業務邏輯，功能簡單單一，基本上服務器性能不會有太大壓力
缺點：1、Service 越來越多，調用關係變複雜，前端搭建本地環境不再是一件簡單的事。考慮團隊協作，往往會考慮搭建集中式的開發服務器來解決。這種解決方案對編譯型的後端開發來說也許還好，但對前端開發來說並不友好。天哪，我只是想調整下按鈕樣式，卻要本地開發、代碼上傳、驗證生效等好幾個步驟。也許習慣了也還好，但開發服務器總是不那麼穩定，出問題時往往需要依賴後端開發搞定。看似僅僅是前端開發難以本地化，但這對研發效率的影響其實蠻大。
2、JSP 等代碼的可維護性越來越差。JSP 非常強大，可以內嵌 Java 代碼。這種強大使得前後端的職責不清晰，JSP 變成了一個灰色地帶。經常為了趕項目，為了各種緊急需求，會在 JSP 裡揉雜大量業務代碼。積攢到一定階段時，往往會帶來大量維護成本。
web2.0時代簡介
隨著Web2.0的時代的到來，用戶訪問量大幅度提升，同時產生了大量的用戶數據。加上後來的智能移動設備的普及，所有的互聯網平臺都面臨了巨大的性能挑戰。包括web服務器CPU及內存壓力。數據庫服務器IO壓力等
為了解決服務器的性能壓力問題，出現了各種各樣的解決方案，最典型的就是使用MVC的架構，MVC 是個非常好的協作模式，從架構層面讓開發者懂得什麼代碼應該寫在什麼地方。為了讓 View 層更簡單幹脆，還可以選擇 Velocity、Freemaker 等模板，使得模板裡寫不了 Java 代碼。看起來是功能變弱了，但正是這種限制使得前後端分工更清晰。但是同樣也會面臨以下問題
1、前端開發重度依賴開發環境。這種架構下，前後端協作有兩種模式：一種是前端寫 demo，寫好後，讓後端去套模板。淘寶早期包括現在依舊有大量業務線是這種模式。好處很明顯，demo 可以本地開發，很高效。不足是還需要後端套模板，有可能套錯，套完後還需要前端確定，來回溝通調整的成本比較大。另一種協作模式是前端負責瀏覽器端的所有開發和服務器端的 View 層模板開發，支付寶是這種模式。好處是 UI 相關的代碼都是前端去寫就好，後端不用太關注，不足就是前端開發重度綁定後端環境，環境成為影響前端開發效率的重要因素。
2、前後端職責依舊糾纏不清。Velocity 模板還是蠻強大的，變量、邏輯、宏等特性，依舊可以通過拿到的上下文變量來實現各種業務邏輯。這樣，只要前端弱勢一點，往往就會被後端要求在模板層寫出不少業務代碼。還有一個很大的灰色地帶是 Controller，頁面路由等功能本應該是前端最關注的，但卻是由後端來實現。Controller 本身與 Model 往往也會糾纏不清，看了讓人咬牙的代碼經常會出現在 Controller 層。這些問題不能全歸結於程序員的素養，否則 JSP 就夠了。
關於如何解決Web服務器的負載壓力，其中最常用的一種方式就是使用nginx實現web集群的服務轉發以及服務拆分等等
但是這樣也會存在問題，後端服務器的多個tomcat之間如何解決session共享的問題，以及session存放的問題等等
為了解決session存放的問 題，也有多種解決方案
方案一：存放在cookie裡面。不安全，否定
方案二：存放在文件或者數據庫當中。速度慢
方案三：session複製。大量session冗餘，節點浪費大
方案四：使用NoSQL緩存數據庫。例如redis或者memcache等，完美解決
NoSQL適用場景
• 對數據高併發的讀寫
• 海量數據的讀寫
• 對數據高可擴展性的
• 速度夠快，能夠快速的存取數據
NoSQL不適用場景
• 需要事務支持
• 基於sql的結構化查詢存儲，處理複雜的關係,需要即席查詢（用戶自定義查詢條件的查詢）。
總結：用不著sql的和用了sql也不行的情況，請考慮用NoSql
2、 NoSQL數據庫兄弟會
1、memcache介紹
• 很早出現的NoSql數據庫
• 數據都在內存中，一般不持久化
• 支持簡單的key-value模式
• 一般是作為緩存數據庫輔助持久化的數據庫
2、redis介紹
• 幾乎覆蓋了Memcached的絕大部分功能
• 數據都在內存中，支持持久化，主要用作備份恢復
• 除了支持簡單的key-value模式，還支持多種數據結構的存儲，比如 list、set、hash、zset等。
• 一般是作為緩存數據庫輔助持久化的數據庫
• 現在市面上用得非常多的一款內存數據庫
3、mongoDB介紹
• 高性能、開源、模式自由(schema free)的文檔型數據庫
• 數據都在內存中， 如果內存不足，把不常用的數據保存到硬盤
• 雖然是key-value模式，但是對value（尤其是json）提供了豐富的查詢功能
• 支持二進制數據及大型對象
• 可以根據數據的特點替代RDBMS ，成為獨立的數據庫。或者配合RDBMS，存儲特定的數據。
4、列式存儲HBase介紹
• HBase是Hadoop項目中的數據庫。它用於需要對大量的數據進行隨機、實時的讀寫操作的場景中。HBase的目標就是處理數據量非常龐大的表，可以用普通的計算機處理超過10億行數據，還可處理有數百萬列元素的數據表。
3、 Redis的基本介紹以及使用場景
redis官網地址：
https://redis.io/
中文網站
http://www.redis.cn/
redis文章：
https://www.runoob.com/redis/redis-data-types.html
3.1、redis的基本介紹
Redis是當前比較熱門的NOSQL系統之一，它是一個開源的使用ANSI c語言編寫的key-value存儲系統（區別於MySQL的二維表格的形式存儲。）。和Memcache類似，但很大程度補償了Memcache的不足。和Memcache一樣，Redis數據都是緩存在計算機內存中，不同的是，Memcache只能將數據緩存到內存中，無法自動定期寫入硬盤，這就表示，一斷電或重啟，內存清空，數據丟失。所以Memcache的應用場景適用於緩存無需持久化的數據。而Redis不同的是它會週期性的把更新的數據寫入磁盤或者把修改操作寫入追加的記錄文件，實現數據的持久化
3.2、redis的適用場景
1.取最新N個數據的操作
比如典型的取你網站的最新文章，通過下面方式，我們可以將最新的5000條評論的ID放在Redis的List集合中，並將超出集合部分從數據庫獲取
· 使用LPUSH latest.comments命令，向list集合中插入數據
· 插入完成後再用LTRIM latest.comments 0 5000命令使其永遠只保存最近5000個ID
· 然後我們在客戶端獲取某一頁評論時可以用下面的邏輯（偽代碼）
FUNCTION get_latest_comments(start,num_items):
id_list = redis.lrange("latest.comments",start,start+num_items-1)
IF id_list.length < num_items
id_list = SQL_DB("SELECT ... ORDER BY time LIMIT ...")
END
RETURN id_list
END如果你還有不同的篩選維度，比如某個分類的最新N條，那麼你可以再建一個按此分類的List，只存ID的話，Redis是非常高效的。
2.排行榜應用，取TOP N操作
這個需求與上面需求的不同之處在於，前面操作以時間為權重，這個是以某個條件為權重，比如按頂的次數排序，這時候就需要我們的sorted set出馬了，將你要排序的值設置成sorted set的score，將具體的數據設置成相應的value，每次只需要執行一條ZADD命令即可。
3.需要精準設定過期時間的應用
比如你可以把上面說到的sorted set的score值設置成過期時間的時間戳，那麼就可以簡單地通過過期時間排序，定時清除過期數據了，不僅是清除Redis中的過期數據，你完全可以把Redis裡這個過期時間當成是對數據庫中數據的索引，用Redis來找出哪些數據需要過期刪除，然後再精準地從數據庫中刪除相應的記錄。
4.計數器應用
Redis的命令都是原子性的，你可以輕鬆地利用INCR，DECR命令來構建計數器系統。
5.Uniq操作，獲取某段時間所有數據排重值
這個使用Redis的set數據結構最合適了，只需要不斷地將數據往set中扔就行了，set意為集合，所以會自動排重。
6.實時系統，反垃圾系統
通過上面說到的set功能，你可以知道一個終端用戶是否進行了某個操作，可以找到其操作的集合並進行分析統計對比等。沒有做不到，只有想不到。
7.Pub/Sub構建實時消息系統
Redis的Pub/Sub系統可以構建實時的消息系統，比如很多用Pub/Sub構建的實時聊天系統的例子。
8.構建隊列系統
使用list可以構建隊列系統，使用sorted set甚至可以構建有優先級的隊列系統。
9.緩存
將數據直接存放到內存中，性能優於Memcached，數據結構更多樣化。
3.3、redis的特點
高效性：Redis讀取的速度是110000次/s，寫的速度是81000次/s
原子性：Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全並後的原子性執行。
支持多種數據結構：string（字符串）；list（列表）；hash（哈希），set（集合）；zset(有序集合)
穩定性：持久化，主從複製（集群）
其他特性：支持過期時間，支持事務，消息訂閱。
