Redis - NoSQL數據庫技術（一）

NoSQL入門概述（一）

做者 ： Stanley 羅昊

【轉載請註明出處和署名，謝謝！】

什麼是NoSQL

NoSQL(NoSQL - Not Only SQL),意「不只僅是SQL」；

泛指非關係型的數據庫；

隨着互聯網web2.0網站的興起，傳統的關係數據庫在應對web2.0網站，特別是超大規模和高併發的SNS類型的web2.0純動態網站以及顯得力不從心，暴露了不少難以克服的問題，而非關係型的數據庫則因爲其自己的特色獲得了很是迅速的發展；

NoSQL數據庫的產生就是爲了解決大規模數據集合，多重複數據種類帶來的挑戰，尤爲是大數據應用難題，包括大規模數據的存儲。

（例如谷歌或Facebook天天爲澳門的用戶手機萬億比特的數據），這些類型的數據存儲不須要固定的模式，無需多餘操做就能夠橫向擴展；

爲何用NoSQL

在最先的項目研發時期，是單機MySQL的美好年代，無非就是三層架構，dao層直接訪問數據庫獲取數據後響應給客戶便可，很是簡單；

可是隨着時代的改變，以及互聯網用戶愈來愈多，大規模的互聯網公司興起，數據量急劇增長，再用最先的開發模式，已經徹底知足不了如今時代的需求了；

因此就nosql（非關係型數據庫）橫空出世，來解決大數據量狀況下提升數據庫讀取效率，從而提高系統性能以及客戶體驗；

在早期的系統，dao層直接訪問數據庫獲取數據，可是如今時代的變遷，這樣的方式在數據量大的狀況下，效率很是很是的查，你不管怎麼優化都是徒勞；

nosql出現後，猶如在數據庫前面加了一堵牆，dao層先訪問Redis，Redis再訪問數據庫；

數據庫讀出來的數據先存入Redis，獲取數據的時候，直接從Redis中獲取便可，不用再經過數據庫從內存中讀寫；

今天咱們能夠經過第三方平臺（如：Google,Facebook等）能夠很容易的訪問和抓取數據，用戶的我的信息，社交網絡，地理位置，用戶產生的數據和用戶操做日誌以及成倍的增長；

咱們若是要對這些用戶數據進行挖掘，MySQL數據庫以及不合適這些應用了，NoSQL數據庫發展卻能很好的出列這些大數據；

單機MySQL的美好年代

在最先的javaweb開發應用程序中，無非就是JSP跳JSP，一個JSP處理用戶而且響應，另一個JSP發出請求，請求別的JSP，再日後，JSP跳Serclet，Serclet掉業務邏輯層的方法，業務邏輯掉數據訪問層，數據訪問層去請求數據庫發起事物；

在90年代，一個網站的訪問量都不大，用單個數據庫徹底能夠輕鬆應付；

在那個時候，更多的都是靜態網頁，動態交互類型的網站很少；

在那個時候程序的劃分也很是簡單：

 

隨着時代的變遷，數據的總量總有一天會撐破這個機器，數據庫讀取也就是查詢效率講會變得很是很是低；

創建索引也是會佔用磁盤空間的，數據量越大，你索引越多，時間久了機器就是受不了你這樣折騰了；

還有一個訪問量（讀寫混合）一個數據庫是受不了的，你讀取跟插入數據都是在同一個數據庫，這樣數據庫也是承受不了的（數據量大的狀況下）；

因此，問題已經列出來了，咱們就要解決，要去優化這些問題，提升性能；

在以上這種開發模式，數據量在小於1w是能夠知足的，本身用用，或訪問量不大的狀況下是沒有問題的，本身作練習什麼的均可以，可是進入企業，就不能夠再這麼用了；

Redis（緩存）+MySQL+垂直拆分

隨着數據量大，讀寫都是在同一臺機器上，扛不住了之後呢，項目架構也就進行了改變：

跟上一張圖標對比，是隻有一個MySQL數據庫，而且如今咱們還在MySQL前面檔了一層Cache（這裏理解成Redis【緩存】）,換句話說，以前是DAO層直接去訪問數據庫，如今DAO層直接去Redis裏面；

是否是有點像替數據庫擋了一層，你們都指定，對數據庫傷害比較大的就是頻繁的查詢，若是頻繁查詢的恰好仍是一些固定的順序，咱們是否是能夠把他摘出來放到緩存裏面（Redis）；

mysql還有一個垂直拆分，言下之意就是，你一個數據裝不住了，你拆開了之後，例如，買家跟賣家被分紅兩個庫，這樣的話，數據庫的壓力就被分擔了一些；

MySQL主從讀寫分離

舉個例子，如今是一臺機器一個數據庫，我如今要求一臺機器變成五個數據庫，那麼，其中的一臺數據庫做爲主庫，另外四臺做爲從庫，我插入一條數據是給主庫，主庫這個時候須要同步另外四個從庫，好比我主庫裏面有 a b c，這個時候我向裏面查一個d，這個時候主庫就須要向另外四個從庫也添加一個d來保持同步；

也能夠理解爲主從複製，主表裏面有什麼東西，我從表須要迅速的複製粘貼進來；

讀寫分離，顧名思義，讀就是查詢，寫就是增 刪 改，在咱們本身作練習的時候，增刪改查一直都是同一臺機器或同一個數據庫，可是在實際開發當中，這種狀況是不容許的，由於很是影響效率；

因此又有一個數據庫是隻作查詢，另一個數據庫是隻作增 刪 改，這就是讀寫分離，因此就形成了下面這張圖：

因爲數據庫的寫入壓力增長，Redis只能緩解數據庫的讀取壓力，讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從賦值技術來達到讀寫分離，提升讀寫性能和讀庫的可擴展性；

以前是光在mysql前面檔了一個緩存，如今，在緩存背後又出現了數據庫的拆分，變成了讀寫分離了，M表明主表，S表明從表；

什麼概念呢？

就是，對於一個數據庫的信息，寫的操做都放到M（主）庫了，讀的操做都去從庫去度，這樣的話，存載的數據被分割之後，就能夠大大的緩解數據庫的壓力；

分庫分表+水平拆分+mysql集羣

通過前幾回的拆分，改變，讀寫分離，日後發現又扛不住了，這個時候，集羣就出來了；

在Redis的高速緩存，MySQL的主從複製，讀寫分離的基礎上，這時，MySQL主庫的讀寫壓力開始出現瓶頸，而數據量的持續猛增，因爲MyISAM使用表鎖，在高併發下會出現嚴重的鎖問題，大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM；

同時，開始流行使用分表分庫來緩解寫壓力和數據庫增加的擴展問題，這個時候，分表分庫就成了一個熱門的技術，是面試的熱門問題也是業界討論的熱門技術問題；

也就是在這個時候MySQL推出了還不太穩定的表分區，這也給技術實力通常的公司帶來了但願，雖然MySQL推出MySQL Cluster集羣，但性能也不能很好知足互聯網的需求，只是在高可靠性上提供很是大的保障；

咱們能夠發現，以上圖就用了數據庫的集羣，三個數據庫各司其職，每一個數據庫存放的是整個項目數據的3分之1，頻繁查詢的數據庫單獨列出一個庫，常常不用的數據也獨立出來放在一個數據庫中；

現在的項目結構

首先，三個藍色的小人人就點客戶，經過企業防火牆Linux，日後就是負載均衡的主備Nginx，作這個負載均衡、反向代理的一個；

因此說在真正的項目研發的時候，你是不可能先通過服務器的，而是先通過Nginx；

後面就是一大堆應用服務器的集羣，也能夠理解爲tomcat的集羣，一隻貓帶不動這個項目，那麼就一羣貓來帶，這樣就實現了高可用，負載均衡以及服務器的集羣；

再日後，就是數據庫的集羣了；

今日感悟：

當一我的能夠輕鬆作一件事情的時候，你本身也這麼認爲本身也能夠；

那麼你就大錯特錯了