kv存儲系統是什麼

① 一般什麼產品或者系統或網站會使用K/V資料庫型資料庫呢

KV型存儲系統是最常用的Nosql存儲系統之一。Memcached和Redis是其最具代表的兩個產品。本文將詳細介紹Memcached和Redis的常用場景及如何構建一個高可用和自動彈性伸縮的KV存儲系統。

Cache加DB是最常見的存儲層架構。時間局部性原理指出正在被訪問的數據很可能會在近期再次被訪問。根據這一原理應用程序將最近訪問過的數據保存在Cache中，每次讀取請求首先訪問Cache，若Cache中保存有該數據則直接獲取數據返回給前端。若Cache中該數據不存在則從DB獲取數據並將該數據保存到Cache；若數據被更新或刪除則將Cache中對應數據置為失效。使用Cache能夠很好地緩解DB的讀請求壓力。KV存儲系統既可以應用在Cache層也可以應用在DB層。

Memcached使用內存作為存儲介質，因為內存數據的易失性Memcached主要應用在Cache層。Memcached常見的應用場景是存儲一些讀取頻繁但更新較少的數據，如靜態網頁、系統配置及規則數據、活躍用戶的基本數據和個性化定製數據、准實時統計信息等。並不是所有場景都適合Memcached加DB的架構，在某些場景下這一架構存在一些局限。例如這一架構不能提升寫的性能，寫數據時還是數據直接存儲到DB，同時需要將Cache中數據置為失效，所以對以寫請求為主的應用使用Cache提升性能的效果並不是很明顯。如果應用的熱點數據或者活躍用戶分布較為分散也會降低Cache的命中率。如果遇到機器宕機，內存數據會丟失，那麼機器重啟後需要一段時間重新建立熱點數據，建立熱點數據的過程中會對DB會造成較大的壓力，嚴重時會導致系統雪崩。

相比Memcached，Redis做了一些優化。首先，Redis對數據做了持久化，支持AOF和RDB兩種持久化方式，機器重啟後能通過持久化數據自動重建內存。其次，Redis支持主從復制，主機會自動將數據同步到從機，可以進行讀寫分離，主機負責寫操作，從機負責讀操作。那樣既增加了系統的讀寫性能又提升了數據的可靠性。再次，Redis除了支持string類型的value外還支持string、hash、set、sorted set、list等類型的數據結構。因此，Redis既可以應用在Cache層，也可以替換或者部分替換DB存儲持久化數據。使用Redis作為Cache時機器宕機後熱點數據不會丟失，無須像Memcached一樣重建熱點數據。相比Cache加DB的架構方式，使用Redis存儲持久化數據不僅能夠提升讀性能，還能提升寫性能，而且不存在熱點數據分布是否集中而影響命中率的問題。Redis豐富的數據結構也使其擁有更加豐富的應用場景。Redis的命令都是原子性的，可以簡單地利用INCR和DECR實現計數功能。使用list可以實現獲取最近N個數的操作。sort set支持對數據排序，可以應用在排行榜中。set集合可以應用到數據排重。Redis還支持過期時間設置，可以應用到需要設定精確過期時間的應用。只要可以使用Redis支持的數據結構表示的場景，就可以使用Redis進行存儲。但Redis不是萬能的，它不支持關系型資料庫復雜的SQL操作。某些場景下，可結合Redis和關系型DB，將簡單查詢相關的數據保存在Redis中，復雜SQL操作由關系型DB完成。

雖然Redis集很多優點於一身，但在實際運營中也存在一些問題。首先，Redis不具備自動容錯和恢復功能，主機從機的宕機都會導致前端部分讀寫請求失敗，需要等待機器重啟或者手動切換前端的IP才能恢復。如果主機宕機，宕機前有部分數據未能及時同步到從機，切換IP後還會引入數據不一致的問題，降低了系統的可用性。其次，Redis的主從復制採用全量復制，復制過程中主機會fork出一個子進程對內存做一份快照，並將子進程的內存快照保持為文件發送給從機，這一過程需要確保主機有足夠多的空餘內存。若快照文件較大，對集群的服務能力會產生較大的影響，而且復制過程是在從機新加入集群或者從機和主機網路斷開重連時都會進行，也就是網路波動都會造成主機和從機間的一次全量的數據復制，這對實際的系統運營造成了不小的麻煩。最後，Redis較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜。為避免這一問題，運維人員在系統上線時必須確保有足夠的空間，這對資源造成了很大的浪費。

② 如何評價ku存儲引擎

沒有數據分析流式計算的經驗，根據對kv存儲系統的理解，簡單答一發，輕拍。。
數據存儲的選擇上，HBASE和HADOOP在吞吐率、延遲上各有側重，如果做數據分析，要從HBase導出到hadoop平台再用Hive查詢，這就要求系統要混布HBASE和hadoop。
KADU的目標就是要兼顧前兩個存儲系統，實現對外數據的存儲和後台計算的本地化，減少數據傳輸成本已經部署運維成本。
架構方面，還是延用BIGTABLE的基本架構，元數據和數據分開存儲的，但做了一些比較有挑戰的優化操作，提升查詢和插入的性能
另外的亮點是，多副本間使用了raft保證數據的高可靠性。
性能方面，目前beta版本要略差與HBASE,這也是意料之中的事情。

③ 怎麼指定redis集群節點的主從關系

市面上太多kv的緩存，最常用的就屬memcache了，但是memcache存在單點問題，不過小日本有復製版本，但是使用的人比較少，redis的出現讓kv內存存儲的想法成為現實。今天主要內容便是redis主從實現簡單的集群，實際上redis的安裝配置砸門ttlsa之前就有個文章，廢話少說，進入正題吧

Redis簡介

redis是一個key-value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、 list(鏈表)、set(集合)和zset(有序集合)。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操 作，而且這些操作都是原子性的。在此基礎上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的 是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步。

Redis 是一個高性能的key-value資料庫。 redis的出現，很大程度補償了memcached這類key/value存儲的不足，在部 分場合可以對關系資料庫起到很好的補充作用。它提供了Python，Ruby，Erlang，PHP客戶端，使用很方便。

 

1. 下載軟體包

# cd /usr/local/src/

# wget http://redis.googlecode.com/files/redis-2.6.11.tar.gz

2. Redis安裝

主從都需要安裝

# tar -xzvf redis-2.6.11.tar.gz

# mv redis-2.6.11 /usr/local/

# cd /usr/local/redis-2.6.11/

# make

備註：這邊就不make install 了，直接使用make好的文件

3. redis配置

找到配置文件/usr/local/redis-2.6.11/redis.conf

修改如下內容：

daemonize no 改為 yes # 是否後台運行

port 6379 改

④ 文件比較」功能的java開源項目嗎

一個輕量級分布式KV存儲系統。 如果用K記錄文件路徑和文件名，用V記錄文件內容，就是一個輕量級分布式小文件系統。 至於大文件，幾乎一定是HDFS這種有元數據服務中心（NameNode）架構的。

⑤ 有沒有用Java寫的輕量級開源的分布式存儲系統

1、jmeter的架構和loadrunner原理一樣，都是通過中間代理，監控和收集並發客戶端發出的指令，把他們生成腳本，再發送到應用伺服器，再監控伺服器反饋結果的一個過程；
2、分布式中間代理功能在jmeter中也有，這個分頁式代理是指可設置多台代理在不同PC中，通過遠程進行控制，即通過使用多台機器運行的謂的agant來分擔load generator自身的壓力，並借引來獲取更大的並發用戶數，loadrunner也有此功能；
3、jmeter安裝簡單，只需要解壓jmeter文件包到C盤上就可以了，不用安裝，要是你想執行調試測試腳本，前提是：裝上jdk和netbean插件，而loadrunner安裝包有1G多，在一台P3.0,1G內存的PC上安裝要一個多小時，要是裝過舊的盜版還不能再裝新版，解決辦法倒是有，但麻煩且花時間；
4、Jmeter沒有IP欺騙功能，IP欺騙是指在一台PC上多個IP地址分配給並發用戶，這個功能對於模擬較真實的用戶環境來說，是較有用，loadrunner有此功能；
5、jmeter也提供了一個利用本地proxy server(代理伺服器)來錄制生成測試腳本的功能，但是這個功能並不好用，測試對象的個別參數要手工增加上去，還得附帶裝個IE代理，如 GoogleToolbarDownloader這些插件來捕捉參數，但是有一個工具badbody,利用這個工具可以錄制操作，然後選擇將腳本保存為jmeter腳本，然後利用jmeter可以打開並修改腳本；
6、Jmeter的報表較少，對於要分析測試性能不足作為依據。如要知道資料庫伺服器或應用程序服務的cpu,money等參數，還得在相關伺服器上另外寫腳本記錄伺服器的性能；
7、jmeter做性能測試，主要是通過增加線程的數目，或者是設置循環次數來增加並發用戶，而loadrunner可以通過在場景中選擇要設置什麼樣的場景，然後選擇虛擬用戶數；
8、jmeter可以通過邏輯控制器實現復雜的測試行為，相當於loadrunner中的測試場景；
9、jmeter可以做web程序的功能測試，利用jmeter中的樣本，可以做灰盒測試，loadrunner主要用來做性能測試；
10、jmeter是開源的，但是使用的人較少，網路上相關資料不全面，需要自己去揣摩，而loadrunner是商業軟體，如果是正版本，有技術支持，同時，網路上的資料相當多；
11、Jmeter的腳本修改，主要是針對jmeter中各個部件的熟悉程序，已經相關的一些協議的掌握情況，而不依賴於編程，而loadrunner除了復雜的場景設置外，還需要掌握函數，修改腳本。

⑥ 為什麼分布式資料庫這么喜歡用kv store

大部分資料庫都有KV存儲這個抽象，但仍然存在很大的設計空間，例如單機的KV是否需要支持事務，是否需要感知schema，是否需要暴露多版本的介面。因此，不能籠統地說分布式資料庫都喜歡用KV store。

分布式資料庫系統通常使用較小的計算機系統，每台計算機可單獨放在一個地方，每台計算機中都可能有DBMS的一份完整拷貝副本，或者部分拷貝副本，並具有自己局部的資料庫，位於不同地點的許多計算機通過網路互相連接，共同組成一個完整的、全局的邏輯上集中、物理上分布的大型資料庫。

結構模式

根據我國制定的《分布式資料庫系統標准》，分布式資料庫系統抽象為4層的結構模式。這種結構模式得到了國內外的支持和認同。

4層模式劃分為全局外層、全局概念層、局部概念層和局部內層，在各層間還有相應的層間映射。這種4層模式適用於同構型分布式資料庫系統，也適用於異構型分布式資料庫系統。

⑦ 如何解決網站架構KV儲存問題

• 如果對樓主有幫助，給個採納可以不，謝謝啦

• Key-value存儲系統，是非常普遍的需求，幾乎每個在線的互聯網後台服務都需要KV存儲，我們團隊在KV存儲方面，經歷過幾個時期，我自己深感要做好不容易。

• 這里扯遠一點，展開說一下：

• 第一個時期，很早期的時候，我們的數據存儲在mysql表裡，按照用戶賬號簡單的分庫分表，為了保證訪問高並發，利用每個mysql伺服器的內存做數據緩存；主備兩套分布在不同IDC，業務邏輯自己做副本同步。當時主要的問題是：內存的數據結構擴展困難、運維工作瑣碎、數據同步機制本身的缺陷導致不能做異地IDC部署，這些缺點對於業務飛速發展、一地機房已經不夠用的局面非常被動

• 第二個時期，我們設計了新的KV存儲系統，其用戶數據結構容易擴展、具備可以多地部署的數據同步機制，很好的應對了新時期業務發展的需要。為了設備成本考慮，我們把數據做冷熱分離，訪問頻繁的數據會載入到專門的cache層，且對於不同的訪問模型，掛載不同架構的cache，另外一個file層專門做數據持久化。這樣的設計，使得架構太復雜，bug收斂速度慢，運維工作相比以前甚至更復雜了。

• 第三個時期，為了應對普遍的KV存儲需求，我們以公共組件的形式重新設計了KV存儲，作為團隊標準的組件之一，得到了大規模的應用。結合同期抽象出來的邏輯層框架、路由管理等其他組件，團隊的公共基礎組件和運維設施建設的比較完備了，整個業務的開發和運維實現了標准化。但這個階段就用了我們團隊足足2年多時間。

• 不同於無數據的邏輯層框架，KV存儲系統的架構設計會更復雜、運維工作更繁瑣、運營過程中可能出現的狀況更多、bug收斂時間會更長。一句話：團隊自己做一個KV存儲系統是成本很高的，而且也有比較高的技術門檻。

• 設計一個KV存儲，需要考慮至少這些方面：

• 如何組織機器的存儲介質，通常是內存、磁碟文件；例如用hash的方式組織內存

• 如何設計用戶的數據結構，使得通用、易於擴展、存儲利用率高；例如PB序列化、Json、XML方式

• 友好的訪問介面，而不只是get / set一整個value

• 如何做集群分布、如何sharding、如何做到方便的擴縮容；例如一致性hash演算法

• 如何做數據冗餘、副本間如何同步、一致性問題；副本間如何選舉master

• 備份與恢復、數據校驗與容錯

• 讀寫性能

• 其他可能的特殊需求：例如我們設計過一個KV存儲，用於存儲一些公眾號的個數不受限粉絲列表

上面八點，業內的KV存儲組件一般都會考慮到，或者各有特色，各自優勢在伯仲之間。但是綜合過去的經驗教訓，我們覺得有一點很容易被忽視：可運維性、運維自動化、黑盒化運維。

舉一個例子，前面提到的我們第二個時期的KV存儲系統，剛開始應用的時候，一次擴容過程會有10多步的運維操作，包括load數據、做增量同步、多次修改機器狀態、數據比對等等，需要運維同事以高度的責任心來完成。另外就是運維同事必須如該KV存儲架構設計者一樣深刻理解系統背後的原理和細節，否則就不能很好的執行運維操作，這個要求也非常高，新老交接周期長，還容易出運維事故。

基於上面的考慮，同事為了讓用戶更容易學習和接受，毫秒服務引擎在redis cluster的基礎上，實現了運維web化，並加上了集群的監控。

毫秒服務引擎(msec, 取英文名Mass Service Engine in Cluster的首字母組合)是騰訊一個開源框架，其創作沖動和構建經驗，來自QQ後台團隊超過10年的運營思考。

⑧ 如何實現 Docker 與分布式資料庫結合

那麼Docker是什麼呢?
Docker 是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然後發布到任何流行的 Linux 機器上，也可以實現虛擬化。容器是完全使用沙箱機制，相互之間不會有任何介面。幾乎沒有性能開銷,可以很容易地在機器和數據中心中運行。最重要的是,他們不依賴於任何語言、框架包括系統。
這是對Docker的一個官方解釋，簡單說，有兩個部分：
1) 對於應用程序，曾經我們需要為了不同的系統專門的調整應用程序的代碼或者是構造相應的依賴包驅動等等，大大增加了開發量以及開發的難度。現在，Docker向不同的應用程序，提供了一個統一的環境。
2) 對於伺服器，為了支持不同版本的應用，曾經可能需要在物理機上安裝多個版本或者不同的GuestOS或者說虛擬機。這就大大佔用了物理機的性能，影響了最終程序的表現，提高了資源的成本。

使用Docker容器的方式，對於應用程序，不需要開發多種多樣的版本或者是針對OS每個版本的升級再進行代碼方面的調整，實現了廣泛的兼容性和開發的最簡性。同時對於物理機，部署的環境「瘦身」也節約了更多的資源，將更多的資源用於提高應用程序本身的性能。
CoreOS是Docker的不二之選?
之前大概介紹了Docker，那麼伺服器上面還是需要最基本的應操作系統才能支撐Docker容器，那麼這么多中的Linux內核OS究竟哪一個好呢?筆者和很多Docker技術專家的的觀點就是Core OS。
CoreOS是一個基於Linux 內核的輕量級操作系統，為了計算機集群的基礎設施建設而生，專注於自動化，輕松部署，安全，可靠，規模化。作為一個操作系統，CoreOS 提供了在應用容器內部署應用所需要的基礎功能環境以及一系列用於服務發現和配置共享的內建工具。
簡單說，CoreOS去掉了大量的非必要的功能，只保留了Server端需要的最基本功能，真正意義做到了「輕量化」。
此外，CoreOS還做到了：整體系統升級/回滾方案;容器化所有非系統應用、無包管理器;集群化調度器Fleet;分布式高可靠的KV存儲系統ETCD
這些特性都讓它成為Docker生態的首選操作系統。不過最新的消息是，CoreOS不滿足於做Docker生態下的一環，它正在推出自己的容器AppC計劃，想對Docker來一招「釜底抽薪」。當然，現階段並沒有出現完全的兩者 「分手」，所以對於普通使用者，並沒有太大影響。

Docker+分布式資料庫
資料庫是每一個軟體項目必須的一個部分，作為這樣的一類底層基礎軟體，兼容性、通用性、易用度都是需要考慮的重點。非常遺憾的是，現在的操作系統以及資料庫都沒有完全的實現完全的通用。特別對於NoSQL資料庫這樣的分布式系統，需要部署在多台物理機時，對於通用性要求就更高了。
目前，像SequoiaDB已經實現了自動化的安裝，大大提升了部署的效率，但是考慮到部署之後的配置以及不同環境下的調試問題，仍然可能會耗費不小的人力物力。所以基於剛剛提到的Docker的優點，作為一個通用的基礎軟體，NoSQL資料庫的Docker化就成了必須。

一個簡單的例子，你可以用docker把資料庫的數據與資料庫程序本身分離開：用一個container A作為數據存儲，然後另一個container B運行資料庫。當你想升級資料庫時，用新的container C替換掉container B即可。
Docker+分布式資料庫的結合，帶來諸多的好處：
1) 部署簡單，使用鏡像部署非常簡單，特別是對集群環境，使用Docker鏡像的部署還可以再資料庫上提前集成Hadoop、Spark等架構，真正實現「一步到位」。
2) 方便應用的更新，應用的更新只需要考慮製作一個新的鏡像就可以與容器適配，無需重新再調整與底層的配置。數據和程序的分離，這樣升級替換等等都不會影響到數據。
3) 操作簡單方便，除了底層免除了復雜的與環境進行配置的工作，操作也更加方便，配置好的Docker鏡像在部署時候只需要一條指令就可以了。
4) 開發、應用環境一致，Docker讓資料庫能做到 開發---測試---實施應用 三個階段的環境是完全一致的。降低開發到應用過程中的工作量，開發出來就能保證實際應用環境上能同樣的運行。
5) 系統穩定，因為Docker的隔離作用，將應用與OS獨立開，這樣能更好保證整個系統的穩定性。
6) 節省系統資源，系統只需要運行一個統一的環境就可以，不需要佔用太多性能去支持運行環境本身，能將更多的系統資源投入到應用當中。
有了這些特性， Docker+資料庫，將成為一個資料庫發展的新方向，Docker這樣的通用性和簡單操作解決方案，大大提高了資料庫使用的效率，幫助使用者節約了大量成本。
Docker是如今技術圈的新潮流，開發人員是最樂見於Docker的這種應用部署模式，因為應用的生命周期起始於開發人員的開發系統，經過開發，測試，壓力測試，等過程，最終應用發布到生產系統，並可能在不同的生產系統中遷移。應用開發人員對此都會有切身的體會，任何微小的運行環境的錯誤都會導致應用出現問題，尤其在講究快速敏捷的今天，應用模塊，新的代碼，新的配置，被快速的加入應用的環境中，可能還沒等寫入到文檔，新特性就已經被推送到生產上了。作為一個新的技術，筆者也希望更多的產品能加強與Docker的結合，幫助產品更好的使用。
博文出處：http://segmentfault.com/a/1190000002930030