什么是New SQL?分析NewSQL是如何融合NoSQL和RDBMS兩者的優(yōu)勢(shì)

NewSQL是對(duì)一類現(xiàn)代關(guān)系型數(shù)據(jù)庫(kù)的統(tǒng)稱，這類數(shù)據(jù)庫(kù)對(duì)于一般的OLTP讀寫請(qǐng)求提供可橫向擴(kuò)展的性能，同時(shí)支持事務(wù)的ACID保證。這些系統(tǒng)既擁有NoSQL數(shù)據(jù)庫(kù)的擴(kuò)展性，又保持傳統(tǒng)數(shù)據(jù)庫(kù)的事務(wù)特性。NewSQL重新將“應(yīng)用程序邏輯與數(shù)據(jù)操作邏輯應(yīng)該分離”的理念帶回到現(xiàn)代數(shù)據(jù)庫(kù)的世界，這也驗(yàn)證了歷史的發(fā)展總是呈現(xiàn)出螺旋上升的形式。

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供天祝藏族自治網(wǎng)站建設(shè)、天祝藏族自治做網(wǎng)站、天祝藏族自治網(wǎng)站設(shè)計(jì)、天祝藏族自治網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)與制作、天祝藏族自治企業(yè)網(wǎng)站模板建站服務(wù)，十年天祝藏族自治做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。

在21世紀(jì)00年代中，出現(xiàn)了許多數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng) (如 Vertica，Greeplum 和AsterData)，這些以處理OLAP 請(qǐng)求為設(shè)計(jì)目標(biāo)的系統(tǒng)并不在本文定義的NewSQL范圍內(nèi)。OLAP 數(shù)據(jù)庫(kù)更關(guān)注針對(duì)海量數(shù)據(jù)的大型、復(fù)雜、只讀的查詢，查詢時(shí)間可能持續(xù)秒級(jí)、分鐘級(jí)甚至更長(zhǎng)。

NoSQL的擁躉普遍認(rèn)為阻礙傳統(tǒng)數(shù)據(jù)庫(kù)橫向擴(kuò)容、提高可用性的原因在于ACID保證和關(guān)系模型，因此NoSQL運(yùn)動(dòng)的核心就是放棄事務(wù)強(qiáng)一致性以及關(guān)系模型，擁抱最終一致性和其它數(shù)據(jù)模型?(如 key/value，graphs 和Documents)。

兩個(gè)最著名的NoSQL數(shù)據(jù)庫(kù)就是Google的BigTable和Amazon的Dynamo，由于二者都未開源，其它組織就開始推出類似的開源替代項(xiàng)目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些創(chuàng)業(yè)公司也加入到這場(chǎng)NoSQL運(yùn)動(dòng)中，它們不一定是受BigTable和Dynamo的啟發(fā)，但都響應(yīng)了NoSQL的哲學(xué)，其中最出名的就是MongoDB。

在21世紀(jì)00年代末，市面上已經(jīng)有許多供用戶選擇的分布式數(shù)據(jù)庫(kù)產(chǎn)品。使用NoSQL的優(yōu)勢(shì)在于應(yīng)用開發(fā)者可以更關(guān)注應(yīng)用邏輯本身，而非數(shù)據(jù)庫(kù)的擴(kuò)展性問題；但與此同時(shí)許多應(yīng)用，如金融系統(tǒng)、訂單處理系統(tǒng)，由于無法放棄事務(wù)的一致性要求被拒之門外。

一些組織，如Google，已經(jīng)發(fā)現(xiàn)他們的許多工程師將過多的精力放在處理數(shù)據(jù)一致性上，這既暴露了數(shù)據(jù)庫(kù)的抽象、又提高了代碼的復(fù)雜度，這時(shí)候要么選擇回到傳統(tǒng)DBMS時(shí)代，用更高的機(jī)器配置縱向擴(kuò)容，要么選擇回到中間件時(shí)代，開發(fā)支持分布式事務(wù)的中間件。這兩種方案成本都很高，于是NewSQL運(yùn)動(dòng)開始醞釀。

NewSQL數(shù)據(jù)庫(kù)設(shè)計(jì)針對(duì)的讀寫事務(wù)有以下特點(diǎn)：

1、耗時(shí)短。

2、使用索引查詢，涉及少量數(shù)據(jù)。

3、重復(fù)度高，通常使用相同的查詢語(yǔ)句和不同的查詢參考。

也有一些學(xué)者認(rèn)為NewSQL系統(tǒng)是特指實(shí)現(xiàn)上使用Lock-free并發(fā)控制技術(shù)和share-nothing架構(gòu)的數(shù)據(jù)庫(kù)。所有我們認(rèn)為是NewSQL的數(shù)據(jù)庫(kù)系統(tǒng)確實(shí)都有這樣的特點(diǎn)。

目前哪些NoSQL數(shù)據(jù)庫(kù)應(yīng)用廣泛，各有什么特點(diǎn)

特點(diǎn)：

它們可以處理超大量的數(shù)據(jù)。

它們運(yùn)行在便宜的PC服務(wù)器集群上。

PC集群擴(kuò)充起來非常方便并且成本很低，避免了“sharding”操作的復(fù)雜性和成本。

它們擊碎了性能瓶頸。

NoSQL的支持者稱，通過NoSQL架構(gòu)可以省去將Web或Java應(yīng)用和數(shù)據(jù)轉(zhuǎn)換成SQL友好格式的時(shí)間，執(zhí)行速度變得更快。

“SQL并非適用于所有的程序代碼，” 對(duì)于那些繁重的重復(fù)操作的數(shù)據(jù)，SQL值得花錢。但是當(dāng)數(shù)據(jù)庫(kù)結(jié)構(gòu)非常簡(jiǎn)單時(shí)，SQL可能沒有太大用處。

沒有過多的操作。

雖然NoSQL的支持者也承認(rèn)關(guān)系數(shù)據(jù)庫(kù)提供了無可比擬的功能集合，而且在數(shù)據(jù)完整性上也發(fā)揮絕對(duì)穩(wěn)定，他們同時(shí)也表示，企業(yè)的具體需求可能沒有那么多。

Bootstrap支持

因?yàn)镹oSQL項(xiàng)目都是開源的，因此它們?nèi)狈?yīng)商提供的正式支持。這一點(diǎn)它們與大多數(shù)開源項(xiàng)目一樣，不得不從社區(qū)中尋求支持。

優(yōu)點(diǎn)：

易擴(kuò)展

NoSQL數(shù)據(jù)庫(kù)種類繁多，但是一個(gè)共同的特點(diǎn)都是去掉關(guān)系數(shù)據(jù)庫(kù)的關(guān)系型特性。數(shù)據(jù)之間無關(guān)系，這樣就非常容易擴(kuò)展。也無形之間，在架構(gòu)的層面上帶來了可擴(kuò)展的能力。

大數(shù)據(jù)量，高性能

NoSQL數(shù)據(jù)庫(kù)都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關(guān)系性，數(shù)據(jù)庫(kù)的結(jié)構(gòu)簡(jiǎn)單。一般MySQL使用 Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對(duì)web2.0的交互頻繁的應(yīng)用，Cache性能不高。而NoSQL的 Cache是記錄級(jí)的，是一種細(xì)粒度的Cache，所以NoSQL在這個(gè)層面上來說就要性能高很多了。

靈活的數(shù)據(jù)模型

NoSQL無需事先為要存儲(chǔ)的數(shù)據(jù)建立字段，隨時(shí)可以存儲(chǔ)自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫(kù)里，增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡(jiǎn)直就是一個(gè)噩夢(mèng)。這點(diǎn)在大數(shù)據(jù)量的web2.0時(shí)代尤其明顯。

高可用

NoSQL在不太影響性能的情況，就可以方便的實(shí)現(xiàn)高可用的架構(gòu)。比如Cassandra，HBase模型，通過復(fù)制模型也能實(shí)現(xiàn)高可用。

主要應(yīng)用：

Apache HBase

這個(gè)大數(shù)據(jù)管理平臺(tái)建立在谷歌強(qiáng)大的BigTable管理引擎基礎(chǔ)上。作為具有開源、Java編碼、分布式多個(gè)優(yōu)勢(shì)的數(shù)據(jù)庫(kù)，Hbase最初被設(shè)計(jì)應(yīng)用于Hadoop平臺(tái)，而這一強(qiáng)大的數(shù)據(jù)管理工具，也被Facebook采用，用于管理消息平臺(tái)的龐大數(shù)據(jù)。

Apache Storm

用于處理高速、大型數(shù)據(jù)流的分布式實(shí)時(shí)計(jì)算系統(tǒng)。Storm為Apache Hadoop添加了可靠的實(shí)時(shí)數(shù)據(jù)處理功能，同時(shí)還增加了低延遲的儀表板、安全警報(bào)，改進(jìn)了原有的操作方式，幫助企業(yè)更有效率地捕獲商業(yè)機(jī)會(huì)、發(fā)展新業(yè)務(wù)。

Apache Spark

該技術(shù)采用內(nèi)存計(jì)算，從多迭代批量處理出發(fā)，允許將數(shù)據(jù)載入內(nèi)存做反復(fù)查詢，此外還融合數(shù)據(jù)倉(cāng)庫(kù)、流處理和圖計(jì)算等多種計(jì)算范式，Spark用Scala語(yǔ)言實(shí)現(xiàn)，構(gòu)建在HDFS上，能與Hadoop很好的結(jié)合，而且運(yùn)行速度比MapReduce快100倍。

Apache Hadoop

該技術(shù)迅速成為了大數(shù)據(jù)管理標(biāo)準(zhǔn)之一。當(dāng)它被用來管理大型數(shù)據(jù)集時(shí)，對(duì)于復(fù)雜的分布式應(yīng)用，Hadoop體現(xiàn)出了非常好的性能，平臺(tái)的靈活性使它可以運(yùn)行在商用硬件系統(tǒng)，它還可以輕松地集成結(jié)構(gòu)化、半結(jié)構(gòu)化和甚至非結(jié)構(gòu)化數(shù)據(jù)集。

Apache Drill

你有多大的數(shù)據(jù)集？其實(shí)無論你有多大的數(shù)據(jù)集，Drill都能輕松應(yīng)對(duì)。通過支持HBase、Cassandra和MongoDB，Drill建立了交互式分析平臺(tái)，允許大規(guī)模數(shù)據(jù)吞吐，而且能很快得出結(jié)果。

Apache Sqoop

也許你的數(shù)據(jù)現(xiàn)在還被鎖定于舊系統(tǒng)中，Sqoop可以幫你解決這個(gè)問題。這一平臺(tái)采用并發(fā)連接，可以將數(shù)據(jù)從關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)方便地轉(zhuǎn)移到Hadoop中，可以自定義數(shù)據(jù)類型以及元數(shù)據(jù)傳播的映射。事實(shí)上，你還可以將數(shù)據(jù)（如新的數(shù)據(jù)）導(dǎo)入到HDFS、Hive和Hbase中。

Apache Giraph

這是功能強(qiáng)大的圖形處理平臺(tái)，具有很好可擴(kuò)展性和可用性。該技術(shù)已經(jīng)被Facebook采用，Giraph可以運(yùn)行在Hadoop環(huán)境中，可以將它直接部署到現(xiàn)有的Hadoop系統(tǒng)中。通過這種方式，你可以得到強(qiáng)大的分布式作圖能力，同時(shí)還能利用上現(xiàn)有的大數(shù)據(jù)處理引擎。

Cloudera Impala

Impala模型也可以部署在你現(xiàn)有的Hadoop群集上，監(jiān)視所有的查詢。該技術(shù)和MapReduce一樣，具有強(qiáng)大的批處理能力，而且Impala對(duì)于實(shí)時(shí)的SQL查詢也有很好的效果，通過高效的SQL查詢，你可以很快的了解到大數(shù)據(jù)平臺(tái)上的數(shù)據(jù)。

Gephi

它可以用來對(duì)信息進(jìn)行關(guān)聯(lián)和量化處理，通過為數(shù)據(jù)創(chuàng)建功能強(qiáng)大的可視化效果，你可以從數(shù)據(jù)中得到不一樣的洞察力。Gephi已經(jīng)支持多個(gè)圖表類型，而且可以在具有上百萬(wàn)個(gè)節(jié)點(diǎn)的大型網(wǎng)絡(luò)上運(yùn)行。Gephi具有活躍的用戶社區(qū)，Gephi還提供了大量的插件，可以和現(xiàn)有系統(tǒng)完美的集成到一起，它還可以對(duì)復(fù)雜的IT連接、分布式系統(tǒng)中各個(gè)節(jié)點(diǎn)、數(shù)據(jù)流等信息進(jìn)行可視化分析。

MongoDB

這個(gè)堅(jiān)實(shí)的平臺(tái)一直被很多組織推崇，它在大數(shù)據(jù)管理上有極好的性能。MongoDB最初是由DoubleClick公司的員工創(chuàng)建，現(xiàn)在該技術(shù)已經(jīng)被廣泛的應(yīng)用于大數(shù)據(jù)管理。MongoDB是一個(gè)應(yīng)用開源技術(shù)開發(fā)的NoSQL數(shù)據(jù)庫(kù)，可以用于在JSON這樣的平臺(tái)上存儲(chǔ)和處理數(shù)據(jù)。目前，紐約時(shí)報(bào)、Craigslist以及眾多企業(yè)都采用了MongoDB，幫助他們管理大型數(shù)據(jù)集。（Couchbase服務(wù)器也作為一個(gè)參考）。

十大頂尖公司：

Amazon Web Services

Forrester將AWS稱為“云霸主”，談到云計(jì)算領(lǐng)域的大數(shù)據(jù)，那就不得不提到亞馬遜。該公司的Hadoop產(chǎn)品被稱為EMR（Elastic Map Reduce），AWS解釋這款產(chǎn)品采用了Hadoop技術(shù)來提供大數(shù)據(jù)管理服務(wù)，但它不是純開源Hadoop，經(jīng)過修改后現(xiàn)在被專門用在AWS云上。

Forrester稱EMR有很好的市場(chǎng)前景。很多公司基于EMR為客戶提供服務(wù)，有一些公司將EMR應(yīng)用于數(shù)據(jù)查詢、建模、集成和管理。而且AWS還在創(chuàng)新，F(xiàn)orrester稱未來EMR可以基于工作量的需要自動(dòng)縮放調(diào)整大小。亞馬遜計(jì)劃為其產(chǎn)品和服務(wù)提供更強(qiáng)大的EMR支持，包括它的RedShift數(shù)據(jù)倉(cāng)庫(kù)、新公布的Kenesis實(shí)時(shí)處理引擎以及計(jì)劃中的NoSQL數(shù)據(jù)庫(kù)和商業(yè)智能工具。不過AWS還沒有自己的Hadoop發(fā)行版。

Cloudera

Cloudera有開源Hadoop的發(fā)行版，這個(gè)發(fā)行版采用了Apache Hadoop開源項(xiàng)目的很多技術(shù)，不過基于這些技術(shù)的發(fā)行版也有很大的進(jìn)步。Cloudera為它的Hadoop發(fā)行版開發(fā)了很多功能，包括Cloudera管理器，用于管理和監(jiān)控，以及名為Impala的SQL引擎等。Cloudera的Hadoop發(fā)行版基于開源Hadoop，但也不是純開源的產(chǎn)品。當(dāng)Cloudera的客戶需要Hadoop不具備的某些功能時(shí)，Cloudera的工程師們就會(huì)實(shí)現(xiàn)這些功能，或者找一個(gè)擁有這項(xiàng)技術(shù)的合作伙伴。Forrester表示：“Cloudera的創(chuàng)新方法忠于核心Hadoop，但因?yàn)槠淇蓪?shí)現(xiàn)快速創(chuàng)新并積極滿足客戶需求，這一點(diǎn)使它不同于其他那些供應(yīng)商?！蹦壳?，Cloudera的平臺(tái)已經(jīng)擁有200多個(gè)付費(fèi)客戶，一些客戶在Cloudera的技術(shù)支持下已經(jīng)可以跨1000多個(gè)節(jié)點(diǎn)實(shí)現(xiàn)對(duì)PB級(jí)數(shù)據(jù)的有效管理。

Hortonworks

和Cloudera一樣，Hortonworks是一個(gè)純粹的Hadoop技術(shù)公司。與Cloudera不同的是，Hortonworks堅(jiān)信開源Hadoop比任何其他供應(yīng)商的Hadoop發(fā)行版都要強(qiáng)大。Hortonworks的目標(biāo)是建立Hadoop生態(tài)圈和Hadoop用戶社區(qū)，推進(jìn)開源項(xiàng)目的發(fā)展。Hortonworks平臺(tái)和開源Hadoop聯(lián)系緊密，公司管理人員表示這會(huì)給用戶帶來好處，因?yàn)樗梢苑乐贡还?yīng)商套牢（如果Hortonworks的客戶想要離開這個(gè)平臺(tái)，他們可以輕松轉(zhuǎn)向其他開源平臺(tái)）。這并不是說Hortonworks完全依賴開源Hadoop技術(shù)，而是因?yàn)樵摴緦⑵渌虚_發(fā)的成果回報(bào)給了開源社區(qū)，比如Ambari，這個(gè)工具就是由Hortonworks開發(fā)而成，用來填充集群管理項(xiàng)目漏洞。Hortonworks的方案已經(jīng)得到了Teradata、Microsoft、Red Hat和SAP這些供應(yīng)商的支持。

IBM

當(dāng)企業(yè)考慮一些大的IT項(xiàng)目時(shí)，很多人首先會(huì)想到IBM。IBM是Hadoop項(xiàng)目的主要參與者之一，F(xiàn)orrester稱IBM已有100多個(gè)Hadoop部署，它的很多客戶都有PB級(jí)的數(shù)據(jù)。IBM在網(wǎng)格計(jì)算、全球數(shù)據(jù)中心和企業(yè)大數(shù)據(jù)項(xiàng)目實(shí)施等眾多領(lǐng)域有著豐富的經(jīng)驗(yàn)?！癐BM計(jì)劃繼續(xù)整合SPSS分析、高性能計(jì)算、BI工具、數(shù)據(jù)管理和建模、應(yīng)對(duì)高性能計(jì)算的工作負(fù)載管理等眾多技術(shù)?！?/p>

Intel

和AWS類似，英特爾不斷改進(jìn)和優(yōu)化Hadoop使其運(yùn)行在自己的硬件上，具體來說，就是讓Hadoop運(yùn)行在其至強(qiáng)芯片上，幫助用戶打破Hadoop系統(tǒng)的一些限制，使軟件和硬件結(jié)合的更好，英特爾的Hadoop發(fā)行版在上述方面做得比較好。Forrester指出英特爾在最近才推出這個(gè)產(chǎn)品，所以公司在未來還有很多改進(jìn)的可能，英特爾和微軟都被認(rèn)為是Hadoop市場(chǎng)上的潛力股。

MapR Technologies

MapR的Hadoop發(fā)行版目前為止也許是最好的了，不過很多人可能都沒有聽說過。Forrester對(duì)Hadoop用戶的調(diào)查顯示，MapR的評(píng)級(jí)最高，其發(fā)行版在架構(gòu)和數(shù)據(jù)處理能力上都獲得了最高分。MapR已將一套特殊功能融入其Hadoop發(fā)行版中。例如網(wǎng)絡(luò)文件系統(tǒng)（NFS）、災(zāi)難恢復(fù)以及高可用性功能。Forrester說MapR在Hadoop市場(chǎng)上沒有Cloudera和Hortonworks那樣的知名度，MapR要成為一個(gè)真正的大企業(yè)，還需要加強(qiáng)伙伴關(guān)系和市場(chǎng)營(yíng)銷。

Microsoft

微軟在開源軟件問題上一直很低調(diào)，但在大數(shù)據(jù)形勢(shì)下，它不得不考慮讓W(xué)indows也兼容Hadoop，它還積極投入到開源項(xiàng)目中，以更廣泛地推動(dòng)Hadoop生態(tài)圈的發(fā)展。我們可以在微軟的公共云Windows Azure HDInsight產(chǎn)品中看到其成果。微軟的Hadoop服務(wù)基于Hortonworks的發(fā)行版，而且是為Azure量身定制的。

微軟也有一些其他的項(xiàng)目，包括名為Polybase的項(xiàng)目，讓Hadoop查詢實(shí)現(xiàn)了SQLServer查詢的一些功能。Forrester說：“微軟在數(shù)據(jù)庫(kù)、數(shù)據(jù)倉(cāng)庫(kù)、云、OLAP、BI、電子表格（包括PowerPivot）、協(xié)作和開發(fā)工具市場(chǎng)上有很大優(yōu)勢(shì)，而且微軟擁有龐大的用戶群，但要在Hadoop這個(gè)領(lǐng)域成為行業(yè)領(lǐng)導(dǎo)者還有很遠(yuǎn)的路要走。”

Pivotal Software

EMC和Vmware部分大數(shù)據(jù)業(yè)務(wù)分拆組合產(chǎn)生了Pivotal。Pivotal一直努力構(gòu)建一個(gè)性能優(yōu)越的Hadoop發(fā)行版，為此，Pivotal在開源Hadoop的基礎(chǔ)上又添加了一些新的工具，包括一個(gè)名為HAWQ的SQL引擎以及一個(gè)專門解決大數(shù)據(jù)問題的Hadoop應(yīng)用。Forrester稱Pivotal Hadoop平臺(tái)的優(yōu)勢(shì)在于它整合了Pivotal、EMC、Vmware的眾多技術(shù)，Pivotal的真正優(yōu)勢(shì)實(shí)際上等于EMC和Vmware兩大公司為其撐腰。到目前為止，Pivotal的用戶還不到100個(gè)，而且大多是中小型客戶。

Teradata

對(duì)于Teradata來說，Hadoop既是一種威脅也是一種機(jī)遇。數(shù)據(jù)管理，特別是關(guān)于SQL和關(guān)系數(shù)據(jù)庫(kù)這一領(lǐng)域是Teradata的專長(zhǎng)。所以像Hadoop這樣的NoSQL平臺(tái)崛起可能會(huì)威脅到Teradata。相反，Teradata接受了Hadoop，通過與Hortonworks合作，Teradata在Hadoop平臺(tái)集成了SQL技術(shù)，這使Teradata的客戶可以在Hadoop平臺(tái)上方便地使用存儲(chǔ)在Teradata數(shù)據(jù)倉(cāng)庫(kù)中的數(shù)據(jù)。

AMPLab

通過將數(shù)據(jù)轉(zhuǎn)變?yōu)樾畔?，我們才可以理解世界，而這也正是AMPLab所做的。AMPLab致力于機(jī)器學(xué)習(xí)、數(shù)據(jù)挖掘、數(shù)據(jù)庫(kù)、信息檢索、自然語(yǔ)言處理和語(yǔ)音識(shí)別等多個(gè)領(lǐng)域，努力改進(jìn)對(duì)信息包括不透明數(shù)據(jù)集內(nèi)信息的甄別技術(shù)。除了Spark，開源分布式SQL查詢引擎Shark也源于AMPLab，Shark具有極高的查詢效率，具有良好的兼容性和可擴(kuò)展性。近幾年的發(fā)展使計(jì)算機(jī)科學(xué)進(jìn)入到全新的時(shí)代，而AMPLab為我們?cè)O(shè)想一個(gè)運(yùn)用大數(shù)據(jù)、云計(jì)算、通信等各種資源和技術(shù)靈活解決難題的方案，以應(yīng)對(duì)越來越復(fù)雜的各種難題。

nosql是什么

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)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫(kù)則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫(kù)的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重?cái)?shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題。

雖然NoSQL流行語(yǔ)火起來才短短一年的時(shí)間，但是不可否認(rèn)，現(xiàn)在已經(jīng)開始了第二代運(yùn)動(dòng)。盡管早期的堆棧代碼只能算是一種實(shí)驗(yàn)，然而現(xiàn)在的系統(tǒng)已經(jīng)更加的成熟、穩(wěn)定。不過現(xiàn)在也面臨著一個(gè)嚴(yán)酷的事實(shí)：技術(shù)越來越成熟——以至于原來很好的NoSQL數(shù)據(jù)存儲(chǔ)不得不進(jìn)行重寫，也有少數(shù)人認(rèn)為這就是所謂的2.0版本。這里列出一些比較知名的工具，可以為大數(shù)據(jù)建立快速、可擴(kuò)展的存儲(chǔ)庫(kù)。

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)用，這一概念無疑是一種全新的思維的注入。

對(duì)于NoSQL并沒有一個(gè)明確的范圍和定義，但是他們都普遍存在下面一些共同特征：

不需要預(yù)定義模式：不需要事先定義數(shù)據(jù)模式，預(yù)定義表結(jié)構(gòu)。數(shù)據(jù)中的每條記錄都可能有不同的屬性和格式。當(dāng)插入數(shù)據(jù)時(shí)，并不需要預(yù)先定義它們的模式。

無共享架構(gòu)：相對(duì)于將所有數(shù)據(jù)存儲(chǔ)的存儲(chǔ)區(qū)域網(wǎng)絡(luò)中的全共享架構(gòu)。NoSQL往往將數(shù)據(jù)劃分后存儲(chǔ)在各個(gè)本地服務(wù)器上。因?yàn)閺谋镜卮疟P讀取數(shù)據(jù)的性能往往好于通過網(wǎng)絡(luò)傳輸讀取數(shù)據(jù)的性能，從而提高了系統(tǒng)的性能。

彈性可擴(kuò)展：可以在系統(tǒng)運(yùn)行的時(shí)候，動(dòng)態(tài)增加或者刪除結(jié)點(diǎn)。不需要停機(jī)維護(hù)，數(shù)據(jù)可以自動(dòng)遷移。

分區(qū)：相對(duì)于將數(shù)據(jù)存放于同一個(gè)節(jié)點(diǎn)，NoSQL數(shù)據(jù)庫(kù)需要將數(shù)據(jù)進(jìn)行分區(qū)，將記錄分散在多個(gè)節(jié)點(diǎn)上面。并且通常分區(qū)的同時(shí)還要做復(fù)制。這樣既提高了并行性能，又能保證沒有單點(diǎn)失效的問題。

異步復(fù)制：和RAID存儲(chǔ)系統(tǒng)不同的是，NoSQL中的復(fù)制，往往是基于日志的異步復(fù)制。這樣，數(shù)據(jù)就可以盡快地寫入一個(gè)節(jié)點(diǎn)，而不會(huì)被網(wǎng)絡(luò)傳輸引起遲延。缺點(diǎn)是并不總是能保證一致性，這樣的方式在出現(xiàn)故障的時(shí)候，可能會(huì)丟失少量的數(shù)據(jù)。

BASE：相對(duì)于事務(wù)嚴(yán)格的ACID特性，NoSQL數(shù)據(jù)庫(kù)保證的是BASE特性。BASE是最終一致性和軟事務(wù)。

NoSQL數(shù)據(jù)庫(kù)并沒有一個(gè)統(tǒng)一的架構(gòu)，兩種NoSQL數(shù)據(jù)庫(kù)之間的不同，甚至遠(yuǎn)遠(yuǎn)超過兩種關(guān)系型數(shù)據(jù)庫(kù)的不同。可以說，NoSQL各有所長(zhǎng)，成功的NoSQL必然特別適用于某些場(chǎng)合或者某些應(yīng)用，在這些場(chǎng)合中會(huì)遠(yuǎn)遠(yuǎn)勝過關(guān)系型數(shù)據(jù)庫(kù)和其他的NoSQL。

newsql和nosql的區(qū)別和聯(lián)系

在大數(shù)據(jù)時(shí)代，“多種架構(gòu)支持多類應(yīng)用”成為數(shù)據(jù)庫(kù)行業(yè)應(yīng)對(duì)大數(shù)據(jù)的基本思路，數(shù)據(jù)庫(kù)行業(yè)出現(xiàn)互為補(bǔ)充的三大陣營(yíng)，適用于事務(wù)處理應(yīng)用的OldSQL、適用于數(shù)據(jù)分析應(yīng)用的NewSQL和適用于互聯(lián)網(wǎng)應(yīng)用的NoSQL。但在一些復(fù)雜的應(yīng)用場(chǎng)景中，單一數(shù)據(jù)庫(kù)架構(gòu)都不能完全滿足應(yīng)用場(chǎng)景對(duì)海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)管理、復(fù)雜分析、關(guān)聯(lián)查詢、實(shí)時(shí)性處理和控制建設(shè)成本等多方面的需要，因此不同架構(gòu)數(shù)據(jù)庫(kù)混合部署應(yīng)用成為滿足復(fù)雜應(yīng)用的必然選擇。不同架構(gòu)數(shù)據(jù)庫(kù)混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個(gè)案例對(duì)不同架構(gòu)數(shù)據(jù)庫(kù)的混合應(yīng)用部署進(jìn)行介紹。

OldSQL+NewSQL 在數(shù)據(jù)中心類應(yīng)用中混合部署

采用OldSQL+NewSQL模式構(gòu)建數(shù)據(jù)中心，在充分發(fā)揮OldSQL數(shù)據(jù)庫(kù)的事務(wù)處理能力的同時(shí)，借助NewSQL在實(shí)時(shí)性、復(fù)雜分析、即席查詢等方面的獨(dú)特優(yōu)勢(shì)，以及面對(duì)海量數(shù)據(jù)時(shí)較強(qiáng)的擴(kuò)展能力，滿足數(shù)據(jù)中心對(duì)當(dāng)前“熱”數(shù)據(jù)事務(wù)型處理和海量歷史“冷”數(shù)據(jù)分析兩方面的需求。OldSQL+NewSQL模式在數(shù)據(jù)中心類應(yīng)用中的互補(bǔ)作用體現(xiàn)在，OldSQL彌補(bǔ)了NewSQL不適合事務(wù)處理的不足，NewSQL彌補(bǔ)了OldSQL在海量數(shù)據(jù)存儲(chǔ)能力和處理性能方面的缺陷。

商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL數(shù)據(jù)庫(kù)滿足各業(yè)務(wù)系統(tǒng)數(shù)據(jù)的歸檔備份和事務(wù)型應(yīng)用，NewSQL MPP數(shù)據(jù)庫(kù)集群對(duì)即席查詢、多維分析等應(yīng)用提供高性能支持，并且通過MPP集群架構(gòu)實(shí)現(xiàn)應(yīng)對(duì)海量數(shù)據(jù)存儲(chǔ)的擴(kuò)展能力。

商業(yè)銀行數(shù)據(jù)中心存儲(chǔ)架構(gòu)

與傳統(tǒng)的OldSQL模式相比，商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合搭建模式，數(shù)據(jù)加載性能提升3倍以上，即席查詢和統(tǒng)計(jì)分析性能提升6倍以上。NewSQL MPP的高可擴(kuò)展性能夠應(yīng)對(duì)新的業(yè)務(wù)需求，可隨著數(shù)據(jù)量的增長(zhǎng)采用集群方式構(gòu)建存儲(chǔ)容量更大的數(shù)據(jù)中心。

OldSQL+NoSQL 在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中混合部署

在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中采用OldSQL+NoSQL混合模式，能夠很好的解決互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用對(duì)海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)進(jìn)行存儲(chǔ)和快速處理的需求。在諸如大型電子商務(wù)平臺(tái)、大型SNS平臺(tái)等互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用場(chǎng)景中，OldSQL在應(yīng)用中負(fù)責(zé)高價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和事務(wù)型處理，NoSQL在應(yīng)用中負(fù)責(zé)存儲(chǔ)和處理海量非結(jié)構(gòu)化的數(shù)據(jù)和低價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)。OldSQL+NoSQL模式在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中的互補(bǔ)作用體現(xiàn)在，OldSQL彌補(bǔ)了NoSQL在ACID特性和復(fù)雜關(guān)聯(lián)運(yùn)算方面的不足，NoSQL彌補(bǔ)了OldSQL在海量數(shù)據(jù)存儲(chǔ)和非結(jié)構(gòu)化數(shù)據(jù)處理方面的缺陷。

數(shù)據(jù)魔方是淘寶網(wǎng)的一款數(shù)據(jù)產(chǎn)品，主要提供行業(yè)數(shù)據(jù)分析、店鋪數(shù)據(jù)分析。淘寶數(shù)據(jù)產(chǎn)品在存儲(chǔ)層采用OldSQL+NoSQL混合模式，由基于MySQL的分布式關(guān)系型數(shù)據(jù)庫(kù)集群MyFOX和基于HBase的NoSQL存儲(chǔ)集群Prom組成。由于OldSQL強(qiáng)大的語(yǔ)義和關(guān)系表達(dá)能力，在應(yīng)用中仍然占據(jù)著重要地位，目前存儲(chǔ)在MyFOX中的統(tǒng)計(jì)結(jié)果數(shù)據(jù)已經(jīng)達(dá)到10TB，占據(jù)著數(shù)據(jù)魔方總數(shù)據(jù)量的95%以上。另一方面，NoSQL作為SQL的有益補(bǔ)充，解決了OldSQL數(shù)據(jù)庫(kù)無法解決的全屬性選擇器等問題。

淘寶海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)

基于OldSQL+NoSQL混合架構(gòu)的特點(diǎn)，數(shù)據(jù)魔方目前已經(jīng)能夠提供壓縮前80TB的數(shù)據(jù)存儲(chǔ)空間，支持每天4000萬(wàn)的查詢請(qǐng)求，平均響應(yīng)時(shí)間在28毫秒，足以滿足未來一段時(shí)間內(nèi)的業(yè)務(wù)增長(zhǎng)需求。

NewSQL+NoSQL 在行業(yè)大數(shù)據(jù)應(yīng)用中混合部署

行業(yè)大數(shù)據(jù)與互聯(lián)網(wǎng)大數(shù)據(jù)的區(qū)別在于行業(yè)大數(shù)據(jù)的價(jià)值密度更高，并且對(duì)結(jié)構(gòu)化數(shù)據(jù)的實(shí)時(shí)處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強(qiáng)一致性等都比互聯(lián)網(wǎng)大數(shù)據(jù)有更高的要求。行業(yè)大數(shù)據(jù)應(yīng)用場(chǎng)景主要是分析類應(yīng)用，如：電信、金融、政務(wù)、能源等行業(yè)的決策輔助、預(yù)測(cè)預(yù)警、統(tǒng)計(jì)分析、經(jīng)營(yíng)分析等。

在行業(yè)大數(shù)據(jù)應(yīng)用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在結(jié)構(gòu)化數(shù)據(jù)分析處理方面的優(yōu)勢(shì)，以及NoSQL在非結(jié)構(gòu)數(shù)據(jù)處理方面的優(yōu)勢(shì)，實(shí)現(xiàn)NewSQL與NoSQL的功能互補(bǔ)，解決行業(yè)大數(shù)據(jù)應(yīng)用對(duì)高價(jià)值結(jié)構(gòu)化數(shù)據(jù)的實(shí)時(shí)處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強(qiáng)一致性等要求，以及對(duì)海量非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)和精確查詢的要求。在應(yīng)用中，NewSQL承擔(dān)高價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和分析處理工作，NoSQL承擔(dān)存儲(chǔ)和處理海量非結(jié)構(gòu)化數(shù)據(jù)和不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的低價(jià)值密度結(jié)構(gòu)化數(shù)據(jù)的工作。

當(dāng)前電信運(yùn)營(yíng)商在集中化BI系統(tǒng)建設(shè)過程中面臨著數(shù)據(jù)規(guī)模大、數(shù)據(jù)處理類型多等問題，并且需要應(yīng)對(duì)大量的固定應(yīng)用，以及占統(tǒng)計(jì)總數(shù)80%以上的突發(fā)性臨時(shí)統(tǒng)計(jì)(ad-hoc)需求。在集中化BI系統(tǒng)的建設(shè)中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復(fù)雜分析、即席查詢等方面處理性能的優(yōu)勢(shì)，及NoSQL在非結(jié)構(gòu)化數(shù)據(jù)處理和海量數(shù)據(jù)存儲(chǔ)方面的優(yōu)勢(shì)，實(shí)現(xiàn)高效低成本。

集中化BI系統(tǒng)數(shù)據(jù)存儲(chǔ)架構(gòu)

集中化BI系統(tǒng)按照數(shù)據(jù)類型和處理方式的不同，將結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)分別存儲(chǔ)在不同的系統(tǒng)中：非結(jié)構(gòu)化數(shù)據(jù)在Hadoop平臺(tái)上存儲(chǔ)與處理;結(jié)構(gòu)化、不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的數(shù)據(jù)保存在NoSQL數(shù)據(jù)庫(kù)或Hadoop平臺(tái);結(jié)構(gòu)化、需要關(guān)聯(lián)分析或經(jīng)常ad-hoc查詢的數(shù)據(jù)，保存在NewSQL MPP數(shù)據(jù)庫(kù)中，短期高價(jià)值數(shù)據(jù)放在高性能平臺(tái)，中長(zhǎng)期放在低成本產(chǎn)品中。

結(jié)語(yǔ)

當(dāng)前信息化應(yīng)用的多樣性、復(fù)雜性，以及三種數(shù)據(jù)庫(kù)架構(gòu)各自所具有的優(yōu)勢(shì)和局限性，造成任何一種架構(gòu)的數(shù)據(jù)庫(kù)都不能完全滿足應(yīng)用需求，因此不同架構(gòu)數(shù)據(jù)庫(kù)混合使用，從而彌補(bǔ)其他架構(gòu)的不足成為必然選擇。根據(jù)應(yīng)用場(chǎng)景采用不同架構(gòu)數(shù)據(jù)庫(kù)進(jìn)行組合搭配，充分發(fā)揮每種架構(gòu)數(shù)據(jù)庫(kù)的特點(diǎn)和優(yōu)勢(shì)，并且與其他架構(gòu)數(shù)據(jù)庫(kù)形成互補(bǔ)，完全涵蓋應(yīng)用需求，保證數(shù)據(jù)資源的最優(yōu)化利用，將成為未來一段時(shí)期內(nèi)信息化應(yīng)用主要采用的解決方式。

目前在國(guó)內(nèi)市場(chǎng)上，OldSQL主要為Oracle、IBM等國(guó)外數(shù)據(jù)庫(kù)廠商所壟斷，達(dá)夢(mèng)、金倉(cāng)等國(guó)產(chǎn)廠商仍處于追趕狀態(tài);南大通用憑借國(guó)產(chǎn)新型數(shù)據(jù)庫(kù)GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場(chǎng)三強(qiáng);NoSQL方面用戶則大多采用Hadoop開源方案。

網(wǎng)易傳媒技術(shù)團(tuán)隊(duì)：消息中間件實(shí)現(xiàn)延遲隊(duì)列的應(yīng)用與實(shí)踐

早期需要延遲處理的業(yè)務(wù)場(chǎng)景，更多的是通過定時(shí)任務(wù)掃表，然后執(zhí)行滿足條件的記錄，具有頻率高、命中低、資源消耗大的缺點(diǎn)。隨著消息中間件的普及，延遲消息可以很好的處理這種場(chǎng)景，本文主要介紹延遲消息的使用場(chǎng)景以及基于常見的消息中間件如何實(shí)現(xiàn)延遲隊(duì)列，最后給出了一個(gè)在網(wǎng)易公開課使用延遲隊(duì)列的實(shí)踐。

1、有效期：限時(shí)活動(dòng)、拼團(tuán)。。。

2、超時(shí)處理：取消超時(shí)未支付訂單、超時(shí)自動(dòng)確認(rèn)收貨。。。

4、重試：網(wǎng)絡(luò)異常重試、打車派單、依賴條件未滿足重試。。。

5、定時(shí)任務(wù)：智能設(shè)備定時(shí)啟動(dòng)。。。

1、RabbitMQ

1）簡(jiǎn)介：基于AMQP協(xié)議，使用Erlang編寫，實(shí)現(xiàn)了一個(gè)Broker框架

a、Broker：接收和分發(fā)消息的代理服務(wù)器

b、Virtual Host：虛擬主機(jī)之間相互隔離，可理解為一個(gè)虛擬主機(jī)對(duì)應(yīng)一個(gè)消息服務(wù)

c、Exchange：交換機(jī)，消息發(fā)送到指定虛擬機(jī)的交換機(jī)上

d、Binding：交換機(jī)與隊(duì)列綁定，并通過路由策略和routingKey將消息投遞到一個(gè)或多個(gè)隊(duì)列中

e、Queue：存放消息的隊(duì)列，F(xiàn)IFO，可持久化

f、Channel：信道，消費(fèi)者通過信道消費(fèi)消息，一個(gè)TCP連接上可同時(shí)創(chuàng)建成百上千個(gè)信道，作為消息隔離

2）延遲隊(duì)列實(shí)現(xiàn)：RabbitMQ的延遲隊(duì)列基于消息的存活時(shí)間TTL（Time To Live）和死信交換機(jī)DLE（Dead Letter Exchanges）實(shí)現(xiàn)

a、TTL：RabbitMQ支持對(duì)隊(duì)列和消息各自設(shè)置存活時(shí)間，取二者中較小的值，即隊(duì)列無消費(fèi)者連接或消息在隊(duì)列中一直未被消費(fèi)的過期時(shí)間

b、DLE：過期的消息通過綁定的死信交換機(jī)，路由到指定的死信隊(duì)列，消費(fèi)者實(shí)際上消費(fèi)的是死信隊(duì)列上的消息

3）缺點(diǎn)：

a、配置麻煩，額外增加一個(gè)死信交換機(jī)和一個(gè)死信隊(duì)列的配置

b、脆弱性，配置錯(cuò)誤或者生產(chǎn)者消費(fèi)者連接的隊(duì)列錯(cuò)誤都有可能造成延遲失效

2、RocketMQ

1）簡(jiǎn)介：來源于阿里，目前為Apache頂級(jí)開源項(xiàng)目，使用Java編寫，基于長(zhǎng)輪詢的拉取方式，支持事務(wù)消息，并解決了順序消息和海量堆積的問題

a、Broker：存放Topic并根據(jù)讀取Producer的提交日志，將邏輯上的一個(gè)Topic分多個(gè)Queue存儲(chǔ)，每個(gè)Queue上存儲(chǔ)消息在提交日志上的位置

b、Name Server：無狀態(tài)的節(jié)點(diǎn)，維護(hù)Topic與Broker的對(duì)應(yīng)關(guān)系以及Broker的主從關(guān)系

2）延遲隊(duì)列實(shí)現(xiàn)：RocketMQ發(fā)送延時(shí)消息時(shí)先把消息按照延遲時(shí)間段發(fā)送到指定的隊(duì)列中(rocketmq把每種延遲時(shí)間段的消息都存放到同一個(gè)隊(duì)列中)，然后通過一個(gè)定時(shí)器進(jìn)行輪訓(xùn)這些隊(duì)列，查看消息是否到期，如果到期就把這個(gè)消息發(fā)送到指定topic的隊(duì)列中

3）缺點(diǎn)：延遲時(shí)間粒度受限制（1s/5s/10s/30s/1m/2m/3m/4m/5m/6m/7m/8m/9m/10m/20m/30m/1h/2h）

3、Kafka

1）簡(jiǎn)介：來源于Linkedin，目前為Apache頂級(jí)開源項(xiàng)目，使用Scala和Java編寫，基于zookeeper協(xié)調(diào)的分布式、流處理的日志系統(tǒng)，升級(jí)版為Jafka

2）延遲隊(duì)列實(shí)現(xiàn)：Kafka支持延時(shí)生產(chǎn)、延時(shí)拉取、延時(shí)刪除等，其基于時(shí)間輪和JDK的DelayQueue實(shí)現(xiàn)

a、時(shí)間輪(TimingWheel)：是一個(gè)存儲(chǔ)定時(shí)任務(wù)的環(huán)形隊(duì)列，底層采用數(shù)組實(shí)現(xiàn)，數(shù)組中的每個(gè)元素可以存放一個(gè)定時(shí)任務(wù)列表

b、定時(shí)任務(wù)列表(TimerTaskList)：是一個(gè)環(huán)形的雙向鏈表，鏈表中的每一項(xiàng)表示的都是定時(shí)任務(wù)項(xiàng)

c、定時(shí)任務(wù)項(xiàng)(TimerTaskEntry)：封裝了真正的定時(shí)任務(wù)TimerTask

d、層級(jí)時(shí)間輪：當(dāng)任務(wù)的到期時(shí)間超過了當(dāng)前時(shí)間輪所表示的時(shí)間范圍時(shí)，就會(huì)嘗試添加到上層時(shí)間輪中，類似于鐘表就是一個(gè)三級(jí)時(shí)間輪

e、JDK DelayQueue：存儲(chǔ)TimerTaskList，并根據(jù)其expiration來推進(jìn)時(shí)間輪的時(shí)間，每推進(jìn)一次除執(zhí)行相應(yīng)任務(wù)列表外，層級(jí)時(shí)間輪也會(huì)進(jìn)行相應(yīng)調(diào)整

3）缺點(diǎn)：

a、延遲精度取決于時(shí)間格設(shè)置

b、延遲任務(wù)除由超時(shí)觸發(fā)還可能被外部事件觸發(fā)而執(zhí)行

4、ActiveMQ

1）簡(jiǎn)介：基于JMS協(xié)議，Java編寫的Apache頂級(jí)開源項(xiàng)目，支持點(diǎn)對(duì)點(diǎn)和發(fā)布訂閱兩種模式。

a、點(diǎn)對(duì)點(diǎn)（point-to-point）：消息發(fā)送到指定的隊(duì)列，每條消息只有一個(gè)消費(fèi)者能夠消費(fèi)，基于拉模型

b、發(fā)布訂閱（publish/subscribe）：消息發(fā)送到主題Topic上，每條消息會(huì)被訂閱該Topic的所有消費(fèi)者各自消費(fèi)，基于推模型

2）延遲隊(duì)列實(shí)現(xiàn)：需要延遲的消息會(huì)先存儲(chǔ)在JobStore中，通過異步線程任務(wù)JobScheduler將到達(dá)投遞時(shí)間的消息投遞到相應(yīng)隊(duì)列上

a、Broker Filter：Broker中定義了一系列BrokerFilter的子類構(gòu)成攔截器鏈，按順序?qū)ο⑦M(jìn)行相應(yīng)處理

b、ScheduleBroker：當(dāng)消息中指定了延遲相關(guān)屬性，并且jobId為空時(shí)，會(huì)生成調(diào)度任務(wù)存儲(chǔ)到JobStore中，此時(shí)消息不會(huì)進(jìn)入到隊(duì)列

c、JobStore：基于BTree存儲(chǔ)，key為任務(wù)執(zhí)行的時(shí)間戳，value為該時(shí)間戳下需要執(zhí)行的任務(wù)列表

d、JobScheduler：取JobStore中最小的key執(zhí)行（調(diào)度時(shí)間最早的），執(zhí)行時(shí)間=當(dāng)前時(shí)間，將該任務(wù)列表依次投遞到所屬的隊(duì)列，對(duì)于需要重復(fù)投遞和投遞失敗的會(huì)再次存入JobStore中。

注： 此處JobScheduler的執(zhí)行時(shí)間間隔可動(dòng)態(tài)變化，默認(rèn)0.5s，有新任務(wù)時(shí)會(huì)立即執(zhí)行（Object-notifyAll()）并設(shè)置時(shí)間間隔為0.1s，沒有新任務(wù)后，下次執(zhí)行時(shí)間為最近任務(wù)的調(diào)度執(zhí)行時(shí)間。

3）缺點(diǎn)：投遞到隊(duì)列失敗，將消息重新存入JobStore，消息調(diào)度執(zhí)行時(shí)間=系統(tǒng)當(dāng)前時(shí)間+延遲時(shí)間，會(huì)導(dǎo)致消息被真實(shí)投遞的時(shí)間可能為設(shè)置的延遲時(shí)間的整數(shù)倍

5、Redis

1）簡(jiǎn)介：基于Key-Value的NoSQL數(shù)據(jù)庫(kù)，由于其極高的性能常被當(dāng)作緩存來使用，其數(shù)據(jù)結(jié)構(gòu)支持：字符串、哈希、列表、集合、有序集合

2）延遲隊(duì)列實(shí)現(xiàn)：Redis的延遲隊(duì)列基于有序集合，score為執(zhí)行時(shí)間戳，value為任務(wù)實(shí)體或任務(wù)實(shí)體引用

3）缺點(diǎn)：

a、實(shí)現(xiàn)復(fù)雜，本身不支持

b、完全基于內(nèi)存，延遲時(shí)間長(zhǎng)浪費(fèi)內(nèi)存資源

6、消息隊(duì)列對(duì)比

1、公開課延遲隊(duì)列技術(shù)選型

1）業(yè)務(wù)場(chǎng)景：關(guān)閉超時(shí)未支付訂單、限時(shí)優(yōu)惠活動(dòng)、拼團(tuán)

2）性能要求：訂單、活動(dòng)、拼團(tuán) 數(shù)據(jù)量可控，上述MQ均能滿足要求

3）可靠性：使用ActiveMQ、RabbitMQ、RocketMQ作為延遲隊(duì)列更普遍

4）可用性：ActiveMQ、RocketMQ自身支持延遲隊(duì)列功能，且目前公開課業(yè)務(wù)中使用的中間件為ActiveMQ和Kafka

5）延遲時(shí)間靈活：活動(dòng)的開始和結(jié)束時(shí)間比較靈活，而RocketMQ時(shí)間粒度較粗，Kafka會(huì)依賴時(shí)間格有精度缺失

結(jié)論： 最終選擇ActiveMQ來作為延遲隊(duì)列

2、業(yè)務(wù)場(chǎng)景：關(guān)閉未支付訂單

1）關(guān)閉微信未支付訂單

2）關(guān)閉IOS未支付訂單

3、ActiveMQ使用方式

1）activemq.xml中支持調(diào)度任務(wù)

2）發(fā)送消息時(shí)，設(shè)置message的延遲屬性

其中：

a、延遲處理

AMQ_SCHEDULED_DELAY：設(shè)置多長(zhǎng)時(shí)間后，投遞給消費(fèi)者（毫秒）

b、重復(fù)投遞

AMQ_SCHEDULED_PERIOD：重復(fù)投遞時(shí)間間隔（毫秒）

AMQ_SCHEDULED_REPEAT：重復(fù)投遞次數(shù)

c、指定調(diào)度計(jì)劃

AMQ_SCHEDULED_CRON：corn正則表達(dá)式

4、公開課使用中進(jìn)行的優(yōu)化

1）可靠性：針對(duì)實(shí)際投遞時(shí)間可能翻倍的問題，結(jié)合ActiveMQ的重復(fù)投遞，在消費(fèi)者邏輯中做冪等處理來保證延遲時(shí)間的準(zhǔn)確性

2）可追溯性：延遲消息及消費(fèi)情況做數(shù)據(jù)庫(kù)冗余存儲(chǔ)

3）易用性：業(yè)務(wù)上定義好延遲枚舉類型，直接使用JmsDelayTemplate發(fā)送，無需關(guān)心數(shù)據(jù)備份和參數(shù)等細(xì)節(jié)

1、無論是基于死信隊(duì)列還是基于數(shù)據(jù)先存儲(chǔ)后投遞，本質(zhì)上都是將延遲待發(fā)送的消息數(shù)據(jù)與正常訂閱的隊(duì)列分開存儲(chǔ)，從而降低耦合度

2、無論是檢查隊(duì)頭消息TTL還是調(diào)度存儲(chǔ)的延遲數(shù)據(jù)，本質(zhì)上都是通過定時(shí)任務(wù)來完成的，但是定時(shí)任務(wù)的觸發(fā)策略以及延遲數(shù)據(jù)的存儲(chǔ)方式?jīng)Q定了不同中間件之間的性能優(yōu)劣

張浩，2018年加入網(wǎng)易傳媒，高級(jí)Java開發(fā)工程師，目前在網(wǎng)易公開課主要做支付財(cái)務(wù)體系、版本迭代相關(guān)的工作。

消息中間件（一）MQ詳解及四大MQ比較

一、消息中間件相關(guān)知識(shí)

1、概述

消息隊(duì)列已經(jīng)逐漸成為企業(yè)IT系統(tǒng)內(nèi)部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為異步RPC的主要手段之一。當(dāng)今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發(fā)RocketMQ等。

2、消息中間件的組成

2.1 Broker

消息服務(wù)器，作為server提供消息核心服務(wù)

2.2 Producer

消息生產(chǎn)者，業(yè)務(wù)的發(fā)起方，負(fù)責(zé)生產(chǎn)消息傳輸給broker，

2.3 Consumer

消息消費(fèi)者，業(yè)務(wù)的處理方，負(fù)責(zé)從broker獲取消息并進(jìn)行業(yè)務(wù)邏輯處理

2.4 Topic

2.5 Queue

2.6 Message

消息體，根據(jù)不同通信協(xié)議定義的固定格式進(jìn)行編碼的數(shù)據(jù)包，來封裝業(yè)務(wù)數(shù)據(jù)，實(shí)現(xiàn)消息的傳輸

3 消息中間件模式分類

3.1 點(diǎn)對(duì)點(diǎn)

PTP點(diǎn)對(duì)點(diǎn):使用queue作為通信載體

說明：

消息生產(chǎn)者生產(chǎn)消息發(fā)送到queue中，然后消息消費(fèi)者從queue中取出并且消費(fèi)消息。

消息被消費(fèi)以后，queue中不再存儲(chǔ)，所以消息消費(fèi)者不可能消費(fèi)到已經(jīng)被消費(fèi)的消息。 Queue支持存在多個(gè)消費(fèi)者，但是對(duì)一個(gè)消息而言，只會(huì)有一個(gè)消費(fèi)者可以消費(fèi)。

說明：

queue實(shí)現(xiàn)了負(fù)載均衡，將producer生產(chǎn)的消息發(fā)送到消息隊(duì)列中，由多個(gè)消費(fèi)者消費(fèi)。但一個(gè)消息只能被一個(gè)消費(fèi)者接受，當(dāng)沒有消費(fèi)者可用時(shí)，這個(gè)消息會(huì)被保存直到有一個(gè)可用的消費(fèi)者。

4 消息中間件的優(yōu)勢(shì)

4.1 系統(tǒng)解耦

交互系統(tǒng)之間沒有直接的調(diào)用關(guān)系，只是通過消息傳輸，故系統(tǒng)侵入性不強(qiáng)，耦合度低。

4.2 提高系統(tǒng)響應(yīng)時(shí)間

例如原來的一套邏輯，完成支付可能涉及先修改訂單狀態(tài)、計(jì)算會(huì)員積分、通知物流配送幾個(gè)邏輯才能完成；通過MQ架構(gòu)設(shè)計(jì)，就可將緊急重要（需要立刻響應(yīng)）的業(yè)務(wù)放到該調(diào)用方法中，響應(yīng)要求不高的使用消息隊(duì)列，放到MQ隊(duì)列中，供消費(fèi)者處理。

4.3 為大數(shù)據(jù)處理架構(gòu)提供服務(wù)

通過消息作為整合，大數(shù)據(jù)的背景下，消息隊(duì)列還與實(shí)時(shí)處理架構(gòu)整合，為數(shù)據(jù)處理提供性能支持。

4.4 Java消息服務(wù)——JMS

Java消息服務(wù)（Java Message Service，JMS）應(yīng)用程序接口是一個(gè)Java平臺(tái)中關(guān)于面向消息中間件（MOM）的API，用于在兩個(gè)應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進(jìn)行異步通信。

5 消息中間件應(yīng)用場(chǎng)景

5.1 異步通信

有些業(yè)務(wù)不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶把一個(gè)消息放入隊(duì)列，但并不立即處理它。想向隊(duì)列中放入多少消息就放多少，然后在需要的時(shí)候再去處理它們。

5.2 解耦

降低工程間的強(qiáng)依賴程度，針對(duì)異構(gòu)系統(tǒng)進(jìn)行適配。在項(xiàng)目啟動(dòng)之初來預(yù)測(cè)將來項(xiàng)目會(huì)碰到什么需求，是極其困難的。通過消息系統(tǒng)在處理過程中間插入了一個(gè)隱含的、基于數(shù)據(jù)的接口層，兩邊的處理過程都要實(shí)現(xiàn)這一接口，當(dāng)應(yīng)用發(fā)生變化時(shí)，可以獨(dú)立的擴(kuò)展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

5.3 冗余

有些情況下，處理數(shù)據(jù)的過程會(huì)失敗。除非數(shù)據(jù)被持久化，否則將造成丟失。消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險(xiǎn)。許多消息隊(duì)列所采用的”插入-獲取-刪除”范式中，在把一個(gè)消息從隊(duì)列中刪除之前，需要你的處理系統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)據(jù)被安全的保存直到你使用完畢。

5.4 擴(kuò)展性

因?yàn)橄㈥?duì)列解耦了你的處理過程，所以增大消息入隊(duì)和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調(diào)節(jié)參數(shù)。便于分布式擴(kuò)容。

5.5 過載保護(hù)

在訪問量劇增的情況下，應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量無法提取預(yù)知；如果以為了能處理這類瞬間峰值訪問為標(biāo)準(zhǔn)來投入資源隨時(shí)待命無疑是巨大的浪費(fèi)。使用消息隊(duì)列能夠使關(guān)鍵組件頂住突發(fā)的訪問壓力，而不會(huì)因?yàn)橥话l(fā)的超負(fù)荷的請(qǐng)求而完全崩潰。

5.6 可恢復(fù)性

系統(tǒng)的一部分組件失效時(shí)，不會(huì)影響到整個(gè)系統(tǒng)。消息隊(duì)列降低了進(jìn)程間的耦合度，所以即使一個(gè)處理消息的進(jìn)程掛掉，加入隊(duì)列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。

5.7 順序保證

在大多使用場(chǎng)景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊(duì)列本來就是排序的，并且能保證數(shù)據(jù)會(huì)按照特定的順序來處理。

5.8 緩沖

在任何重要的系統(tǒng)中，都會(huì)有需要不同的處理時(shí)間的元素。消息隊(duì)列通過一個(gè)緩沖層來幫助任務(wù)最高效率的執(zhí)行，該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度。以調(diào)節(jié)系統(tǒng)響應(yīng)時(shí)間。

5.9 數(shù)據(jù)流處理

分布式系統(tǒng)產(chǎn)生的海量數(shù)據(jù)流，如：業(yè)務(wù)日志、監(jiān)控?cái)?shù)據(jù)、用戶行為等，針對(duì)這些數(shù)據(jù)流進(jìn)行實(shí)時(shí)或批量采集匯總，然后進(jìn)行大數(shù)據(jù)分析是當(dāng)前互聯(lián)網(wǎng)的必備技術(shù)，通過消息隊(duì)列完成此類數(shù)據(jù)收集是最好的選擇。

6 消息中間件常用協(xié)議

6.1 AMQP協(xié)議

AMQP即Advanced Message Queuing Protocol,一個(gè)提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn)高級(jí)消息隊(duì)列協(xié)議,是應(yīng)用層協(xié)議的一個(gè)開放標(biāo)準(zhǔn),為面向消息的中間件設(shè)計(jì)。基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品，不同開發(fā)語(yǔ)言等條件的限制。

優(yōu)點(diǎn)：可靠、通用

6.2 MQTT協(xié)議

MQTT（Message Queuing Telemetry Transport，消息隊(duì)列遙測(cè)傳輸）是IBM開發(fā)的一個(gè)即時(shí)通訊協(xié)議，有可能成為物聯(lián)網(wǎng)的重要組成部分。該協(xié)議支持所有平臺(tái)，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，被用來當(dāng)做傳感器和致動(dòng)器（比如通過Twitter讓房屋聯(lián)網(wǎng)）的通信協(xié)議。

優(yōu)點(diǎn)：格式簡(jiǎn)潔、占用帶寬小、移動(dòng)端通信、PUSH、嵌入式系統(tǒng)

6.3 STOMP協(xié)議

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協(xié)議，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設(shè)計(jì)的簡(jiǎn)單文本協(xié)議。STOMP提供一個(gè)可互操作的連接格式，允許客戶端與任意STOMP消息代理（Broker）進(jìn)行交互。

優(yōu)點(diǎn)：命令模式（非topic\queue模式）

6.4 XMPP協(xié)議

XMPP（可擴(kuò)展消息處理現(xiàn)場(chǎng)協(xié)議，Extensible Messaging and Presence Protocol）是基于可擴(kuò)展標(biāo)記語(yǔ)言（XML）的協(xié)議，多用于即時(shí)消息（IM）以及在線現(xiàn)場(chǎng)探測(cè)。適用于服務(wù)器之間的準(zhǔn)即時(shí)操作。核心是基于XML流傳輸，這個(gè)協(xié)議可能最終允許因特網(wǎng)用戶向因特網(wǎng)上的其他任何人發(fā)送即時(shí)消息，即使其操作系統(tǒng)和瀏覽器不同。

優(yōu)點(diǎn)：通用公開、兼容性強(qiáng)、可擴(kuò)展、安全性高，但XML編碼格式占用帶寬大

6.5 其他基于TCP/IP自定義的協(xié)議

有些特殊框架（如：redis、kafka、zeroMq等）根據(jù)自身需要未嚴(yán)格遵循MQ規(guī)范，而是基于TCP\IP自行封裝了一套協(xié)議，通過網(wǎng)絡(luò)socket接口進(jìn)行傳輸，實(shí)現(xiàn)了MQ的功能。

7 常見消息中間件MQ介紹

7.1 RocketMQ

阿里系下開源的一款分布式、隊(duì)列模型的消息中間件，原名Metaq，3.0版本名稱改為RocketMQ，是阿里參照kafka設(shè)計(jì)思想使用java實(shí)現(xiàn)的一套mq。同時(shí)將阿里系內(nèi)部多款mq產(chǎn)品（Notify、metaq）進(jìn)行整合，只維護(hù)核心功能，去除了所有其他運(yùn)行時(shí)依賴，保證核心功能最簡(jiǎn)化，在此基礎(chǔ)上配合阿里上述其他開源產(chǎn)品實(shí)現(xiàn)不同場(chǎng)景下mq的架構(gòu)，目前主要多用于訂單交易系統(tǒng)。

具有以下特點(diǎn)：

官方提供了一些不同于kafka的對(duì)比差異：

7.2 RabbitMQ

使用Erlang編寫的一個(gè)開源的消息隊(duì)列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它變的非常重量級(jí)，更適合于企業(yè)級(jí)的開發(fā)。同時(shí)實(shí)現(xiàn)了Broker架構(gòu)，核心思想是生產(chǎn)者不會(huì)將消息直接發(fā)送給隊(duì)列，消息在發(fā)送給客戶端時(shí)先在中心隊(duì)列排隊(duì)。對(duì)路由(Routing)，負(fù)載均衡(Load balance)、數(shù)據(jù)持久化都有很好的支持。多用于進(jìn)行企業(yè)級(jí)的ESB整合。

7.3 ActiveMQ

Apache下的一個(gè)子項(xiàng)目。使用Java完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實(shí)現(xiàn)，少量代碼就可以高效地實(shí)現(xiàn)高級(jí)應(yīng)用場(chǎng)景?？刹灏蔚膫鬏攨f(xié)議支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語(yǔ)言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。

7.4 Redis

使用C語(yǔ)言開發(fā)的一個(gè)Key-Value的NoSQL數(shù)據(jù)庫(kù)，開發(fā)維護(hù)很活躍，雖然它是一個(gè)Key-Value數(shù)據(jù)庫(kù)存儲(chǔ)系統(tǒng)，但它本身支持MQ功能，所以完全可以當(dāng)做一個(gè)輕量級(jí)的隊(duì)列服務(wù)來使用。對(duì)于RabbitMQ和Redis的入隊(duì)和出隊(duì)操作，各執(zhí)行100萬(wàn)次，每10萬(wàn)次記錄一次執(zhí)行時(shí)間。測(cè)試數(shù)據(jù)分為128Bytes、512Bytes、1K和10K四個(gè)不同大小的數(shù)據(jù)。實(shí)驗(yàn)表明：入隊(duì)時(shí)，當(dāng)數(shù)據(jù)比較小時(shí)Redis的性能要高于RabbitMQ，而如果數(shù)據(jù)大小超過了10K，Redis則慢的無法忍受；出隊(duì)時(shí)，無論數(shù)據(jù)大小，Redis都表現(xiàn)出非常好的性能，而RabbitMQ的出隊(duì)性能則遠(yuǎn)低于Redis。

7.5 Kafka

Apache下的一個(gè)子項(xiàng)目，使用scala實(shí)現(xiàn)的一個(gè)高性能分布式Publish/Subscribe消息隊(duì)列系統(tǒng)，具有以下特性：

7.6 ZeroMQ

號(hào)稱最快的消息隊(duì)列系統(tǒng)，專門為高吞吐量/低延遲的場(chǎng)景開發(fā)，在金融界的應(yīng)用中經(jīng)常使用，偏重于實(shí)時(shí)數(shù)據(jù)通信場(chǎng)景。ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長(zhǎng)的高級(jí)/復(fù)雜的隊(duì)列，但是開發(fā)人員需要自己組合多種技術(shù)框架，開發(fā)成本高。因此ZeroMQ具有一個(gè)獨(dú)特的非中間件的模式，更像一個(gè)socket library，你不需要安裝和運(yùn)行一個(gè)消息服務(wù)器或中間件，因?yàn)槟愕膽?yīng)用程序本身就是使用ZeroMQ API完成邏輯服務(wù)的角色。但是ZeroMQ僅提供非持久性的隊(duì)列，如果down機(jī)，數(shù)據(jù)將會(huì)丟失。如：Twitter的Storm中使用ZeroMQ作為數(shù)據(jù)流的傳輸。

ZeroMQ套接字是與傳輸層無關(guān)的：ZeroMQ套接字對(duì)所有傳輸層協(xié)議定義了統(tǒng)一的API接口。默認(rèn)支持 進(jìn)程內(nèi)(inproc) ，進(jìn)程間(IPC) ，多播，TCP協(xié)議，在不同的協(xié)議之間切換只要簡(jiǎn)單的改變連接字符串的前綴?？梢栽谌魏螘r(shí)候以最小的代價(jià)從進(jìn)程間的本地通信切換到分布式下的TCP通信。ZeroMQ在背后處理連接建立，斷開和重連邏輯。

特性：

二、主要消息中間件的比較

新聞標(biāo)題：消息中間件nosql對(duì)比的簡(jiǎn)單介紹
文章地址：http://chinadenli.net/article44/dseoche.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、自適應(yīng)網(wǎng)站、網(wǎng)站營(yíng)銷、云服務(wù)器、靜態(tài)網(wǎng)站、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)