NoSQL太火，冒出太多產(chǎn)品了，保守估計(jì)也成百上千了。
創(chuàng)新互聯(lián)是一家專(zhuān)注于成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)和綿陽(yáng)電信機(jī)房的網(wǎng)絡(luò)公司，有著豐富的建站經(jīng)驗(yàn)和案例。
互聯(lián)網(wǎng)公司常用的基本集中在以下幾種，每種只舉一個(gè)比較常見(jiàn)或者應(yīng)用比較成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store，同時(shí)提供了更加豐富的數(shù)據(jù)結(jié)構(gòu)和運(yùn)算的能力，成功用法是替代memcached，通過(guò)checkpoint和commit log提供了快速的宕機(jī)恢復(fù)，同時(shí)支持replication提供讀可擴(kuò)展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盤(pán)的key-value storage, 模型單一簡(jiǎn)單，數(shù)據(jù)量不受限于內(nèi)存大小，數(shù)據(jù)落盤(pán)高可靠，Google的幾位大神出品的精品，LSM模型天然寫(xiě)優(yōu)化，順序?qū)懕P(pán)的方式對(duì)于新硬件ssd再適合不過(guò)了，不足是僅提供了一個(gè)庫(kù)，需要自己封裝server端。
3. Document Store: Mongodb
分布式nosql，具備了區(qū)別mysql的最大亮點(diǎn)：可擴(kuò)展性。mongodb 最新引人的莫過(guò)于提供了sql接口，是目前nosql里最像mysql的，只是沒(méi)有ACID的特性，發(fā)展很快，支持了索引等特性，上手容易，對(duì)于數(shù)據(jù)量遠(yuǎn)超內(nèi)存限制的場(chǎng)景來(lái)說(shuō)，還需要慎重。
4. Column Table Store: HBase
這個(gè)富二代似乎不用贅述了，最大的優(yōu)勢(shì)是開(kāi)源，對(duì)于普通的scan和基于行的get等基本查詢(xún)，性能完全不是問(wèn)題，只是只提供裸的api,易用性上是短板，可擴(kuò)展性方面是最強(qiáng)的，其次坐上了Hadoop的快車(chē)，社區(qū)發(fā)展很快，各種基于其上的開(kāi)源產(chǎn)品不少，來(lái)解決諸如join、聚集運(yùn)算等復(fù)雜查詢(xún)。
Redis與Memcached的區(qū)別傳統(tǒng)MySQL+ Memcached架構(gòu)遇到的問(wèn)題實(shí)際MySQL是適合進(jìn)行海量數(shù)據(jù)存儲(chǔ)的，通過(guò)Memcached將熱點(diǎn)數(shù)據(jù)加載到cache，加速訪問(wèn)，很多公司都曾經(jīng)使用過(guò)這樣的架構(gòu)，但隨著業(yè)務(wù)數(shù)據(jù)量的不斷增加，和訪問(wèn)量的持續(xù)增長(zhǎng)，我們遇到了很多問(wèn)題：1.MySQL需要不斷進(jìn)行拆庫(kù)拆表，Memcached也需不斷跟著擴(kuò)容，擴(kuò)容和維護(hù)工作占據(jù)大量開(kāi)發(fā)時(shí)間。2.Memcached與MySQL數(shù)據(jù)庫(kù)數(shù)據(jù)一致性問(wèn)題。3.Memcached數(shù)據(jù)命中率低或down機(jī)，大量訪問(wèn)直接穿透到DB，MySQL無(wú)法支撐。4.跨機(jī)房cache同步問(wèn)題。眾多NoSQL百花齊放，如何選擇最近幾年，業(yè)界不斷涌現(xiàn)出很多各種各樣的NoSQL產(chǎn)品，那么如何才能正確地使用好這些產(chǎn)品，最大化地發(fā)揮其長(zhǎng)處，是我們需要深入研究和思考的問(wèn)題，實(shí)際歸根結(jié)底最重要的是了解這些產(chǎn)品的定位，并且了解到每款產(chǎn)品的tradeoffs，在實(shí)際應(yīng)用中做到揚(yáng)長(zhǎng)避短，總體上這些NoSQL主要用于解決以下幾種問(wèn)題1.少量數(shù)據(jù)存儲(chǔ)，高速讀寫(xiě)訪問(wèn)。此類(lèi)產(chǎn)品通過(guò)數(shù)據(jù)全部in-momery 的方式來(lái)保證高速訪問(wèn)，同時(shí)提供數(shù)據(jù)落地的功能，實(shí)際這正是Redis最主要的適用場(chǎng)景。2.海量數(shù)據(jù)存儲(chǔ)，分布式系統(tǒng)支持，數(shù)據(jù)一致性保證，方便的集群節(jié)點(diǎn)添加/刪除。3.這方面最具代表性的是dynamo和bigtable 2篇論文所闡述的思路。前者是一個(gè)完全無(wú)中心的設(shè)計(jì)，節(jié)點(diǎn)之間通過(guò)gossip方式傳遞集群信息，數(shù)據(jù)保證最終一致性，后者是一個(gè)中心化的方案設(shè)計(jì)，通過(guò)類(lèi)似一個(gè)分布式鎖服務(wù)來(lái)保證強(qiáng)一致性,數(shù)據(jù)寫(xiě)入先寫(xiě)內(nèi)存和redo log，然后定期compat歸并到磁盤(pán)上，將隨機(jī)寫(xiě)優(yōu)化為順序?qū)?，提高?xiě)入性能。4.Schema free，auto-sharding等。比如目前常見(jiàn)的一些文檔數(shù)據(jù)庫(kù)都是支持schema-free的，直接存儲(chǔ)json格式數(shù)據(jù)，并且支持auto-sharding等功能，比如mongodb。面對(duì)這些不同類(lèi)型的NoSQL產(chǎn)品,我們需要根據(jù)我們的業(yè)務(wù)場(chǎng)景選擇最合適的產(chǎn)品。Redis適用場(chǎng)景，如何正確的使用前面已經(jīng)分析過(guò)，Redis最適合所有數(shù)據(jù)in-momory的場(chǎng)景，雖然Redis也提供持久化功能，但實(shí)際更多的是一個(gè)disk-backed的功能，跟傳統(tǒng)意義上的持久化有比較大的差別，那么可能大家就會(huì)有疑問(wèn)，似乎Redis更像一個(gè)加強(qiáng)版的Memcached，那么何時(shí)使用Memcached,何時(shí)使用Redis呢?如果簡(jiǎn)單地比較Redis與Memcached的區(qū)別，大多數(shù)都會(huì)得到以下觀點(diǎn)：1 Redis不僅僅支持簡(jiǎn)單的k/v類(lèi)型的數(shù)據(jù)，同時(shí)還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。2 Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。3 Redis支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤(pán)中，重啟的時(shí)候可以再次加載進(jìn)行使用。拋開(kāi)這些，可以深入到Redis內(nèi)部構(gòu)造去觀察更加本質(zhì)的區(qū)別，理解Redis的設(shè)計(jì)。在Redis中，并不是所有的數(shù)據(jù)都一直存儲(chǔ)在內(nèi)存中的。這是和Memcached相比一個(gè)最大的區(qū)別。Redis只會(huì)緩存所有的 key的信息，如果Redis發(fā)現(xiàn)內(nèi)存的使用量超過(guò)了某一個(gè)閥值，將觸發(fā)swap的操作，Redis根據(jù)“swappability = age*log(size_in_memory)”計(jì) 算出哪些key對(duì)應(yīng)的value需要swap到磁盤(pán)。然后再將這些key對(duì)應(yīng)的value持久化到磁盤(pán)中，同時(shí)在內(nèi)存中清除。這種特性使得Redis可以 保持超過(guò)其機(jī)器本身內(nèi)存大小的數(shù)據(jù)。當(dāng)然，機(jī)器本身的內(nèi)存必須要能夠保持所有的key，畢竟這些數(shù)據(jù)是不會(huì)進(jìn)行swap操作的。同時(shí)由于Redis將內(nèi)存 中的數(shù)據(jù)swap到磁盤(pán)中的時(shí)候，提供服務(wù)的主線程和進(jìn)行swap操作的子線程會(huì)共享這部分內(nèi)存，所以如果更新需要swap的數(shù)據(jù)，Redis將阻塞這個(gè) 操作，直到子線程完成swap操作后才可以進(jìn)行修改。使用Redis特有內(nèi)存模型前后的情況對(duì)比：VM off: 300k keys, 4096 bytes values: 1.3G usedVM on: 300k keys, 4096 bytes values: 73M usedVM off: 1 million keys, 256 bytes values: 430.12M usedVM on: 1 million keys, 256 bytes values: 160.09M usedVM on: 1 million keys, values as large as you want, still: 160.09M used當(dāng) 從Redis中讀取數(shù)據(jù)的時(shí)候，如果讀取的key對(duì)應(yīng)的value不在內(nèi)存中，那么Redis就需要從swap文件中加載相應(yīng)數(shù)據(jù)，然后再返回給請(qǐng)求方。 這里就存在一個(gè)I/O線程池的問(wèn)題。在默認(rèn)的情況下，Redis會(huì)出現(xiàn)阻塞，即完成所有的swap文件加載后才會(huì)相應(yīng)。這種策略在客戶端的數(shù)量較小，進(jìn)行 批量操作的時(shí)候比較合適。但是如果將Redis應(yīng)用在一個(gè)大型的網(wǎng)站應(yīng)用程序中，這顯然是無(wú)法滿足大并發(fā)的情況的。所以Redis運(yùn)行我們?cè)O(shè)置I/O線程 池的大小，對(duì)需要從swap文件中加載相應(yīng)數(shù)據(jù)的讀取請(qǐng)求進(jìn)行并發(fā)操作，減少阻塞的時(shí)間。如果希望在海量數(shù)據(jù)的環(huán)境中使用好Redis，我相信理解Redis的內(nèi)存設(shè)計(jì)和阻塞的情況是不可缺少的。補(bǔ)充的知識(shí)點(diǎn)：memcached和redis的比較1 網(wǎng)絡(luò)IO模型Memcached是多線程，非阻塞IO復(fù)用的網(wǎng)絡(luò)模型，分為監(jiān)聽(tīng)主線程和worker子線程，監(jiān)聽(tīng)線程監(jiān)聽(tīng)網(wǎng)絡(luò)連接，接受請(qǐng)求后，將連接描述字pipe 傳遞給worker線程，進(jìn)行讀寫(xiě)IO, 網(wǎng)絡(luò)層使用libevent封裝的事件庫(kù)，多線程模型可以發(fā)揮多核作用，但是引入了cache coherency和鎖的問(wèn)題，比如，Memcached最常用的stats 命令，實(shí)際Memcached所有操作都要對(duì)這個(gè)全局變量加鎖，進(jìn)行計(jì)數(shù)等工作，帶來(lái)了性能損耗。(Memcached網(wǎng)絡(luò)IO模型)Redis使用單線程的IO復(fù)用模型，自己封裝了一個(gè)簡(jiǎn)單的AeEvent事件處理框架，主要實(shí)現(xiàn)了epoll、kqueue和select，對(duì)于單純只有IO操作來(lái)說(shuō)，單線程可以將速度優(yōu)勢(shì)發(fā)揮到最大，但是Redis也提供了一些簡(jiǎn)單的計(jì)算功能，比如排序、聚合等，對(duì)于這些操作，單線程模型實(shí)際會(huì)嚴(yán)重影響整體吞吐量，CPU計(jì)算過(guò)程中，整個(gè)IO調(diào)度都是被阻塞住的。2.內(nèi)存管理方面Memcached使用預(yù)分配的內(nèi)存池的方式，使用slab和大小不同的chunk來(lái)管理內(nèi)存，Item根據(jù)大小選擇合適的chunk存儲(chǔ)，內(nèi)存池的方式可以省去申請(qǐng)/釋放內(nèi)存的開(kāi)銷(xiāo)，并且能減小內(nèi)存碎片產(chǎn)生，但這種方式也會(huì)帶來(lái)一定程度上的空間浪費(fèi)，并且在內(nèi)存仍然有很大空間時(shí)，新的數(shù)據(jù)也可能會(huì)被剔除，原因可以參考Timyang的文章：/memcached/)。Memcached的客戶端軟件實(shí)現(xiàn)非常多，包括C/C++, PHP, Java, Python, Ruby, Perl, Erlang, Lua等。當(dāng)前Memcached使用廣泛，除了LiveJournal以外還有Wikipedia、Flickr、Twitter、Youtube和WordPress等。在Window系統(tǒng)下，Memcached的安裝非常方便，只需從以上給出的地址下載可執(zhí)行軟件然后運(yùn)行memcached.exe –d install即可完成安裝。在Linux等系統(tǒng)下，我們首先需要安裝libevent，然后從獲取源碼，make make install即可。默認(rèn)情況下，Memcached的服務(wù)器啟動(dòng)程序會(huì)安裝到/usr/local/bin目錄下。在啟動(dòng)Memcached時(shí)，我們可以為其配置不同的啟動(dòng)參數(shù)。1.1 Memcache配置Memcached服務(wù)器在啟動(dòng)時(shí)需要對(duì)關(guān)鍵的參數(shù)進(jìn)行配置，下面我們就看一看Memcached在啟動(dòng)時(shí)需要設(shè)定哪些關(guān)鍵參數(shù)以及這些參數(shù)的作用。1）-p Memcached的TCP監(jiān)聽(tīng)端口，缺省配置為11211；2）-U Memcached的UDP監(jiān)聽(tīng)端口，缺省配置為11211，為0時(shí)表示關(guān)閉UDP監(jiān)聽(tīng)；3）-s Memcached監(jiān)聽(tīng)的UNIX套接字路徑；4）-a 訪問(wèn)UNIX套接字的八進(jìn)制掩碼，缺省配置為0700；5）-l 監(jiān)聽(tīng)的服務(wù)器IP地址，默認(rèn)為所有網(wǎng)卡；6）-d 為Memcached服務(wù)器啟動(dòng)守護(hù)進(jìn)程；7）-r 最大core文件大小；8）-u 運(yùn)行Memcached的用戶，如果當(dāng)前為root的話需要使用此參數(shù)指定用戶；9）-m 分配給Memcached使用的內(nèi)存數(shù)量，單位是MB；10）-M 指示Memcached在內(nèi)存用光的時(shí)候返回錯(cuò)誤而不是使用LRU算法移除數(shù)據(jù)記錄；11）-c 最大并發(fā)連數(shù)，缺省配置為1024；12）-v –vv –vvv 設(shè)定服務(wù)器端打印的消息的詳細(xì)程度，其中-v僅打印錯(cuò)誤和警告信息，-vv在-v的基礎(chǔ)上還會(huì)打印客戶端的命令和相應(yīng)，-vvv在-vv的基礎(chǔ)上還會(huì)打印內(nèi)存狀態(tài)轉(zhuǎn)換信息；13）-f 用于設(shè)置chunk大小的遞增因子；14）-n 最小的chunk大小，缺省配置為48個(gè)字節(jié)；15）-t Memcached服務(wù)器使用的線程數(shù)，缺省配置為4個(gè)；16）-L 嘗試使用大內(nèi)存頁(yè)；17）-R 每個(gè)事件的最大請(qǐng)求數(shù)，缺省配置為20個(gè)；18）-C 禁用CAS，CAS模式會(huì)帶來(lái)8個(gè)字節(jié)的冗余；2. Redis簡(jiǎn)介Redis是一個(gè)開(kāi)源的key-value存儲(chǔ)系統(tǒng)。與Memcached類(lèi)似，Redis將大部分?jǐn)?shù)據(jù)存儲(chǔ)在內(nèi)存中，支持的數(shù)據(jù)類(lèi)型包括：字符串、哈希表、鏈表、集合、有序集合以及基于這些數(shù)據(jù)類(lèi)型的相關(guān)操作。Redis使用C語(yǔ)言開(kāi)發(fā)，在大多數(shù)像Linux、BSD和Solaris等POSIX系統(tǒng)上無(wú)需任何外部依賴(lài)就可以使用。Redis支持的客戶端語(yǔ)言也非常豐富，常用的計(jì)算機(jī)語(yǔ)言如C、C#、C++、Object-C、PHP、Python、Java、Perl、Lua、Erlang等均有可用的客戶端來(lái)訪問(wèn)Redis服務(wù)器。當(dāng)前Redis的應(yīng)用已經(jīng)非常廣泛，國(guó)內(nèi)像新浪、淘寶，國(guó)外像Flickr、Github等均在使用Redis的緩存服務(wù)。Redis的安裝非常方便，只需從bin目錄下。在啟動(dòng)Redis服務(wù)器時(shí)，我們需要為其指定一個(gè)配置文件，缺省情況下配置文件在Redis的源碼目錄下，文件名為redis.conf。php面試題 memcache和redis的區(qū)別
NoSQL，泛指非關(guān)系型的數(shù)據(jù)庫(kù)。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在處理web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類(lèi)型的web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，出現(xiàn)了很多難以克服的問(wèn)題，而非關(guān)系型的數(shù)據(jù)庫(kù)則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。
常見(jiàn)的Nosql數(shù)據(jù)庫(kù)有：
一、Redis數(shù)據(jù)庫(kù)
Redis（RemoteDictionaryServer），即遠(yuǎn)程字典服務(wù)，是一個(gè)開(kāi)源的使用ANSIC語(yǔ)言編寫(xiě)、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key－Value數(shù)據(jù)庫(kù)，并提供多種語(yǔ)言的API。從2010年3月15日起，Redis的開(kāi)發(fā)工作由VMware主持。從2013年5月開(kāi)始，Redis的開(kāi)發(fā)由Pivotal贊助。
二、MongoDB數(shù)據(jù)庫(kù)
MongoDB是一個(gè)介于關(guān)系數(shù)據(jù)庫(kù)和非關(guān)系數(shù)據(jù)庫(kù)之間的產(chǎn)品，是非關(guān)系數(shù)據(jù)庫(kù)當(dāng)中功能最豐富，最像關(guān)系數(shù)據(jù)庫(kù)的。它支持的數(shù)據(jù)結(jié)構(gòu)非常松散，是類(lèi)似json的bson格式，因此可以存儲(chǔ)比較復(fù)雜的數(shù)據(jù)類(lèi)型。
Mongo最大的特點(diǎn)是它支持的查詢(xún)語(yǔ)言非常強(qiáng)大，其語(yǔ)法有點(diǎn)類(lèi)似于面向?qū)ο蟮牟樵?xún)語(yǔ)言，幾乎可以實(shí)現(xiàn)類(lèi)似關(guān)系數(shù)據(jù)庫(kù)單表查詢(xún)的絕大部分功能，而且還支持對(duì)數(shù)據(jù)建立索引。
擴(kuò)展資料：
對(duì)于NoSQL并沒(méi)有一個(gè)明確的范圍和定義，但是他們都普遍存在下面一些共同特征：
一、易擴(kuò)展
NoSQL數(shù)據(jù)庫(kù)種類(lèi)繁多，但是一個(gè)共同的特點(diǎn)都是去掉關(guān)系數(shù)據(jù)庫(kù)的關(guān)系型特性。數(shù)據(jù)之間無(wú)關(guān)系，這樣就非常容易擴(kuò)展。無(wú)形之間，在架構(gòu)的層面上帶來(lái)了可擴(kuò)展的能力。
二、大數(shù)據(jù)量，高性能
NoSQL數(shù)據(jù)庫(kù)都具有非常高的讀寫(xiě)性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無(wú)關(guān)系性，數(shù)據(jù)庫(kù)的結(jié)構(gòu)簡(jiǎn)單。一般MySQL使用Query Cache。NoSQL的Cache是記錄級(jí)的，是一種細(xì)粒度的Cache，所以NoSQL在這個(gè)層面上來(lái)說(shuō)性能就要高很多。
三、靈活的數(shù)據(jù)模型
NoSQL無(wú)須事先為要存儲(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模型，通過(guò)復(fù)制模型也能實(shí)現(xiàn)高可用。
參考資料來(lái)源：百度百科-NoSQL
1、可能會(huì)問(wèn)nosql和關(guān)系型數(shù)據(jù)庫(kù)的區(qū)別：
優(yōu)點(diǎn)：
1）成本：nosql數(shù)據(jù)庫(kù)簡(jiǎn)單易部署，基本都是開(kāi)源軟件，不需要像使用Oracle那樣花費(fèi)大量成本購(gòu)買(mǎi)使用，相比關(guān)系型數(shù)據(jù)庫(kù)價(jià)格便宜
2）查詢(xún)速度：nosql數(shù)據(jù)庫(kù)將數(shù)據(jù)存儲(chǔ)于緩存之中，關(guān)系型數(shù)據(jù)庫(kù)將數(shù)據(jù)存儲(chǔ)在硬盤(pán)中，自然查詢(xún)速度遠(yuǎn)不及nosql數(shù)據(jù)庫(kù)
3）存儲(chǔ)數(shù)據(jù)的格式：nosql的存儲(chǔ)格式是key,value形式、文檔形式、圖片形式等等，所以可以存儲(chǔ)基礎(chǔ)類(lèi)型以及對(duì)象或者是集合等各種格式，而數(shù)據(jù)庫(kù)則只支持基礎(chǔ)類(lèi)型
4）擴(kuò)展性：關(guān)系型數(shù)據(jù)庫(kù)有類(lèi)似join這樣的多表查詢(xún)機(jī)制的限制導(dǎo)致擴(kuò)展很艱難
缺點(diǎn)：
1）維護(hù)的工具和資料有限，因?yàn)閚osql是屬于新的技術(shù)，不能和關(guān)系型數(shù)據(jù)庫(kù)10幾年的技術(shù)同日而語(yǔ)。
2）不提供對(duì)sql的支持，如果不支持sql這樣的工業(yè)標(biāo)準(zhǔn)，將產(chǎn)生一定用戶的學(xué)習(xí)和使用成本
3）不提供關(guān)系型數(shù)據(jù)庫(kù)對(duì)事物的處理
2、介紹下redis和mongodb：
自行g(shù)oogle。
3、應(yīng)用場(chǎng)景：
redis：
a.主要是做熱點(diǎn)數(shù)據(jù)緩存。
b.數(shù)據(jù)過(guò)期處理。
c.消息隊(duì)列等功能。
d.計(jì)數(shù)，例如投票等。
mongodb：
mongodb的主要目標(biāo)是在鍵/值存儲(chǔ)方式（提供了高性能和高度伸縮性）以及傳統(tǒng)的RDBMS系統(tǒng)（豐富的功能）架起一座橋梁，集兩者的優(yōu)勢(shì)于一身。mongo適用于以下場(chǎng)景：
a.網(wǎng)站數(shù)據(jù)：mongo非常適合實(shí)時(shí)的插入，更新與查詢(xún)，并具備網(wǎng)站實(shí)時(shí)數(shù)據(jù)存儲(chǔ)所需的復(fù)制及高度伸縮性。
b.緩存：由于性能很高，mongo也適合作為信息基礎(chǔ)設(shè)施的緩存層。在系統(tǒng)重啟之后，由mongo搭建的持久化緩存可以避免下層的數(shù)據(jù)源過(guò)載。
c.大尺寸、低價(jià)值的數(shù)據(jù)：使用傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)存儲(chǔ)一些數(shù)據(jù)時(shí)可能會(huì)比較貴，在此之前，很多程序員往往會(huì)選擇傳統(tǒng)的文件進(jìn)行存儲(chǔ)。
d.高伸縮性的場(chǎng)景：mongo非常適合由數(shù)十或者數(shù)百臺(tái)服務(wù)器組成的數(shù)據(jù)庫(kù)。
e.用于對(duì)象及JSON數(shù)據(jù)的存儲(chǔ)：mongo的BSON數(shù)據(jù)格式非常適合文檔格式化的存儲(chǔ)及查詢(xún)。
4、支持的數(shù)據(jù)類(lèi)型:
內(nèi)容比較多，自行將網(wǎng)上的信息整理一下。
SOA與微服務(wù)的區(qū)別？
SOA的提出是在企業(yè)計(jì)算領(lǐng)域，就是要將緊耦合的系統(tǒng)，劃分為面向業(yè)務(wù)的，粗粒度，松耦合，無(wú)狀態(tài)的服務(wù)。服務(wù)發(fā)布出來(lái)供其他服務(wù)調(diào)用，一組互相依賴(lài)的服務(wù)就構(gòu)成了SOA架構(gòu)下的系統(tǒng)。
基于這些基礎(chǔ)的服務(wù)，可以將業(yè)務(wù)過(guò)程用類(lèi)似BPEL流程的方式編排起來(lái)，而B(niǎo)PEL反映的是業(yè)務(wù)處理的過(guò)程，這些過(guò)程對(duì)于業(yè)務(wù)人員更為直觀，調(diào)整也比hardcode的代碼更容易。
當(dāng)然企業(yè)還需要對(duì)服務(wù)治理，比如服務(wù)注冊(cè)庫(kù)，監(jiān)控管理等。
我們知道企業(yè)計(jì)算領(lǐng)域，如果不是交易系統(tǒng)的話，并發(fā)量都不是很大的，所以大多數(shù)情況下，一臺(tái)服務(wù)器就容納將許許多多的服務(wù)，這些服務(wù)采用統(tǒng)一的基礎(chǔ)設(shè)施，可能都運(yùn)行在一個(gè)應(yīng)用服務(wù)器的進(jìn)程中。雖然說(shuō)是面向服務(wù)了，但還是單一的系統(tǒng)。
而微服務(wù)架構(gòu)大體是從互聯(lián)網(wǎng)企業(yè)興起的，由于大規(guī)模用戶，對(duì)分布式系統(tǒng)的要求很高，如果像企業(yè)計(jì)算那樣的系統(tǒng)，伸縮就需要多個(gè)容納續(xù)續(xù)多多的服務(wù)的系統(tǒng)實(shí)例，前面通過(guò)負(fù)載均衡使得多個(gè)系統(tǒng)成為一個(gè)集群。但這是很不方便的，互聯(lián)網(wǎng)企業(yè)迭代的周期很短，一周可能發(fā)布一個(gè)版本，甚至可能每天一個(gè)版本，而不同的子系統(tǒng)的發(fā)布周期是不一樣的。而且，不同的子系統(tǒng)也不像原來(lái)企業(yè)計(jì)算那樣采用集中式的存儲(chǔ)，使用昂貴的Oracle存儲(chǔ)整個(gè)系統(tǒng)的數(shù)據(jù)，二是使用MongoDB，HBase，Cassandra等NOSQL數(shù)據(jù)庫(kù)和Redis，memcache等分布式緩存。那么就傾向采用以子系統(tǒng)為分割，不同的子系統(tǒng)采用自己的架構(gòu)，那么各個(gè)服務(wù)運(yùn)行自己的Web容器中，當(dāng)需要增加計(jì)算能力的時(shí)候，只需要增加這個(gè)子系統(tǒng)或服務(wù)的實(shí)例就好了，當(dāng)升級(jí)的時(shí)候，可以不影響別的子系統(tǒng)。這種組織方式大體上就被稱(chēng)作微服務(wù)架構(gòu)。
微服務(wù)與SOA相比，更強(qiáng)調(diào)分布式系統(tǒng)的特性，比如橫向伸縮性，服務(wù)發(fā)現(xiàn)，負(fù)載均衡，故障轉(zhuǎn)移，高可用?；ヂ?lián)網(wǎng)開(kāi)發(fā)對(duì)服務(wù)治理提出了更多的要求，比如多版本，比如灰度升級(jí)，比如服務(wù)降級(jí)，比如分布式跟蹤，這些都是在SOA實(shí)踐中重視不夠的。
Docker容器技術(shù)的出現(xiàn)，為微服務(wù)提供了更便利的條件，比如更小的部署單元，每個(gè)服務(wù)可以通過(guò)類(lèi)似Node.js或Spring Boot的技術(shù)跑在自己的進(jìn)程中?？赡茉趲资_(tái)計(jì)算機(jī)中運(yùn)行成千上萬(wàn)個(gè)Docker容器，每個(gè)容器都運(yùn)行著服務(wù)的一個(gè)實(shí)例。隨時(shí)可以增加某個(gè)服務(wù)的實(shí)例數(shù)，或者某個(gè)實(shí)例崩潰后，在其他的計(jì)算機(jī)上再創(chuàng)建該服務(wù)的新的實(shí)例。
如何拆分服務(wù)？
要圍繞業(yè)務(wù)模塊進(jìn)行拆分，拆分粒度應(yīng)該保證微服務(wù)具有業(yè)務(wù)的獨(dú)立性與完整性，盡可能少的存在服務(wù)依賴(lài)，鏈?zhǔn)秸{(diào)用。但是，在實(shí)際開(kāi)發(fā)過(guò)程中，有的時(shí)候單體架構(gòu)更加適合當(dāng)前的項(xiàng)目。實(shí)際上，微服務(wù)的設(shè)計(jì)并不是一蹴而就的，它是一個(gè)設(shè)計(jì)與反饋過(guò)程。因此，我們?cè)谠O(shè)計(jì)之初可以將服務(wù)的粒度設(shè)計(jì)的大一些，并考慮其可擴(kuò)展性，隨著業(yè)務(wù)的發(fā)展，進(jìn)行動(dòng)態(tài)地拆分也是一個(gè)不錯(cuò)的選擇。
REST的名稱(chēng)"表現(xiàn)層狀態(tài)轉(zhuǎn)化"中，省略了主語(yǔ)。"表現(xiàn)層"其實(shí)指的是"資源"（Resources）的"表現(xiàn)層"。
所謂"資源"，就是網(wǎng)絡(luò)上的一個(gè)實(shí)體，或者說(shuō)是網(wǎng)絡(luò)上的一個(gè)具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務(wù)，總之就是一個(gè)具體的實(shí)在。你可以用一個(gè)URI（統(tǒng)一資源定位符）指向它，每種資源對(duì)應(yīng)一個(gè)特定的URI。要獲取這個(gè)資源，訪問(wèn)它的URI就可以，因此URI就成了每一個(gè)資源的地址或獨(dú)一無(wú)二的識(shí)別符。
客戶端用到的手段，只能是HTTP協(xié)議。具體來(lái)說(shuō)，就是HTTP協(xié)議里面，四個(gè)表示操作方式的動(dòng)詞：GET、POST、PUT、DELETE。它們分別對(duì)應(yīng)四種基本操作：GET用來(lái)獲取資源，POST用來(lái)新建資源（也可以用于更新資源），PUT用來(lái)更新資源，DELETE用來(lái)刪除資源。
實(shí)際上呢，不是所有的東西都是“資源”，尤其是在業(yè)務(wù)系統(tǒng)中，缺點(diǎn)如下：
有個(gè)接口是更新訂單狀態(tài)，你是用上面的GET POST PUT DELETE 哪個(gè)呢，看樣子應(yīng)該是PUT，但是路徑呢PUT /tickets/12
我有時(shí)候多個(gè)接口 ，更新訂單收款狀態(tài)，更新訂單支款狀態(tài)，更新訂單結(jié)算狀態(tài)；
Restful 的路徑明顯不友好不夠用；
再比如，批量刪除，DELETE還好用么，DELETE /tickets/12 #刪除ticekt 12 這種形式如果要傳數(shù)組怎么辦，url是不是不夠友好？
再比如，Resuful要求 GET /tickets # 獲取ticket列表 。我們?cè)?jīng)有個(gè)需求，對(duì)方會(huì)把不超過(guò)1000個(gè)訂單id傳給我們，我們系統(tǒng)過(guò)濾其中一部分特殊訂單；這也是個(gè)查詢(xún)服務(wù)，用GET /tickets # 獲取ticket列表的形式，1000個(gè)訂單id顯然是超過(guò)GET url長(zhǎng)度的，這里也不合適；再者，我想開(kāi)發(fā)多個(gè)條件查詢(xún)列表服務(wù)，路徑這么淺顯然不合適；
實(shí)際業(yè)務(wù)中，我們webapi的路徑是這樣的：systemAlias/controller/action
總結(jié)下規(guī)則：
簡(jiǎn)單查詢(xún)盡量用GET，好處是可以直接帶查詢(xún)參數(shù)copy api路徑；
復(fù)雜查詢(xún)和更新用POST，用的最多；
不用PUT和DELETE，原因是增加復(fù)雜度，并沒(méi)有帶來(lái)什么好處
看看BAT的很多openapi，也是寫(xiě)著restful，實(shí)際沒(méi)有嚴(yán)格遵守，都是get和post，這是也很多人不知道put和delete的原因
如：
//根據(jù)訂單id獲取訂單
GET oms/order/queryOrderById?id=value1param2=value2
//根據(jù)訂單id List獲取訂單
POST oms/order/queryOrderByIdList
//根據(jù)條件查詢(xún)訂單，帶分頁(yè)參數(shù)
POST oms/order/queryOrderByCondition
//更新訂單收款狀態(tài)
POST oms/order/updateOrderCollectionStatus
//批量更新訂單收款狀態(tài)
POST oms/order/updateOrderCollectionStatusInBatch
//批量更新訂單收款狀態(tài)
POST oms/order/updateOrderCollectionStatusInBatch
//批量刪除訂單，帶操作來(lái)源
POST oms/order/deleteOrderInBatch
微服務(wù)如何進(jìn)行數(shù)據(jù)庫(kù)管理？
CAP 原理(CAP Theorem)
在足球比賽里，一個(gè)球員在一場(chǎng)比賽中進(jìn)三個(gè)球，稱(chēng)之為帽子戲法(Hat-trick)。在分布式數(shù)據(jù)系統(tǒng)中，也有一個(gè)帽子原理(CAP Theorem)，不過(guò)此帽子非彼帽子。CAP 原理中，有三個(gè)要素：
CAP 原理指的是，這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。
因此在進(jìn)行分布式架構(gòu)設(shè)計(jì)時(shí)，必須做出取舍。而對(duì)于分布式數(shù)據(jù)系統(tǒng)，分區(qū)容忍性是基本要求 ，否則就失去了價(jià)值，因此設(shè)計(jì)分布式數(shù)據(jù)系統(tǒng)，就是在一致性和可用性之間取一個(gè)平衡。
對(duì)于大多數(shù) WEB 應(yīng)用，其實(shí)并不需要強(qiáng)一致性，因此犧牲一致性而換取高可用性，是目前多數(shù)分布式數(shù)據(jù)庫(kù)產(chǎn)品的方向。
當(dāng)然，犧牲一致性，并不是完全不管數(shù)據(jù)的一致性，否則數(shù)據(jù)是混亂的，那么系統(tǒng)可用性再高分布式再好也沒(méi)有了價(jià)值。
犧牲一致性，只是不再要求關(guān)系型數(shù) 據(jù)庫(kù)中的強(qiáng)一致性，而是只要系統(tǒng)能達(dá)到最終一致性即可，考慮到客戶體驗(yàn)，這個(gè)最終一致的時(shí)間窗口，要盡可能的對(duì)用戶透明，也就是需要保障“用戶感知到的一致性”。
通常是通過(guò)數(shù)據(jù)的多份異步復(fù)制來(lái)實(shí)現(xiàn)系統(tǒng)的高可用和數(shù)據(jù)的最終一致性的，“用戶感知到的一致性”的時(shí)間窗口則 取決于數(shù)據(jù)復(fù)制到一致?tīng)顟B(tài)的時(shí)間。
最終一致性(eventually consistent)
對(duì)于一致性，可以分為從客戶端和服務(wù)端兩個(gè)不同的視角。
從客戶端來(lái)看，一致性主要指的是多并發(fā)訪問(wèn)時(shí)更新過(guò)的數(shù)據(jù)如何獲取的問(wèn)題。
從服務(wù)端來(lái)看，則是更新如何復(fù)制分布到整個(gè)系統(tǒng)，以保證數(shù)據(jù)最終一致。
一致性是因?yàn)橛胁l(fā)讀寫(xiě)才有的問(wèn)題，因此在理解一致性的問(wèn)題時(shí)，一定要注意結(jié)合考慮并發(fā)讀寫(xiě)的場(chǎng)景。
從客戶端角度，多進(jìn)程并發(fā)訪問(wèn)時(shí)，更新過(guò)的數(shù)據(jù)在不同進(jìn)程如何獲取的不同策略，決定了不同的一致性。
對(duì)于關(guān)系型數(shù)據(jù)庫(kù)，要求更新過(guò)的數(shù)據(jù)能被后續(xù)的 訪問(wèn)都能看到，這是強(qiáng)一致性 ;如果能容忍后續(xù)的部分或者全部訪問(wèn)不到，則是弱一致性 ; 如果經(jīng)過(guò)一段時(shí)間后要求能訪問(wèn)到更新后的數(shù)據(jù)，則是最終一致性。
從服務(wù)端角度，如何盡快將更新后的數(shù)據(jù)分布到整個(gè)系統(tǒng)，降低達(dá)到最終一致性的時(shí)間窗口，是提高系統(tǒng)的可用度和用戶體驗(yàn)非常重要的方面。
那么問(wèn)題來(lái)了，如何實(shí)現(xiàn)數(shù)據(jù)的最終一致性呢?答案就在事件驅(qū)動(dòng)架構(gòu)。
最佳解決辦法是采用事件驅(qū)動(dòng)架構(gòu)。其中碰到的一個(gè)挑戰(zhàn)是如何原子性的更新?tīng)顟B(tài)和發(fā)布事件。有幾種方法可以解決此問(wèn)題，包括將數(shù)據(jù)庫(kù)視為消息隊(duì)列和事件源等。
從目前技術(shù)應(yīng)用范圍和成熟度看，推薦使用第一種方式(本地事務(wù)發(fā)布事件)，來(lái)實(shí)現(xiàn)事件投遞原子化，即可靠事件投遞。
SpringCloud和Dubbo有哪些區(qū)別？
總體來(lái)說(shuō)，兩者各有優(yōu)勢(shì)。雖說(shuō)后者服務(wù)調(diào)用的功能，但也避免了上面提到的原生RPC帶來(lái)的問(wèn)題。而且REST相比RPC更為靈活，服務(wù)提供方和調(diào)用方的依賴(lài)只依靠一紙契約，不存在代碼級(jí)別的依賴(lài)，這在強(qiáng)調(diào)快速演化的微服務(wù)環(huán)境下，顯得更加合適。
品牌機(jī)與組裝機(jī)的區(qū)別：很明顯SpringCloud比dubbo的功能更強(qiáng)大，覆蓋面更廣，而且能夠與SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring項(xiàng)目完美融合，這些對(duì)于微服務(wù)至關(guān)重要。使用Dubbo構(gòu)建的微服務(wù)架構(gòu)就像組裝電腦、各環(huán)節(jié)我們選擇自由度高，但是最總可能會(huì)因?yàn)閮?nèi)存質(zhì)量而影響整體，但對(duì)于高手這也就不是問(wèn)題。而SpringCloud就像品牌機(jī)，在Spring Source的整合下，做了大量的兼容性測(cè)試，保證了機(jī)器擁有更高的穩(wěn)定性。
在面臨微服務(wù)基礎(chǔ)框架選型時(shí)Dubbo與SpringCloud只能二選一。
重慶分公司
重慶分公司
