這次的NoSQL專欄系列將先整體介紹NoSQL，然后介紹如何把NoSQL運用到自己的項目中合適的場景中，還會適當(dāng)?shù)胤治鲆恍┏晒Π咐Ｍ谐晒κ褂肗oSQL經(jīng)驗的朋友給我提供一些線索和信息。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：空間域名、網(wǎng)站空間、營銷軟件、網(wǎng)站建設(shè)、讓胡路網(wǎng)站維護、網(wǎng)站推廣。
NoSQL概念隨著web2.0的快速發(fā)展，非關(guān)系型、分布式數(shù)據(jù)存儲得到了快速的發(fā)展，它們不保證關(guān)系數(shù)據(jù)的ACID特性。NoSQL概念在2009年被提了出來。NoSQL最常見的解釋是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一詞最早于1998年被用于一個輕量級的關(guān)系數(shù)據(jù)庫的名字。）
NoSQL被我們用得最多的當(dāng)數(shù)key-value存儲，當(dāng)然還有其他的文檔型的、列存儲、圖型數(shù)據(jù)庫、xml數(shù)據(jù)庫等。在NoSQL概念提出之前，這些數(shù)據(jù)庫就被用于各種系統(tǒng)當(dāng)中，但是卻很少用于web互聯(lián)網(wǎng)應(yīng)用。比如cdb、qdbm、bdb數(shù)據(jù)庫。
傳統(tǒng)關(guān)系數(shù)據(jù)庫的瓶頸
傳統(tǒng)的關(guān)系數(shù)據(jù)庫具有不錯的性能，高穩(wěn)定型，久經(jīng)歷史考驗，而且使用簡單，功能強大，同時也積累了大量的成功案例。在互聯(lián)網(wǎng)領(lǐng)域，MySQL成為了絕對靠前的王者，毫不夸張的說，MySQL為互聯(lián)網(wǎng)的發(fā)展做出了卓越的貢獻。
在90年代，一個網(wǎng)站的訪問量一般都不大，用單個數(shù)據(jù)庫完全可以輕松應(yīng)付。在那個時候，更多的都是靜態(tài)網(wǎng)頁，動態(tài)交互類型的網(wǎng)站不多。
到了最近10年，網(wǎng)站開始快速發(fā)展?；鸨恼搲⒉┛?、sns、微博逐漸引領(lǐng)web領(lǐng)域的潮流。在初期，論壇的流量其實也不大，如果你接觸網(wǎng)絡(luò)比較早，你可能還記得那個時候還有文本型存儲的論壇程序，可以想象一般的論壇的流量有多大。
Memcached+MySQL
后來，隨著訪問量的上升，幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫上都開始出現(xiàn)了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術(shù)來緩解數(shù)據(jù)庫的壓力，優(yōu)化數(shù)據(jù)庫的結(jié)構(gòu)和索引。開始比較流行的是通過文件緩存來緩解數(shù)據(jù)庫壓力，但是當(dāng)訪問量繼續(xù)增大的時候，多臺web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術(shù)產(chǎn)品。
Memcached作為一個獨立的分布式的緩存服務(wù)器，為多個web服務(wù)器提供了一個共享的高性能緩存服務(wù)，在Memcached服務(wù)器上，又發(fā)展了根據(jù)hash算法來進行多臺Memcached緩存服務(wù)的擴展，然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務(wù)器導(dǎo)致重新hash帶來的大量緩存失效的弊端。當(dāng)時，如果你去面試，你說你有Memcached經(jīng)驗，肯定會加分的。
Mysql主從讀寫分離
由于數(shù)據(jù)庫的寫入壓力增加，Memcached只能緩解數(shù)據(jù)庫的讀取壓力。讀寫集中在一個數(shù)據(jù)庫上讓數(shù)據(jù)庫不堪重負(fù)，大部分網(wǎng)站開始使用主從復(fù)制技術(shù)來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網(wǎng)站標(biāo)配了。
分表分庫隨著web2.0的繼續(xù)高速發(fā)展，在Memcached的高速緩存，MySQL的主從復(fù)制，讀寫分離的基礎(chǔ)之上，這時MySQL主庫的寫壓力開始出現(xiàn)瓶頸，而數(shù)據(jù)量的持續(xù)猛增，由于MyISAM使用表鎖，在高并發(fā)下會出現(xiàn)嚴(yán)重的鎖問題，大量的高并發(fā)MySQL應(yīng)用開始使用InnoDB引擎代替MyISAM。同時，開始流行使用分表分庫來緩解寫壓力和數(shù)據(jù)增長的擴展問題。這個時候，分表分庫成了一個熱門技術(shù)，是面試的熱門問題也是業(yè)界討論的熱門技術(shù)問題。也就在這個時候，MySQL推出了還不太穩(wěn)定的表分區(qū)，這也給技術(shù)實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但是由于在互聯(lián)網(wǎng)幾乎沒有成功案例，性能也不能滿足互聯(lián)網(wǎng)的要求，只是在高可靠性上提供了非常大的保證。
MySQL的擴展性瓶頸
在互聯(lián)網(wǎng)，大部分的MySQL都應(yīng)該是IO密集型的，事實上，如果你的MySQL是個CPU密集型的話，那么很可能你的MySQL設(shè)計得有性能問題，需要優(yōu)化了。大數(shù)據(jù)量高并發(fā)環(huán)境下的MySQL應(yīng)用開發(fā)越來越復(fù)雜，也越來越具有技術(shù)挑戰(zhàn)性。分表分庫的規(guī)則把握都是需要經(jīng)驗的。雖然有像淘寶這樣技術(shù)實力強大的公司開發(fā)了透明的中間件層來屏蔽開發(fā)者的復(fù)雜性，但是避免不了整個架構(gòu)的復(fù)雜性。分庫分表的子庫到一定階段又面臨擴展問題。還有就是需求的變更，可能又需要一種新的分庫方式。
MySQL數(shù)據(jù)庫也經(jīng)常存儲一些大文本字段，導(dǎo)致數(shù)據(jù)庫表非常的大，在做數(shù)據(jù)庫恢復(fù)的時候就導(dǎo)致非常的慢，不容易快速恢復(fù)數(shù)據(jù)庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數(shù)據(jù)從MySQL省去，MySQL將變得非常的小。
關(guān)系數(shù)據(jù)庫很強大，但是它并不能很好的應(yīng)付所有的應(yīng)用場景。MySQL的擴展性差（需要復(fù)雜的技術(shù)來實現(xiàn)），大數(shù)據(jù)下IO壓力大，表結(jié)構(gòu)更改困難，正是當(dāng)前使用MySQL的開發(fā)人員面臨的問題。
NOSQL的優(yōu)勢易擴展NoSQL數(shù)據(jù)庫種類繁多，但是一個共同的特點都是去掉關(guān)系數(shù)據(jù)庫的關(guān)系型特性。數(shù)據(jù)之間無關(guān)系，這樣就非常容易擴展。也無形之間，在架構(gòu)的層面上帶來了可擴展的能力。
大數(shù)據(jù)量，高性能
NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關(guān)系性，數(shù)據(jù)庫的結(jié)構(gòu)簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應(yīng)用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。
靈活的數(shù)據(jù)模型
NoSQL無需事先為要存儲的數(shù)據(jù)建立字段，隨時可以存儲自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫里，增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡直就是一個噩夢。這點在大數(shù)據(jù)量的web2.0時代尤其明顯。
高可用NoSQL在不太影響性能的情況，就可以方便的實現(xiàn)高可用的架構(gòu)。比如Cassandra，HBase模型，通過復(fù)制模型也能實現(xiàn)高可用。
總結(jié)NoSQL數(shù)據(jù)庫的出現(xiàn)，彌補了關(guān)系數(shù)據(jù)（比如MySQL）在某些方面的不足，在某些方面能極大的節(jié)省開發(fā)成本和維護成本。
MySQL和NoSQL都有各自的特點和使用的應(yīng)用場景，兩者的緊密結(jié)合將會給web2.0的數(shù)據(jù)庫發(fā)展帶來新的思路。
一、消息中間件相關(guān)知識
1、概述
消息隊列已經(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
消息消費者，業(yè)務(wù)的處理方，負(fù)責(zé)從broker獲取消息并進行業(yè)務(wù)邏輯處理
2.4 Topic
2.5 Queue
2.6 Message
消息體，根據(jù)不同通信協(xié)議定義的固定格式進行編碼的數(shù)據(jù)包，來封裝業(yè)務(wù)數(shù)據(jù)，實現(xiàn)消息的傳輸
3 消息中間件模式分類
3.1 點對點
PTP點對點:使用queue作為通信載體
說明：
消息生產(chǎn)者生產(chǎn)消息發(fā)送到queue中，然后消息消費者從queue中取出并且消費消息。
消息被消費以后，queue中不再存儲，所以消息消費者不可能消費到已經(jīng)被消費的消息。 Queue支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。
說明：
queue實現(xiàn)了負(fù)載均衡，將producer生產(chǎn)的消息發(fā)送到消息隊列中，由多個消費者消費。但一個消息只能被一個消費者接受，當(dāng)沒有消費者可用時，這個消息會被保存直到有一個可用的消費者。
4 消息中間件的優(yōu)勢
4.1 系統(tǒng)解耦
交互系統(tǒng)之間沒有直接的調(diào)用關(guān)系，只是通過消息傳輸，故系統(tǒng)侵入性不強，耦合度低。
4.2 提高系統(tǒng)響應(yīng)時間
例如原來的一套邏輯，完成支付可能涉及先修改訂單狀態(tài)、計算會員積分、通知物流配送幾個邏輯才能完成；通過MQ架構(gòu)設(shè)計，就可將緊急重要（需要立刻響應(yīng)）的業(yè)務(wù)放到該調(diào)用方法中，響應(yīng)要求不高的使用消息隊列，放到MQ隊列中，供消費者處理。
4.3 為大數(shù)據(jù)處理架構(gòu)提供服務(wù)
通過消息作為整合，大數(shù)據(jù)的背景下，消息隊列還與實時處理架構(gòu)整合，為數(shù)據(jù)處理提供性能支持。
4.4 Java消息服務(wù)——JMS
Java消息服務(wù)（Java Message Service，JMS）應(yīng)用程序接口是一個Java平臺中關(guān)于面向消息中間件（MOM）的API，用于在兩個應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進行異步通信。
5 消息中間件應(yīng)用場景
5.1 異步通信
有些業(yè)務(wù)不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。
5.2 解耦
降低工程間的強依賴程度，針對異構(gòu)系統(tǒng)進行適配。在項目啟動之初來預(yù)測將來項目會碰到什么需求，是極其困難的。通過消息系統(tǒng)在處理過程中間插入了一個隱含的、基于數(shù)據(jù)的接口層，兩邊的處理過程都要實現(xiàn)這一接口，當(dāng)應(yīng)用發(fā)生變化時，可以獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。
5.3 冗余
有些情況下，處理數(shù)據(jù)的過程會失敗。除非數(shù)據(jù)被持久化，否則將造成丟失。消息隊列把數(shù)據(jù)進行持久化直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險。許多消息隊列所采用的”插入-獲取-刪除”范式中，在把一個消息從隊列中刪除之前，需要你的處理系統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)據(jù)被安全的保存直到你使用完畢。
5.4 擴展性
因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調(diào)節(jié)參數(shù)。便于分布式擴容。
5.5 過載保護
在訪問量劇增的情況下，應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量無法提取預(yù)知；如果以為了能處理這類瞬間峰值訪問為標(biāo)準(zhǔn)來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關(guān)鍵組件頂住突發(fā)的訪問壓力，而不會因為突發(fā)的超負(fù)荷的請求而完全崩潰。
5.6 可恢復(fù)性
系統(tǒng)的一部分組件失效時，不會影響到整個系統(tǒng)。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。
5.7 順序保證
在大多使用場景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數(shù)據(jù)會按照特定的順序來處理。
5.8 緩沖
在任何重要的系統(tǒng)中，都會有需要不同的處理時間的元素。消息隊列通過一個緩沖層來幫助任務(wù)最高效率的執(zhí)行，該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度。以調(diào)節(jié)系統(tǒng)響應(yīng)時間。
5.9 數(shù)據(jù)流處理
分布式系統(tǒng)產(chǎn)生的海量數(shù)據(jù)流，如：業(yè)務(wù)日志、監(jiān)控數(shù)據(jù)、用戶行為等，針對這些數(shù)據(jù)流進行實時或批量采集匯總，然后進行大數(shù)據(jù)分析是當(dāng)前互聯(lián)網(wǎng)的必備技術(shù)，通過消息隊列完成此類數(shù)據(jù)收集是最好的選擇。
6 消息中間件常用協(xié)議
6.1 AMQP協(xié)議
AMQP即Advanced Message Queuing Protocol,一個提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn)高級消息隊列協(xié)議,是應(yīng)用層協(xié)議的一個開放標(biāo)準(zhǔn),為面向消息的中間件設(shè)計?；诖藚f(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品，不同開發(fā)語言等條件的限制。
優(yōu)點：可靠、通用
6.2 MQTT協(xié)議
MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發(fā)的一個即時通訊協(xié)議，有可能成為物聯(lián)網(wǎng)的重要組成部分。該協(xié)議支持所有平臺，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，被用來當(dāng)做傳感器和致動器（比如通過Twitter讓房屋聯(lián)網(wǎng)）的通信協(xié)議。
優(yōu)點：格式簡潔、占用帶寬小、移動端通信、PUSH、嵌入式系統(tǒng)
6.3 STOMP協(xié)議
STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協(xié)議，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設(shè)計的簡單文本協(xié)議。STOMP提供一個可互操作的連接格式，允許客戶端與任意STOMP消息代理（Broker）進行交互。
優(yōu)點：命令模式（非topic\queue模式）
6.4 XMPP協(xié)議
XMPP（可擴展消息處理現(xiàn)場協(xié)議，Extensible Messaging and Presence Protocol）是基于可擴展標(biāo)記語言（XML）的協(xié)議，多用于即時消息（IM）以及在線現(xiàn)場探測。適用于服務(wù)器之間的準(zhǔn)即時操作。核心是基于XML流傳輸，這個協(xié)議可能最終允許因特網(wǎng)用戶向因特網(wǎng)上的其他任何人發(fā)送即時消息，即使其操作系統(tǒng)和瀏覽器不同。
優(yōu)點：通用公開、兼容性強、可擴展、安全性高，但XML編碼格式占用帶寬大
6.5 其他基于TCP/IP自定義的協(xié)議
有些特殊框架（如：redis、kafka、zeroMq等）根據(jù)自身需要未嚴(yán)格遵循MQ規(guī)范，而是基于TCP\IP自行封裝了一套協(xié)議，通過網(wǎng)絡(luò)socket接口進行傳輸，實現(xiàn)了MQ的功能。
7 常見消息中間件MQ介紹
7.1 RocketMQ
阿里系下開源的一款分布式、隊列模型的消息中間件，原名Metaq，3.0版本名稱改為RocketMQ，是阿里參照kafka設(shè)計思想使用java實現(xiàn)的一套mq。同時將阿里系內(nèi)部多款mq產(chǎn)品（Notify、metaq）進行整合，只維護核心功能，去除了所有其他運行時依賴，保證核心功能最簡化，在此基礎(chǔ)上配合阿里上述其他開源產(chǎn)品實現(xiàn)不同場景下mq的架構(gòu)，目前主要多用于訂單交易系統(tǒng)。
具有以下特點：
官方提供了一些不同于kafka的對比差異：
7.2 RabbitMQ
使用Erlang編寫的一個開源的消息隊列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它變的非常重量級，更適合于企業(yè)級的開發(fā)。同時實現(xiàn)了Broker架構(gòu)，核心思想是生產(chǎn)者不會將消息直接發(fā)送給隊列，消息在發(fā)送給客戶端時先在中心隊列排隊。對路由(Routing)，負(fù)載均衡(Load balance)、數(shù)據(jù)持久化都有很好的支持。多用于進行企業(yè)級的ESB整合。
7.3 ActiveMQ
Apache下的一個子項目。使用Java完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實現(xiàn)，少量代碼就可以高效地實現(xiàn)高級應(yīng)用場景?？刹灏蔚膫鬏攨f(xié)議支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。
7.4 Redis
使用C語言開發(fā)的一個Key-Value的NoSQL數(shù)據(jù)庫，開發(fā)維護很活躍，雖然它是一個Key-Value數(shù)據(jù)庫存儲系統(tǒng)，但它本身支持MQ功能，所以完全可以當(dāng)做一個輕量級的隊列服務(wù)來使用。對于RabbitMQ和Redis的入隊和出隊操作，各執(zhí)行100萬次，每10萬次記錄一次執(zhí)行時間。測試數(shù)據(jù)分為128Bytes、512Bytes、1K和10K四個不同大小的數(shù)據(jù)。實驗表明：入隊時，當(dāng)數(shù)據(jù)比較小時Redis的性能要高于RabbitMQ，而如果數(shù)據(jù)大小超過了10K，Redis則慢的無法忍受；出隊時，無論數(shù)據(jù)大小，Redis都表現(xiàn)出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。
7.5 Kafka
Apache下的一個子項目，使用scala實現(xiàn)的一個高性能分布式Publish/Subscribe消息隊列系統(tǒng)，具有以下特性：
7.6 ZeroMQ
號稱最快的消息隊列系統(tǒng)，專門為高吞吐量/低延遲的場景開發(fā)，在金融界的應(yīng)用中經(jīng)常使用，偏重于實時數(shù)據(jù)通信場景。ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長的高級/復(fù)雜的隊列，但是開發(fā)人員需要自己組合多種技術(shù)框架，開發(fā)成本高。因此ZeroMQ具有一個獨特的非中間件的模式，更像一個socket library，你不需要安裝和運行一個消息服務(wù)器或中間件，因為你的應(yīng)用程序本身就是使用ZeroMQ API完成邏輯服務(wù)的角色。但是ZeroMQ僅提供非持久性的隊列，如果down機，數(shù)據(jù)將會丟失。如：Twitter的Storm中使用ZeroMQ作為數(shù)據(jù)流的傳輸。
ZeroMQ套接字是與傳輸層無關(guān)的：ZeroMQ套接字對所有傳輸層協(xié)議定義了統(tǒng)一的API接口。默認(rèn)支持 進程內(nèi)(inproc) ，進程間(IPC) ，多播，TCP協(xié)議，在不同的協(xié)議之間切換只要簡單的改變連接字符串的前綴?？梢栽谌魏螘r候以最小的代價從進程間的本地通信切換到分布式下的TCP通信。ZeroMQ在背后處理連接建立，斷開和重連邏輯。
特性：
二、主要消息中間件的比較
一、分庫分表的必要性
分庫分表技術(shù)的使用，主要是數(shù)據(jù)庫產(chǎn)生了瓶頸，如單庫的并發(fā)訪問或單表的查詢都超出了閾值。對系統(tǒng)使用造成一定的影響，不得已而產(chǎn)生的技術(shù)。
通過分庫分表技術(shù)來解決此類問題，但正因為使用此技術(shù)，會產(chǎn)生ACID一系列的問題，各類中間件解決此類問題各有各的優(yōu)勢。
提示：如場景無必要，千萬不要使用分庫分表。
二、分庫分表的思路
1、垂直區(qū)分
垂直分庫：從業(yè)務(wù)角度，一個庫分成多個庫，如把訂單和用戶信息分成兩個庫來存儲。這樣的好處就是可以微服務(wù)了。每塊的業(yè)務(wù)單獨部署，互不影響，通過接口去調(diào)用。
垂直分表：把大表分成多個小表，如熱點數(shù)據(jù)和非熱點數(shù)據(jù)分開，提高查詢速度。
2、水平區(qū)分
水平分表：同一業(yè)務(wù)如數(shù)據(jù)量大了以后，根據(jù)一定的規(guī)則分為不同的表進行存儲。
水平分庫：如訂單分成多個庫存儲，分解服務(wù)器壓力。
以上一般來說，垂直分庫和水平分表用的會多些。
三、分庫分表的原理分析
分庫分表常用的方案：Hash取模方案和range范圍方案；
路由算法為最主要的算法，指得是把路由的Key按照指定的算法進行存放；
1、Hash取模方案
根據(jù)取余分配到不同的表里。要根據(jù)實際情況確認(rèn)模的大小。此方案由于平均分配，不存在熱點問題，但數(shù)據(jù)遷移很復(fù)雜。
2、Range范圍方案
range根據(jù)范圍進行劃分，如日期，大小。此方案不存在數(shù)據(jù)遷移，但存在熱點問題。
四、分庫分表的技術(shù)選型
1、技術(shù)選型
解決方案主要分為4種：MySQL的分區(qū)技術(shù)、NoSql、NewSQL、MySQL的分庫分表。
（1）mysql分區(qū)技術(shù)：把一張表存放在不同存儲文件。由于無法負(fù)載，使用較少。
（2）NoSQL（如MongoDB）：如是訂單等比較重要數(shù)據(jù)，強關(guān)聯(lián)關(guān)系，需約束一致性，不太適應(yīng)。
（3）NewSql(具有NoSQL對海量數(shù)據(jù)的存儲管理能力，還保持了傳統(tǒng)數(shù)據(jù)庫支持ACID和SQL等特性):如TiDB可滿足需求。
（4）MySQL的分庫分表：如使用mysql,此種方案為主流方式。
2、中間件
解決此類問題的中間件主要為：Proxy模式、Client模式。
（1）Proxy模式
（2）Client模式
把分庫分表相關(guān)邏輯存放在客戶端，一版客戶端的應(yīng)用會引用一個jar，然后再jar中處理SQL組合、數(shù)據(jù)庫路由、執(zhí)行結(jié)果合并等相關(guān)功能。
（3）中間件的比較
由于Client模式少了一層，運維方便，相對來說容易些。
五、分庫分表的實踐
根據(jù)容量（當(dāng)前容量和增長量）評估分庫或分表個數(shù) - 選key（均勻）- 分表規(guī)則（hash或range等）- 執(zhí)行（一般雙寫）- 擴容問題（盡量減少數(shù)據(jù)的移動）。
在這里我們選用中間件share-jdbc。
1、引入maven依賴
2、spring boot規(guī)則配置
行表達式標(biāo)識符可以使用${...}或$-{...}，但前者與Spring本身的屬性文件占位符沖突，因此在Spring環(huán)境中使用行表達式標(biāo)識符建議使用$-{...}。
3、創(chuàng)建DataSource
通過ShardingDataSourceFactory工廠和規(guī)則配置對象獲取ShardingDataSource，ShardingDataSource實現(xiàn)自JDBC的標(biāo)準(zhǔn)接口DataSource。然后即可通過DataSource選擇使用原生JDBC開發(fā)，或者使用JPA, MyBatis等ORM工具。
在大數(shù)據(jù)時代，“多種架構(gòu)支持多類應(yīng)用”成為數(shù)據(jù)庫行業(yè)應(yīng)對大數(shù)據(jù)的基本思路，數(shù)據(jù)庫行業(yè)出現(xiàn)互為補充的三大陣營，適用于事務(wù)處理應(yīng)用的OldSQL、適用于數(shù)據(jù)分析應(yīng)用的NewSQL和適用于互聯(lián)網(wǎng)應(yīng)用的NoSQL。但在一些復(fù)雜的應(yīng)用場景中，單一數(shù)據(jù)庫架構(gòu)都不能完全滿足應(yīng)用場景對海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的存儲管理、復(fù)雜分析、關(guān)聯(lián)查詢、實時性處理和控制建設(shè)成本等多方面的需要，因此不同架構(gòu)數(shù)據(jù)庫混合部署應(yīng)用成為滿足復(fù)雜應(yīng)用的必然選擇。不同架構(gòu)數(shù)據(jù)庫混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個案例對不同架構(gòu)數(shù)據(jù)庫的混合應(yīng)用部署進行介紹。
OldSQL+NewSQL 在數(shù)據(jù)中心類應(yīng)用中混合部署
采用OldSQL+NewSQL模式構(gòu)建數(shù)據(jù)中心，在充分發(fā)揮OldSQL數(shù)據(jù)庫的事務(wù)處理能力的同時，借助NewSQL在實時性、復(fù)雜分析、即席查詢等方面的獨特優(yōu)勢，以及面對海量數(shù)據(jù)時較強的擴展能力，滿足數(shù)據(jù)中心對當(dāng)前“熱”數(shù)據(jù)事務(wù)型處理和海量歷史“冷”數(shù)據(jù)分析兩方面的需求。OldSQL+NewSQL模式在數(shù)據(jù)中心類應(yīng)用中的互補作用體現(xiàn)在，OldSQL彌補了NewSQL不適合事務(wù)處理的不足，NewSQL彌補了OldSQL在海量數(shù)據(jù)存儲能力和處理性能方面的缺陷。
商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL數(shù)據(jù)庫滿足各業(yè)務(wù)系統(tǒng)數(shù)據(jù)的歸檔備份和事務(wù)型應(yīng)用，NewSQL MPP數(shù)據(jù)庫集群對即席查詢、多維分析等應(yīng)用提供高性能支持，并且通過MPP集群架構(gòu)實現(xiàn)應(yīng)對海量數(shù)據(jù)存儲的擴展能力。
商業(yè)銀行數(shù)據(jù)中心存儲架構(gòu)
與傳統(tǒng)的OldSQL模式相比，商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合搭建模式，數(shù)據(jù)加載性能提升3倍以上，即席查詢和統(tǒng)計分析性能提升6倍以上。NewSQL MPP的高可擴展性能夠應(yīng)對新的業(yè)務(wù)需求，可隨著數(shù)據(jù)量的增長采用集群方式構(gòu)建存儲容量更大的數(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)用對海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)進行存儲和快速處理的需求。在諸如大型電子商務(wù)平臺、大型SNS平臺等互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用場景中，OldSQL在應(yīng)用中負(fù)責(zé)高價值密度結(jié)構(gòu)化數(shù)據(jù)的存儲和事務(wù)型處理，NoSQL在應(yīng)用中負(fù)責(zé)存儲和處理海量非結(jié)構(gòu)化的數(shù)據(jù)和低價值密度結(jié)構(gòu)化數(shù)據(jù)。OldSQL+NoSQL模式在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中的互補作用體現(xiàn)在，OldSQL彌補了NoSQL在ACID特性和復(fù)雜關(guān)聯(lián)運算方面的不足，NoSQL彌補了OldSQL在海量數(shù)據(jù)存儲和非結(jié)構(gòu)化數(shù)據(jù)處理方面的缺陷。
數(shù)據(jù)魔方是淘寶網(wǎng)的一款數(shù)據(jù)產(chǎn)品，主要提供行業(yè)數(shù)據(jù)分析、店鋪數(shù)據(jù)分析。淘寶數(shù)據(jù)產(chǎn)品在存儲層采用OldSQL+NoSQL混合模式，由基于MySQL的分布式關(guān)系型數(shù)據(jù)庫集群MyFOX和基于HBase的NoSQL存儲集群Prom組成。由于OldSQL強大的語義和關(guān)系表達能力，在應(yīng)用中仍然占據(jù)著重要地位，目前存儲在MyFOX中的統(tǒng)計結(jié)果數(shù)據(jù)已經(jīng)達到10TB，占據(jù)著數(shù)據(jù)魔方總數(shù)據(jù)量的95%以上。另一方面，NoSQL作為SQL的有益補充，解決了OldSQL數(shù)據(jù)庫無法解決的全屬性選擇器等問題。
淘寶海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)
基于OldSQL+NoSQL混合架構(gòu)的特點，數(shù)據(jù)魔方目前已經(jīng)能夠提供壓縮前80TB的數(shù)據(jù)存儲空間，支持每天4000萬的查詢請求，平均響應(yīng)時間在28毫秒，足以滿足未來一段時間內(nèi)的業(yè)務(wù)增長需求。
NewSQL+NoSQL 在行業(yè)大數(shù)據(jù)應(yīng)用中混合部署
行業(yè)大數(shù)據(jù)與互聯(lián)網(wǎng)大數(shù)據(jù)的區(qū)別在于行業(yè)大數(shù)據(jù)的價值密度更高，并且對結(jié)構(gòu)化數(shù)據(jù)的實時處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強一致性等都比互聯(lián)網(wǎng)大數(shù)據(jù)有更高的要求。行業(yè)大數(shù)據(jù)應(yīng)用場景主要是分析類應(yīng)用，如：電信、金融、政務(wù)、能源等行業(yè)的決策輔助、預(yù)測預(yù)警、統(tǒng)計分析、經(jīng)營分析等。
在行業(yè)大數(shù)據(jù)應(yīng)用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在結(jié)構(gòu)化數(shù)據(jù)分析處理方面的優(yōu)勢，以及NoSQL在非結(jié)構(gòu)數(shù)據(jù)處理方面的優(yōu)勢，實現(xiàn)NewSQL與NoSQL的功能互補，解決行業(yè)大數(shù)據(jù)應(yīng)用對高價值結(jié)構(gòu)化數(shù)據(jù)的實時處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強一致性等要求，以及對海量非結(jié)構(gòu)化數(shù)據(jù)存儲和精確查詢的要求。在應(yīng)用中，NewSQL承擔(dān)高價值密度結(jié)構(gòu)化數(shù)據(jù)的存儲和分析處理工作，NoSQL承擔(dān)存儲和處理海量非結(jié)構(gòu)化數(shù)據(jù)和不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的低價值密度結(jié)構(gòu)化數(shù)據(jù)的工作。
當(dāng)前電信運營商在集中化BI系統(tǒng)建設(shè)過程中面臨著數(shù)據(jù)規(guī)模大、數(shù)據(jù)處理類型多等問題，并且需要應(yīng)對大量的固定應(yīng)用，以及占統(tǒng)計總數(shù)80%以上的突發(fā)性臨時統(tǒng)計(ad-hoc)需求。在集中化BI系統(tǒng)的建設(shè)中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復(fù)雜分析、即席查詢等方面處理性能的優(yōu)勢，及NoSQL在非結(jié)構(gòu)化數(shù)據(jù)處理和海量數(shù)據(jù)存儲方面的優(yōu)勢，實現(xiàn)高效低成本。
集中化BI系統(tǒng)數(shù)據(jù)存儲架構(gòu)
集中化BI系統(tǒng)按照數(shù)據(jù)類型和處理方式的不同，將結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)分別存儲在不同的系統(tǒng)中：非結(jié)構(gòu)化數(shù)據(jù)在Hadoop平臺上存儲與處理;結(jié)構(gòu)化、不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的數(shù)據(jù)保存在NoSQL數(shù)據(jù)庫或Hadoop平臺;結(jié)構(gòu)化、需要關(guān)聯(lián)分析或經(jīng)常ad-hoc查詢的數(shù)據(jù)，保存在NewSQL MPP數(shù)據(jù)庫中，短期高價值數(shù)據(jù)放在高性能平臺，中長期放在低成本產(chǎn)品中。
結(jié)語
當(dāng)前信息化應(yīng)用的多樣性、復(fù)雜性，以及三種數(shù)據(jù)庫架構(gòu)各自所具有的優(yōu)勢和局限性，造成任何一種架構(gòu)的數(shù)據(jù)庫都不能完全滿足應(yīng)用需求，因此不同架構(gòu)數(shù)據(jù)庫混合使用，從而彌補其他架構(gòu)的不足成為必然選擇。根據(jù)應(yīng)用場景采用不同架構(gòu)數(shù)據(jù)庫進行組合搭配，充分發(fā)揮每種架構(gòu)數(shù)據(jù)庫的特點和優(yōu)勢，并且與其他架構(gòu)數(shù)據(jù)庫形成互補，完全涵蓋應(yīng)用需求，保證數(shù)據(jù)資源的最優(yōu)化利用，將成為未來一段時期內(nèi)信息化應(yīng)用主要采用的解決方式。
目前在國內(nèi)市場上，OldSQL主要為Oracle、IBM等國外數(shù)據(jù)庫廠商所壟斷，達夢、金倉等國產(chǎn)廠商仍處于追趕狀態(tài);南大通用憑借國產(chǎn)新型數(shù)據(jù)庫GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強;NoSQL方面用戶則大多采用Hadoop開源方案。
云計算架構(gòu)主要可分為四層，其中有三層是橫向的，分別是顯示層、中間件層和基礎(chǔ)設(shè)施層，通過這三層技術(shù)能夠提供非常豐富的云計算能力和友好的用戶界面，還有一層是縱向的，稱為管理層，是為了更好地管理和維護橫向的三層而存在的。下面介紹每個層次的作用和屬于這個層次的主要技術(shù)。
顯示層
這層主要是用于以友好的方式展現(xiàn)用戶所需的內(nèi)容，并會利用到下面中間件層提供的多種服務(wù)，主要有五種技術(shù)：
HTML：標(biāo)準(zhǔn)的Web頁面技術(shù)，現(xiàn)在主要以HTML4為主，但是將要推出的HTML5會在很多方面推動Web頁面的發(fā)展，比如視頻和本地存儲等方面。
JavaScript：一種用于Web頁面的動態(tài)語言，通過JavaScript，能夠極大地豐富Web頁面的功能，最流行的JS框架有jQuery和Prototype。
CSS：主要用于控制Web頁面的外觀，而且能使頁面的內(nèi)容與其表現(xiàn)形式之間進行優(yōu)雅地分離。
Flash：業(yè)界最常用的RIA(Rich Internet Applications)技術(shù)，能夠在現(xiàn)階段提供HTML等技術(shù)所無法提供的基于Web的富應(yīng)用，而且在用戶體驗方面，非常不錯。
Silverlight：來自業(yè)界巨擎微軟的RIA技術(shù)，雖然其現(xiàn)在市場占有率稍遜于Flash，但由于其可以使用C#來進行編程，所以對開發(fā)者非常友好。
在顯示層，大多數(shù)云計算產(chǎn)品都比較傾向HTML，、JavaScript和CSS這對黃金組合，但是Flash和Silverlight等RIA技 術(shù)也有一定的用武之地，比如VMware vCloud就采用了基于Flash的Flex技術(shù)，而微軟的云計算產(chǎn)品肯定會在今后使用到Silverlight。
中間件層
這層是承上啟下的，它在下面的基礎(chǔ)設(shè)施層所提供資源的基礎(chǔ)上提供了多種服務(wù)，比如緩存服務(wù)和REST服務(wù)等，而且這些服務(wù)即可用于支撐顯示層，也可以直接讓用戶調(diào)用，并主要有五種技術(shù)：
REST：通過REST技術(shù)，能夠非常方便和優(yōu)雅地將中間件層所支撐的部分服務(wù)提供給調(diào)用者。
多租戶：就是能讓一個單獨的應(yīng)用實例可以為多個組織服務(wù)，而且保持良好的隔離性和安全性，并且通過這種技術(shù)，能有效地降低應(yīng)用的購置和維護成本。
并行處理：為了處理海量的數(shù)據(jù)，需要利用龐大的X86集群進行規(guī)模巨大的并行處理，Google的MapReduce是這方面的代表之作。
應(yīng)用服務(wù)器：在原有的應(yīng)用服務(wù)器的基礎(chǔ)上為云計算做了一定程度的優(yōu)化，比如用于Google App Engine的Jetty應(yīng)用服務(wù)器。
分布式緩存：通過分布式緩存技術(shù)，不僅能有效地降低對后臺服務(wù)器的壓力，而且還能加快相應(yīng)的反應(yīng)速度，最著名的分布式緩存例子莫過于Memcached。
對于很多PaaS平臺，比如用于部署Ruby應(yīng)用的Heroku云平臺，應(yīng)用服務(wù)器和分布式緩存都是必備的，同時REST技術(shù)也常用于對外的接口， 多租戶技術(shù)則主要用于SaaS應(yīng)用的后臺，比如用于支撐Salesforce的Sales Cloud等應(yīng)用的Force.com多租戶內(nèi)核，而并行處理技術(shù)常被作為單獨的服務(wù)推出，比如Amazon的Elastic MapReduce。
基礎(chǔ)設(shè)施層
這層作用是為給上面的中間件層或者用戶準(zhǔn)備其所需的計算和存儲等資源，主要有四種技術(shù)：
虛擬化：也可以理解它為基礎(chǔ)設(shè)施層的“多租戶”，因為通過虛擬化技術(shù)，能夠在一個物理服務(wù)器上生成多個虛擬 機，并且能在這些虛擬機之間能實現(xiàn)全面的隔離，這樣不僅能減低服務(wù)器的購置成本，而且還能同時降低服務(wù)器的運維成本，成熟的X86虛擬化技術(shù)有 VMware的ESX和開源的Xen。
分布式存儲：為了承載海量的數(shù)據(jù)，同時也要保證這些數(shù)據(jù)的可管理性，所以需要一整套分布式的存儲系統(tǒng)，在這方面，Google的GFS是典范之作。
關(guān)系型數(shù)據(jù)庫：基本是在原有的關(guān)系型數(shù)據(jù)庫的基礎(chǔ)上做了擴展和管理等方面的優(yōu)化，使其在云中更適應(yīng)。
NoSQL：為了滿足一些關(guān)系數(shù)據(jù)庫所無法滿足的目標(biāo)，比如支撐海量的數(shù)據(jù)等，一些公司特地設(shè)計一批不是基于關(guān)系模型的數(shù)據(jù)庫，比如Google的BigTable和Facebook的Cassandra等。
現(xiàn)在大多數(shù)的IaaS服務(wù)都是基于Xen的，比如Amazon的EC2等，但VMware也推出了基于ESX技術(shù)的vCloud，同時業(yè)界也有幾個 基于關(guān)系型數(shù)據(jù)庫的云服務(wù)，比如Amazon的RDS(Relational Database Service)和Windows Azure SDS(SQL Data Services)等。關(guān)于分布式存儲和NoSQL，它們已經(jīng)被廣泛用于云平臺的后端，比如Google App Engine的Datastore就是基于BigTable和GFS這兩個技術(shù)之上的，而Amazon則推出基于NoSQL技術(shù)的Simple DB。
管理層
這層是為橫向的三層服務(wù)的，并給這三層提供多種管理和維護等方面的技術(shù)，主要有下面這六個方面：
帳號管理：通過良好的帳號管理技術(shù)，能夠在安全的條件下方便用戶地登錄，并方便管理員對帳號的管理。
SLA監(jiān)控：對各個層次運行的虛擬機，服務(wù)和應(yīng)用等進行性能方面的監(jiān)控，以使它們都能在滿足預(yù)先設(shè)定的SLA(Service Level Agreement)的情況下運行。
計費管理：也就是對每個用戶所消耗的資源等進行統(tǒng)計，來準(zhǔn)確地向用戶索取費用。
安全管理：對數(shù)據(jù)，應(yīng)用和帳號等IT資源采取全面地保護，使其免受犯罪分子和惡意程序的侵害。
負(fù)載均衡：通過將流量分發(fā)給一個應(yīng)用或者服務(wù)的多個實例來應(yīng)對突發(fā)情況。 運維管理：主要是使運維操作盡可能地專業(yè)和自動化 ，從而降低云計算中心成本。
負(fù)載均衡：通過將流量分發(fā)給一個應(yīng)用或者服務(wù)的多個實例來應(yīng)對突發(fā)情況。
運維管理：主要是使運維操作盡可能地專業(yè)和自動化，從而降低云計算中心的運維成本。
現(xiàn)在的云計算產(chǎn)品在帳號管理，計費管理和負(fù)載均衡這三個方面大都表現(xiàn)地不錯，在這方面最突出的例子就是Amazon 的EC2，但可惜的是，大多數(shù)產(chǎn)品在SLA監(jiān)控，安全管理和運維管理等方面還有所欠缺。
舉例
接下來，將以Salesforce的Sales Cloud和Google的App Engine這兩個著名的云計算產(chǎn)品為例，來幫助大家理解本文所提到的云計算架構(gòu)：
Salesforce Sales Cloud
也就是之前的Salesforce CRM(客戶關(guān)系管理)，屬于云計算中的SaaS層，主要是通過在云中部署可定制化的CRM應(yīng)用，來讓企業(yè)用戶在很低初始投入的情況下使用上CRM，并且 可根據(jù)自身的流程來進行靈活地定制，而且只需接入網(wǎng)絡(luò)就能使用。在技術(shù)層面上大致的架構(gòu)：
采用的主要技術(shù)：
顯示層：基于HTML、JavaScript和CSS這對黃金組合。
中間件層：在此層，Salesforce引入了多租戶內(nèi)核和為支撐此內(nèi)核運行而經(jīng)過定制的應(yīng)用服務(wù)器。
基礎(chǔ)設(shè)施層：雖然在后端還是使用在企業(yè)環(huán)境中很常見的Oracle數(shù)據(jù)庫，但是其為了支撐上層的多租戶內(nèi)核做了很多的優(yōu)化。
管理層：在安全管理方面，Salesforce提供了多層保護，并支持SSL加密等技術(shù)，除此之外，其還在帳號管理、計費管理和負(fù)載均衡這三方面有不錯地支持。
Google App Engine
App Engine屬于云計算中的PaaS層，其主要提供一個平臺，來讓用戶在Google強大的基礎(chǔ)設(shè)施上部署和運行應(yīng)用程序，同時App Engine會根據(jù)應(yīng)用所承受的負(fù)載來對應(yīng)用所需的資源進行調(diào)整，并免去用戶對應(yīng)用和服務(wù)器等的維護工作，而且支持Java和Python這兩種語言。由 于App Engine屬于PaaS平臺，所以關(guān)于顯示層的技術(shù)選擇由應(yīng)用的自身需要而定，與App Engine無關(guān)，關(guān)于App Engine在技術(shù)層面上大致的架構(gòu)。
采用的主要技術(shù)：
中間件層：既有經(jīng)過定制化的應(yīng)用服務(wù)器，比如上面已經(jīng)提到過的Jetty，也提供基于Memcached的分布式緩存服務(wù)。
基礎(chǔ)設(shè)施層： 在分布式存儲GFS的基礎(chǔ)上提供了NoSQL數(shù)據(jù)庫BigTable來對應(yīng)用的數(shù)據(jù)進行持久化。
管理層：由于App Engine是基于Google強大的分布式基礎(chǔ)設(shè)施，使其在運維管理技術(shù)方面非常出色，同時其計費管理能做到非常細粒度的API級計費，而且App Engine在帳號管理和負(fù)載均衡這兩方面都有非常好地支持。
以上內(nèi)容分析源自O(shè)Fweek物聯(lián)網(wǎng)，希望對大家有幫助。
重慶分公司
重慶分公司
