當(dāng)為大家描述我們的整體服務(wù)架構(gòu)時(shí)，最常見(jiàn)的兩個(gè)問(wèn)題是：
網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、微信小程序定制開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了慶元免費(fèi)建站歡迎大家使用！
為什么采用結(jié)構(gòu)化方式將數(shù)據(jù)存儲(chǔ)在SQL數(shù)據(jù)庫(kù)中，而不使用NoSQL平臺(tái)？
為什么自己維護(hù)數(shù)據(jù)中心，而不將Evernote托管到云服務(wù)提供商？
這兩個(gè)問(wèn)題都很有趣，我們先來(lái)探討第一個(gè)。
對(duì)特定的應(yīng)用而言，相比一個(gè)單一的SQL實(shí)例，一個(gè)現(xiàn)代的鍵值存儲(chǔ)引擎具備顯著的性能優(yōu)勢(shì)和可擴(kuò)展性。
CREATE TABLE notebooks ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, name varchar(100) COLLATE utf8_bin NOT NULL, ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE notes ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, notebook_id int UNSIGNED NOT NULL, title varchar(255) NOT NULL, ... FOREIGN KEY (notebook_id) REFERENCES notebooks(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
如果你在Windows客戶端上創(chuàng)建了一個(gè)名為“Cooking”的記事本，并立即在其中粘貼了一個(gè)名為“Quick Tomato Sauce”的食譜，客戶端會(huì)立刻進(jìn)行如下同步：
調(diào)用NoteStore.createNotebook() 請(qǐng)求服務(wù)器創(chuàng)建記事本，并返回以創(chuàng)建記事本的GUID。
通過(guò)指定記事本的GUID，調(diào)用NoteStore.createNote()在記事本中創(chuàng)建筆記。
每次API調(diào)用都通過(guò)SQL事物予以實(shí)現(xiàn)，可以讓客戶端完全信任服務(wù)器的任何提示。ACID兼容的數(shù)據(jù)庫(kù)可以做到這些：
原子性（Atomicity）：如果API調(diào)用成功，那么所有的改動(dòng)都會(huì)保存；如果API調(diào)用失敗，所有的改動(dòng)都不會(huì)提交。
一致性（Consistency）： 在API調(diào)用完成后，所有的賬戶都可用，并能保證內(nèi)部狀態(tài)的一致性。每篇筆記都與記事本相關(guān)聯(lián)，以避免出現(xiàn)孤立項(xiàng)。數(shù)據(jù)庫(kù)不允許刪除關(guān)聯(lián)有記事的記事本，這得感謝FOREIGN KEY約束。
持久性（Durability）：當(dāng)服務(wù)器發(fā)送記事本已創(chuàng)建完畢的回執(zhí)后，客戶端會(huì)認(rèn)為它的存在具有持久性，以便進(jìn)行后續(xù)的操作。變更的持久性，可以讓客戶端知道在任何時(shí)刻對(duì)服務(wù)狀態(tài)的影響都能保持一致性。
對(duì)我們的同步協(xié)議而言，持久性最為重要。如果客戶端不能確定服務(wù)器端的變更具有持久性，那么協(xié)議將會(huì)變得復(fù)雜而低效。
“大數(shù)據(jù)”問(wèn)題
得益于事務(wù)處理的數(shù)據(jù)庫(kù)的ACID屬性，同樣使得數(shù)據(jù)集非常難以擴(kuò)展，以超出單臺(tái)服務(wù)器的范圍。數(shù)據(jù)庫(kù)集群和多主復(fù)制技術(shù)并不理想，鍵值存儲(chǔ)為實(shí)現(xiàn)可擴(kuò)展性提供了一條捷徑。
所幸，Evernote暫時(shí)不需要考慮這個(gè)問(wèn)題。即便是我們有近10億的筆記，和近20億的資源文件，這也并不能稱得上是一個(gè)大數(shù)據(jù)集。通過(guò)按用戶分區(qū)，它被劃分成了2千萬(wàn)個(gè)獨(dú)立的數(shù)據(jù)集。
我們尚未遇到所謂“大數(shù)據(jù)”引發(fā)的問(wèn)題，倒是遇到了許多“中數(shù)據(jù)”的存儲(chǔ)問(wèn)題，這就是通過(guò)規(guī)整分區(qū)形成的分片存儲(chǔ)架構(gòu)。
也許以后……
我們對(duì)新的存儲(chǔ)系統(tǒng)非常感興趣，非常樂(lè)意應(yīng)用在哪些對(duì)ACID要求不強(qiáng)，但確實(shí)需要橫向擴(kuò)展的新項(xiàng)目中。例如，我們的報(bào)告分析系統(tǒng)已經(jīng)逐漸超出了MySQL平臺(tái)的承受力，需要被更快、更先進(jìn)的系統(tǒng)所取代。
我們現(xiàn)在對(duì)以Evernote用戶元數(shù)據(jù)為基礎(chǔ)的MySQL分片存儲(chǔ)頗為滿意，盡管這不會(huì)引起那些IT弄潮兒的興趣。
NoSQL，指的是非關(guān)系型的數(shù)據(jù)庫(kù)。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的
SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問(wèn)題，而非關(guān)系型的數(shù)據(jù)庫(kù)則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。
NoSQL(NoSQL
= Not Only SQL
)，意即“不僅僅是SQL”，是一項(xiàng)全新的數(shù)據(jù)庫(kù)革命性運(yùn)動(dòng)，早期就有人提出，發(fā)展至2009年趨勢(shì)越發(fā)高漲。NoSQL的擁護(hù)者們提倡運(yùn)用非關(guān)系型的數(shù)
據(jù)存儲(chǔ)，相對(duì)于鋪天蓋地的關(guān)系型數(shù)據(jù)庫(kù)運(yùn)用，這一概念無(wú)疑是一種全新的思維的注入。
從這一新興技術(shù)中選擇一款正確的NoSQL數(shù)據(jù)庫(kù)是非常具有挑戰(zhàn)性的。比一下網(wǎng)建議在選擇時(shí)考慮以下因素：
并發(fā)控制
并
發(fā)控制指的是當(dāng)多個(gè)用戶同時(shí)更新運(yùn)行時(shí)，用于保護(hù)數(shù)據(jù)庫(kù)完整性的各種技術(shù)。并發(fā)機(jī)制不正確可能導(dǎo)致臟讀、幻讀和不可重復(fù)讀等此類問(wèn)題。并發(fā)控制的目的是保
證一個(gè)用戶的工作不會(huì)對(duì)另一個(gè)用戶的工作產(chǎn)生不合理的影響。在某些情況下，這些措施保證了當(dāng)用戶和其他用戶一起操作時(shí)，所得的結(jié)果和她單獨(dú)操作時(shí)的結(jié)果是
一樣的。在另一些情況下，這表示用戶的工作按預(yù)定的方式受其他用戶的影響。
封鎖
就是事務(wù)T在對(duì)某個(gè)數(shù)據(jù)對(duì)象（例如表、記錄等）操作之前，先向系統(tǒng)發(fā)出請(qǐng)求，對(duì)其加鎖。加鎖后事務(wù)T就對(duì)該數(shù)據(jù)對(duì)象有了一定的控制，在事務(wù)T釋放它的鎖之前，其它的事務(wù)不能更新此數(shù)據(jù)對(duì)象。
封鎖是一次只允許一個(gè)用戶讀取或修改的一種機(jī)制，是實(shí)現(xiàn)并發(fā)控制的一個(gè)非常重要的技術(shù)。
MVCC
Multi-Version Concurrency Control多版本并發(fā)控制，維持一個(gè)數(shù)據(jù)的多個(gè)版本使讀寫(xiě)操作沒(méi)有沖突。MVCC優(yōu)化了數(shù)據(jù)庫(kù)并發(fā)系統(tǒng)，使系統(tǒng)在有大量并發(fā)用戶時(shí)得到最高的性能，并且可以不用關(guān)閉服務(wù)器就直接進(jìn)行熱備份。
ACID
指
數(shù)據(jù)庫(kù)事務(wù)正確執(zhí)行的四個(gè)基本要素的縮寫(xiě)。包含：原子性(Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久
性（Durability）。一個(gè)支持事務(wù)（Transaction）的數(shù)據(jù)庫(kù)系統(tǒng)，必需要具有這四種特性，否則在事務(wù)過(guò)程（Transaction
processing）當(dāng)中無(wú)法保證數(shù)據(jù)的正確性，交易過(guò)程極可能達(dá)不到交易方的要求。
None
一些系統(tǒng)不提供原子性。
鏡像
數(shù)據(jù)庫(kù)鏡像是DBMS根據(jù)DBA的要求，自動(dòng)把整個(gè)數(shù)據(jù)庫(kù)或其中的關(guān)鍵數(shù)據(jù)復(fù)制到另一個(gè)磁盤(pán)上，每當(dāng)主數(shù)據(jù)庫(kù)更新時(shí)，DBMS會(huì)自動(dòng)把更新后的數(shù)據(jù)復(fù)制過(guò)去，即DBMS自動(dòng)保證鏡像數(shù)據(jù)與主數(shù)據(jù)的一致性。
鏡像分為同步和異步。
數(shù)據(jù)存儲(chǔ)
指的是數(shù)據(jù)的物理特性怎樣被存儲(chǔ)在數(shù)據(jù)庫(kù)中。
磁盤(pán) 數(shù)據(jù)被存儲(chǔ)在硬盤(pán)驅(qū)動(dòng)器里；
GFS或谷歌文件系統(tǒng)是一個(gè)由谷歌開(kāi)發(fā)的專有的分布式文件系統(tǒng)；
Hadoop是Apache軟件框架，免費(fèi)許可下支持?jǐn)?shù)據(jù)密集型分布式應(yīng)用程序；
RAM隨機(jī)存儲(chǔ)器；
插件 可以添加外部插件；
Amazon S3通過(guò)Web服務(wù)接口提供存儲(chǔ)；
BDB：BDB
全稱是 “Berkeley DB”，它是MySQL具有事務(wù)能力的表類型，由Sleepycat
Software開(kāi)發(fā)。BDB表類型提供了MySQL用戶長(zhǎng)久期盼的功能，即事務(wù)控制能力。在任何RDBMS中，事務(wù)控制能力都是一種極其重要和寶貴的功
能。事務(wù)控制能力使得我們能夠確保一組命令確實(shí)已經(jīng)全部執(zhí)行成功，或者確保當(dāng)任何一個(gè)命令出現(xiàn)錯(cuò)誤時(shí)所有命令的執(zhí)行結(jié)果均被退回。
實(shí)現(xiàn)語(yǔ)言
實(shí)現(xiàn)語(yǔ)言會(huì)影響數(shù)據(jù)庫(kù)的發(fā)展速度。典型的NoSQL數(shù)據(jù)庫(kù)是用低級(jí)語(yǔ)言如C / C + +編寫(xiě)的。另一方面，那些更高層次的語(yǔ)言如Java，使自定義更容易。
實(shí)現(xiàn)語(yǔ)言有：C, C++, Erlang, Java, Python
特性
考慮下列哪一個(gè)特點(diǎn)對(duì)你的數(shù)據(jù)庫(kù)是最重要的：
持久性
可用性
一致性
分區(qū)容忍性
證書(shū)類型
下面這些許可證是一個(gè)不同的開(kāi)放源碼許可的形式：
GPL：通用公共許可證
BSD：伯克利軟件分發(fā)
MPL：Mozilla公共許可證
EPL：Eclipse公共許可證
IDPL：最初的開(kāi)發(fā)者的公共許可證
LGPL：較寬松通用公共許可證
存儲(chǔ)類型
存儲(chǔ)類型是NoSQL數(shù)據(jù)庫(kù)最大的不同，是決定使用哪款數(shù)據(jù)庫(kù)的一個(gè)首要指標(biāo)。
關(guān)鍵字：支持get、put和刪除操作
按列存儲(chǔ)：相對(duì)于傳統(tǒng)的按行存儲(chǔ)，數(shù)據(jù)集成容易多了
面向文件系統(tǒng)：存儲(chǔ)像是JSON或XML這樣的結(jié)構(gòu)化文件，很容易就能從面向?qū)ο筌浖蝎@取數(shù)據(jù)。
Hadoop
文件系統(tǒng)：文件系統(tǒng)是用來(lái)存儲(chǔ)和管理文件，并且提供文件的查詢、增加、刪除等操作。
直觀上的體驗(yàn)：在shell窗口輸入 ls 命令，就可以看到當(dāng)前目錄下的文件夾、文件。
文件存儲(chǔ)在哪里？硬盤(pán)
一臺(tái)只有250G硬盤(pán)的電腦，如果需要存儲(chǔ)500G的文件可以怎么辦？先將電腦硬盤(pán)擴(kuò)容至少250G，再將文件分割成多塊，放到多塊硬盤(pán)上儲(chǔ)存。
通過(guò) hdfs dfs -ls 命令可以查看分布式文件系統(tǒng)中的文件，就像本地的ls命令一樣。
HDFS在客戶端上提供了查詢、新增和刪除的指令，可以實(shí)現(xiàn)將分布在多臺(tái)機(jī)器上的文件系統(tǒng)進(jìn)行統(tǒng)一的管理。
在分布式文件系統(tǒng)中，一個(gè)大文件會(huì)被切分成塊，分別存儲(chǔ)到幾臺(tái)機(jī)器上。結(jié)合上文中提到的那個(gè)存儲(chǔ)500G大文件的那個(gè)例子，這500G的文件會(huì)按照一定的大小被切分成若干塊，然后分別存儲(chǔ)在若干臺(tái)機(jī)器上，然后提供統(tǒng)一的操作接口。
看到這里，不少人可能會(huì)覺(jué)得，分布式文件系統(tǒng)不過(guò)如此，很簡(jiǎn)單嘛。事實(shí)真的是這樣的么？
潛在問(wèn)題
假如我有一個(gè)1000臺(tái)機(jī)器組成的分布式系統(tǒng)，一臺(tái)機(jī)器每天出現(xiàn)故障的概率是0.1%，那么整個(gè)系統(tǒng)每天出現(xiàn)故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一個(gè)容錯(cuò)機(jī)制來(lái)保證發(fā)生差錯(cuò)時(shí)文件依然可以讀出，這里暫時(shí)先不展開(kāi)介紹。
如果要存儲(chǔ)PB級(jí)或者EB級(jí)的數(shù)據(jù)，成千上萬(wàn)臺(tái)機(jī)器組成的集群是很常見(jiàn)的，所以說(shuō)分布式系統(tǒng)比單機(jī)系統(tǒng)要復(fù)雜得多呀。
這是一張HDFS的架構(gòu)簡(jiǎn)圖：
client通過(guò)nameNode了解數(shù)據(jù)在哪些DataNode上，從而發(fā)起查詢。此外，不僅是查詢文件，寫(xiě)入文件的時(shí)候也是先去請(qǐng)教N(yùn)ameNode，看看應(yīng)該往哪個(gè)DateNode中去寫(xiě)。
為了某一份數(shù)據(jù)只寫(xiě)入到一個(gè)Datanode中，而這個(gè)Datanode因?yàn)槟承┰虺鲥e(cuò)無(wú)法讀取的問(wèn)題，需要通過(guò)冗余備份的方式來(lái)進(jìn)行容錯(cuò)處理。因此，HDFS在寫(xiě)入一個(gè)數(shù)據(jù)塊的時(shí)候，不會(huì)僅僅寫(xiě)入一個(gè)DataNode，而是會(huì)寫(xiě)入到多個(gè)DataNode中，這樣，如果其中一個(gè)DataNode壞了，還可以從其余的DataNode中拿到數(shù)據(jù)，保證了數(shù)據(jù)不丟失。
實(shí)際上，每個(gè)數(shù)據(jù)塊在HDFS上都會(huì)保存多份，保存在不同的DataNode上。這種是犧牲一定存儲(chǔ)空間換取可靠性的做法。
接下來(lái)我們來(lái)看一下完整的文件寫(xiě)入的流程：
大文件要寫(xiě)入HDFS，client端根據(jù)配置將大文件分成固定大小的塊，然后再上傳到HDFS。
讀取文件的流程：
1、client詢問(wèn)NameNode，我要讀取某個(gè)路徑下的文件，麻煩告訴我這個(gè)文件都在哪些DataNode上？
2、NameNode回復(fù)client，這個(gè)路徑下的文件被切成了3塊，分別在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4，拿到3個(gè)文件塊，通過(guò)stream讀取并且整合起來(lái)
文件寫(xiě)入的流程：
1、client先將文件分塊，然后詢問(wèn)NameNode，我要寫(xiě)入一個(gè)文件到某個(gè)路徑下，文件有3塊，應(yīng)該怎么寫(xiě)？
2、NameNode回復(fù)client，可以分別寫(xiě)到DataNode1、DataNode2、DataNode3、DataNode4上，記住，每個(gè)塊重復(fù)寫(xiě)3份，總共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把數(shù)據(jù)寫(xiě)到他們上面
出于容錯(cuò)的考慮，每個(gè)數(shù)據(jù)塊有3個(gè)備份，但是3個(gè)備份快都直接由client端直接寫(xiě)入勢(shì)必會(huì)帶來(lái)client端過(guò)重的寫(xiě)入壓力，這個(gè)點(diǎn)是否有更好的解決方案呢？回憶一下mysql主備之間是通過(guò)binlog文件進(jìn)行同步的，HDFS當(dāng)然也可以借鑒這個(gè)思想，數(shù)據(jù)其實(shí)只需要寫(xiě)入到一個(gè)datanode上，然后由datanode之間相互進(jìn)行備份同步，減少了client端的寫(xiě)入壓力，那么至于是一個(gè)datanode寫(xiě)入成功即成功，還是需要所有的參與備份的datanode返回寫(xiě)入成功才算成功，是可靠性配置的策略，當(dāng)然這個(gè)設(shè)置會(huì)影響到數(shù)據(jù)寫(xiě)入的吞吐率，我們可以看到可靠性和效率永遠(yuǎn)是“魚(yú)和熊掌不可兼得”的。
潛在問(wèn)題
NameNode確實(shí)會(huì)回放editlog，但是不是每次都從頭回放，它會(huì)先加載一個(gè)fsimage，這個(gè)文件是之前某一個(gè)時(shí)刻整個(gè)NameNode的文件元數(shù)據(jù)的內(nèi)存快照，然后再在這個(gè)基礎(chǔ)上回放editlog，完成后，會(huì)清空editlog，再把當(dāng)前文件元數(shù)據(jù)的內(nèi)存狀態(tài)寫(xiě)入fsimage，方便下一次加載。
這樣，全量回放就變成了增量回放，但是如果NameNode長(zhǎng)時(shí)間未重啟過(guò)，editlog依然會(huì)比較大，恢復(fù)的時(shí)間依然比較長(zhǎng)，這個(gè)問(wèn)題怎么解呢？
SecondNameNode是一個(gè)NameNode內(nèi)的定時(shí)任務(wù)線程，它會(huì)定期地將editlog寫(xiě)入fsimage，然后情況原來(lái)的editlog，從而保證editlog的文件大小維持在一定大小。
NameNode掛了， SecondNameNode并不能替代NameNode，所以如果集群中只有一個(gè)NameNode，它掛了，整個(gè)系統(tǒng)就掛了。hadoop2.x之前，整個(gè)集群只能有一個(gè)NameNode，是有可能發(fā)生單點(diǎn)故障的，所以hadoop1.x有本身的不穩(wěn)定性。但是hadoop2.x之后，我們可以在集群中配置多個(gè)NameNode，就不會(huì)有這個(gè)問(wèn)題了，但是配置多個(gè)NameNode，需要注意的地方就更多了，系統(tǒng)就更加復(fù)雜了。
俗話說(shuō)“一山不容二虎”，兩個(gè)NameNode只能有一個(gè)是活躍狀態(tài)active，另一個(gè)是備份狀態(tài)standby，我們看一下兩個(gè)NameNode的架構(gòu)圖。
兩個(gè)NameNode通過(guò)JournalNode實(shí)現(xiàn)同步editlog，保持狀態(tài)一致可以相互替換。
因?yàn)閍ctive的NameNode掛了之后，standby的NameNode要馬上接替它，所以它們的數(shù)據(jù)要時(shí)刻保持一致，在寫(xiě)入數(shù)據(jù)的時(shí)候，兩個(gè)NameNode內(nèi)存中都要記錄數(shù)據(jù)的元信息，并保持一致。這個(gè)JournalNode就是用來(lái)在兩個(gè)NameNode中同步數(shù)據(jù)的，并且standby NameNode實(shí)現(xiàn)了SecondNameNode的功能。
進(jìn)行數(shù)據(jù)同步操作的過(guò)程如下：
active NameNode有操作之后，它的editlog會(huì)被記錄到JournalNode中，standby NameNode會(huì)從JournalNode中讀取到變化并進(jìn)行同步，同時(shí)standby NameNode會(huì)監(jiān)聽(tīng)記錄的變化。這樣做的話就是實(shí)時(shí)同步了，并且standby NameNode就實(shí)現(xiàn)了SecondNameNode的功能。
優(yōu)點(diǎn)：
缺點(diǎn)：
2. 什么是NoSQL？
2.1 NoSQL 概述
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，
泛指非關(guān)系型的數(shù)據(jù)庫(kù)。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問(wèn)題，而非關(guān)系型的數(shù)據(jù)庫(kù)則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫(kù)的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來(lái)的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題，包括超大規(guī)模數(shù)據(jù)的存儲(chǔ)。
（例如谷歌或Facebook每天為他們的用戶收集萬(wàn)億比特的數(shù)據(jù)）。這些類型的數(shù)據(jù)存儲(chǔ)不需要固定的模式，無(wú)需多余操作就可以橫向擴(kuò)展。
2.2 NoSQL代表
MongDB、 Redis、Memcache
3. 關(guān)系型數(shù)據(jù)庫(kù)與NoSQL的區(qū)別？
3.1 RDBMS
高度組織化結(jié)構(gòu)化數(shù)據(jù)
結(jié)構(gòu)化查詢語(yǔ)言（SQL）
數(shù)據(jù)和關(guān)系都存儲(chǔ)在單獨(dú)的表中。
數(shù)據(jù)操縱語(yǔ)言，數(shù)據(jù)定義語(yǔ)言
嚴(yán)格的一致性
基礎(chǔ)事務(wù)
ACID
關(guān)系型數(shù)據(jù)庫(kù)遵循ACID規(guī)則
事務(wù)在英文中是transaction，和現(xiàn)實(shí)世界中的交易很類似，它有如下四個(gè)特性：
A (Atomicity) 原子性
原子性很容易理解，也就是說(shuō)事務(wù)里的所有操作要么全部做完，要么都不做，事務(wù)成功的條件是事務(wù)里的所有操作都成功，只要有一個(gè)操作失敗，整個(gè)事務(wù)就失敗，需要回滾。比如銀行轉(zhuǎn)賬，從A賬戶轉(zhuǎn)100元至B賬戶，分為兩個(gè)步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢(qián)會(huì)莫名其妙少了100元。
C (Consistency) 一致性
一致性也比較容易理解，也就是說(shuō)數(shù)據(jù)庫(kù)要一直處于一致的狀態(tài)，事務(wù)的運(yùn)行不會(huì)改變數(shù)據(jù)庫(kù)原本的一致性約束。
I (Isolation) 獨(dú)立性
所謂的獨(dú)立性是指并發(fā)的事務(wù)之間不會(huì)互相影響，如果一個(gè)事務(wù)要訪問(wèn)的數(shù)據(jù)正在被另外一個(gè)事務(wù)修改，只要另外一個(gè)事務(wù)未提交，它所訪問(wèn)的數(shù)據(jù)就不受未提交事務(wù)的影響。比如現(xiàn)有有個(gè)交易是從A賬戶轉(zhuǎn)100元至B賬戶，在這個(gè)交易還未完成的情況下，如果此時(shí)B查詢自己的賬戶，是看不到新增加的100元的
D (Durability) 持久性
持久性是指一旦事務(wù)提交后，它所做的修改將會(huì)永久的保存在數(shù)據(jù)庫(kù)上，即使出現(xiàn)宕機(jī)也不會(huì)丟失。
3.2 NoSQL
代表著不僅僅是SQL
沒(méi)有聲明性查詢語(yǔ)言
沒(méi)有預(yù)定義的模式
鍵 - 值對(duì)存儲(chǔ)，列存儲(chǔ)，文檔存儲(chǔ)，圖形數(shù)據(jù)庫(kù)
最終一致性，而非ACID屬性
非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)
CAP定理
高性能，高可用性和可伸縮性
分布式數(shù)據(jù)庫(kù)中的CAP原理(了解)
CAP定理：
Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動(dòng)都是同步的
Availability(可用性), 好的響應(yīng)性能
Partition tolerance(分區(qū)容錯(cuò)性) 可靠性
P: 系統(tǒng)中任意信息的丟失或失敗不會(huì)影響系統(tǒng)的繼續(xù)運(yùn)作。
定理：任何分布式系統(tǒng)只可同時(shí)滿足二點(diǎn)，沒(méi)法三者兼顧。
CAP理論的核心是：一個(gè)分布式系統(tǒng)不可能同時(shí)很好的滿足一致性，可用性和分區(qū)容錯(cuò)性這三個(gè)需求，
因此，根據(jù) CAP 原理將 NoSQL 數(shù)據(jù)庫(kù)分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：
CA - 單點(diǎn)集群，滿足一致性，可用性的系統(tǒng)，通常在可擴(kuò)展性上不太強(qiáng)大。
CP - 滿足一致性，分區(qū)容忍性的系統(tǒng)，通常性能不是特別高。
AP - 滿足可用性，分區(qū)容忍性的系統(tǒng)，通常可能對(duì)一致性要求低一些。
CAP理論就是說(shuō)在分布式存儲(chǔ)系統(tǒng)中，最多只能實(shí)現(xiàn)上面的兩點(diǎn)。
而由于當(dāng)前的網(wǎng)絡(luò)硬件肯定會(huì)出現(xiàn)延遲丟包等問(wèn)題，所以分區(qū)容忍性是我們必須需要實(shí)現(xiàn)的。
所以我們只能在一致性和可用性之間進(jìn)行權(quán)衡，沒(méi)有NoSQL系統(tǒng)能同時(shí)保證這三點(diǎn)。
說(shuō)明：C：強(qiáng)一致性 A：高可用性 P：分布式容忍性
舉例：
CA：傳統(tǒng)Oracle數(shù)據(jù)庫(kù)
AP：大多數(shù)網(wǎng)站架構(gòu)的選擇
CP：Redis、Mongodb
注意：分布式架構(gòu)的時(shí)候必須做出取舍。
一致性和可用性之間取一個(gè)平衡。多余大多數(shù)web應(yīng)用，其實(shí)并不需要強(qiáng)一致性。
因此犧牲C換取P，這是目前分布式數(shù)據(jù)庫(kù)產(chǎn)品的方向。
4. 當(dāng)下NoSQL的經(jīng)典應(yīng)用
當(dāng)下的應(yīng)用是 SQL 與 NoSQL 一起使用的。
代表項(xiàng)目：阿里巴巴商品信息的存放。
去 IOE 化。
ps：I 是指 IBM 的小型機(jī)，很貴的，好像好幾萬(wàn)一臺(tái)；O 是指 Oracle 數(shù)據(jù)庫(kù)，也很貴的，好幾萬(wàn)呢；M 是指 EMC 的存儲(chǔ)設(shè)備，也很貴的。
難點(diǎn)：
數(shù)據(jù)類型多樣性。
數(shù)據(jù)源多樣性和變化重構(gòu)。
數(shù)據(jù)源改造而服務(wù)平臺(tái)不需要大面積重構(gòu)。
elasticsearch是分布式的搜索系統(tǒng)（全文搜索），
NoSQL非關(guān)系型數(shù)據(jù)庫(kù)，主要用在大數(shù)據(jù)量，高并發(fā)情景下（非事務(wù)）
分布式緩存主要用于在高并發(fā)環(huán)境下，減輕數(shù)據(jù)庫(kù)的壓力，提高系統(tǒng)的響應(yīng)速度和并發(fā)吞吐。當(dāng)大量的讀、寫(xiě)請(qǐng)求涌向數(shù)據(jù)庫(kù)時(shí)，磁盤(pán)的處理速度與內(nèi)存顯然不在一個(gè)量級(jí)，因此，在數(shù)據(jù)庫(kù)之前加一層緩存，能夠顯著提高系統(tǒng)的響應(yīng)速度，并降低數(shù)據(jù)庫(kù)的壓力。作為傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)，MySQL提供完整的ACID操作，支持豐富的數(shù)據(jù)類型、強(qiáng)大的關(guān)聯(lián)查詢、where語(yǔ)句等，能夠非?？鸵椎亟⒉樵兯饕?，執(zhí)行復(fù)雜的內(nèi)連接、外連接、求和、排序、分組等操作，并且支持存儲(chǔ)過(guò)程、函數(shù)等功能，產(chǎn)品成熟度高，功能強(qiáng)大。但是，對(duì)于需要應(yīng)對(duì)高并發(fā)訪問(wèn)并且存儲(chǔ)海量數(shù)據(jù)的場(chǎng)景來(lái)說(shuō)，出于對(duì)性能的考慮，不得不放棄很多傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)原本強(qiáng)大的功能，犧牲了系統(tǒng)的易用性，并且使得系統(tǒng)的設(shè)計(jì)和管理變得更為復(fù)雜。這也使得在過(guò)去幾年中，流行著另一種新的存儲(chǔ)解決方案——NoSQL，它與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)最大的差別在于，它不使用SQL作為查詢語(yǔ)言來(lái)查找數(shù)據(jù)，而采用key-value形式進(jìn)行查找，提供了更高的查詢效率及吞吐，并且能夠更加方便地進(jìn)行擴(kuò)展，存儲(chǔ)海量數(shù)據(jù)，在數(shù)千個(gè)節(jié)點(diǎn)上進(jìn)行分區(qū)，自動(dòng)進(jìn)行數(shù)據(jù)的復(fù)制和備份。在分布式系統(tǒng)中，消息作為應(yīng)用間通信的一種方式，得到了十分廣泛的應(yīng)用。消息可以被保存在隊(duì)列中，直到被接收者取出，由于消息發(fā)送者不需要同步等待消息接收者的響應(yīng)，消息的異步接收降低了系統(tǒng)集成的耦合度，提升了分布式系統(tǒng)協(xié)作的效率，使得系統(tǒng)能夠更快地響應(yīng)用戶，提供更高的吞吐。
當(dāng)系統(tǒng)處于峰值壓力時(shí)，分布式消息隊(duì)列還能夠作為緩沖，削峰填谷，緩解集群的壓力，避免整個(gè)系統(tǒng)被壓垮。垂直化的搜索引擎在分布式系統(tǒng)中是一個(gè)非常重要的角色，它既能夠滿足用戶對(duì)于全文檢索、模糊匹配的需求，解決數(shù)據(jù)庫(kù)like查詢效率低下的問(wèn)題，又能夠解決分布式環(huán)境下，由于采用分庫(kù)分表，或者使用NoSQL數(shù)據(jù)庫(kù)，導(dǎo)致無(wú)法進(jìn)行多表關(guān)聯(lián)或者進(jìn)行復(fù)雜查詢的問(wèn)題。
重慶分公司
重慶分公司
