Ⅰ Redis和Memcached的區別
1、redis和Memcache都是將數據存放在內存中，都是內存資料庫。不過memcache還可以用於緩存其他東西，例如圖片，視頻等等
2、Redis不僅僅支持簡單的k/v類型的數據，同時還提供list,set,hash等數據結構的存儲
3、虛擬內存-redis當物流內存用完時，可以將一些很久沒用的value交換到磁碟
4、過期策略-memcache在set時就指定，例如set key1 0 0 8，即永不過期。Redis可以通過例如expire設定，例如expire
name 105、分布式-設定memcache集群，利用magent做一主多從，redis可以做一主多從。都可以一主一叢
6、存儲數據安全-memcache掛掉後，數據沒了，redis可以定期保存到磁碟(持久化)
7、災難恢復-memcache掛掉後，數據不可恢復，redis數據丟失後可以通過aof恢復
8、Redis支持數據的備份，即master-slave模式的數據備份
9、應用場景不一樣，redis除了作為Nosql資料庫使用外，還能用做消息隊列，數據堆棧和數據緩存等;Memcache適合於緩存SQL語句，數據集，用戶臨時性數據，延遲查詢數據和session等
使用場景
1,如果有持久方面的需求或對數據類型和處理有要求的應該選擇redis
2,如果簡單的key/value存儲應該選擇memcached
Ⅱ 什麼是memcached
memcached是一種高性能的內存式緩存系統，通過將數據存儲在內存中減少讀取資料庫的次數
Ⅲ 談談redis，memcache，mongodb的區別和具體應用場景
從以下幾個維度，對 redis、memcache、mongoDB 做了對比。
1、性能
都比較高，性能對我們來說應該都不是瓶頸。
總體來講，TPS 方面 redis 和 memcache 差不多，要大於 mongodb。
2、操作的便利性
memcache 數據結構單一。（key-value）
redis 豐富一些，數據操作方面，redis 更好一些，較少的網路 IO 次數，同時還提供 list，set，
hash 等數據結構的存儲。
mongodb 支持豐富的數據表達，索引，最類似關系型資料庫，支持的查詢語言非常豐富。
3、內存空間的大小和數據量的大小
redis 在 2.0 版本後增加了自己的 VM 特性，突破物理內存的限制；可以對 key value 設置過
期時間（類似 memcache）
memcache 可以修改最大可用內存,採用 LRU 演算法。Memcached 代理軟體 magent，比如建立
10 台 4G 的 Memcache 集群，就相當於有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b
10.1.2.3:14000 mongoDB 適合大數據量的存儲，依賴操作系統 VM 做內存管理，吃內存也比較厲害，服務
不要和別的服務在一起。
4、可用性（單點問題）
對於單點問題，
redis，依賴客戶端來實現分布式讀寫；主從復制時，每次從節點重新連接主節點都要依賴整
個快照,無增量復制，因性能和效率問題，
所以單點問題比較復雜；不支持自動 sharding,需要依賴程序設定一致 hash 機制。
一種替代方案是，不用 redis 本身的復制機制，採用自己做主動復制（多份存儲），或者改成
增量復制的方式（需要自己實現），一致性問題和性能的權衡
Memcache 本身沒有數據冗餘機制，也沒必要；對於故障預防，採用依賴成熟的 hash 或者環
狀的演算法，解決單點故障引起的抖動問題。
mongoDB 支持 master-slave,replicaset（內部採用 paxos 選舉演算法，自動故障恢復）,auto sharding 機制，對客戶端屏蔽了故障轉移和切分機制。
5、可靠性（持久化）
對於數據持久化和數據恢復，
redis 支持（快照、AOF）：依賴快照進行持久化，aof 增強了可靠性的同時，對性能有所影
響
memcache 不支持，通常用在做緩存,提升性能；
MongoDB 從 1.8 版本開始採用 binlog 方式支持持久化的可靠性
6、數據一致性（事務支持）
Memcache 在並發場景下，用 cas 保證一致性redis 事務支持比較弱，只能保證事務中的每個操作連續執行
mongoDB 不支持事務
7、數據分析
mongoDB 內置了數據分析的功能(maprece),其他不支持
8、應用場景
redis：數據量較小的更性能操作和運算上
memcache：用於在動態系統中減少資料庫負載，提升性能;做緩存，提高性能（適合讀多寫
少，對於數據量比較大，可以採用 sharding）
MongoDB:主要解決海量數據的訪問效率問題。
表格比較：
memcache redis 類型 內存資料庫 內存資料庫
數據類型 在定義 value 時就要固定數據類型 不需要
有字元串，鏈表，集 合和有序集合
虛擬內存 不支持 支持
過期策略 支持 支持
分布式 magent master-slave，一主一從或一主多從
存儲數據安全 不支持 使用 save 存儲到 mp.rdb 中
災難恢復 不支持 append only file(aof)用於數據恢復
性能
1、類型——memcache 和 redis 都是將數據存放在內存，所以是內存資料庫。當然，memcache 也可用於緩存其他東西，例如圖片等等。
2、 數據類型——Memcache 在添加數據時就要指定數據的位元組長度,而 redis 不需要。
3、 虛擬內存——當物理內存用完時，可以將一些很久沒用到的 value 交換到磁碟。
4、 過期策略——memcache 在 set 時就指定，例如 set key1 0 0 8,即永不過期。Redis 可以通
過例如 expire 設定，例如 expire name 10。
5、 分布式——設定 memcache 集群，利用 magent 做一主多從;redis 可以做一主多從。都可
以一主一從。
6、 存儲數據安全——memcache 斷電就斷了，數據沒了；redis 可以定期 save 到磁碟。
7、 災難恢復——memcache 同上，redis 丟了後可以通過 aof 恢復。
Memecache 埠 11211
yum -y install memcached
yum -y install php-pecl-memcache
/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid
-d 啟動一個守護進程
-p 埠
-m 分配的內存是 M
-c 最大運行並發數-P memcache 的 pid
//0 壓縮（是否 MEMCACHE_COMPRESSED） 30 秒失效時間
//delete 5 是 timeout <?php
$memcache = new Memcache; $memcache -> connect('127.0.0.1', 11211); $memcache -> set('name','yang',0,30);
if(!$memcache->add('name','susan',0, 30)) {
//echo 'susan is exist'; }$memcache -> replace('name', 'lion', 0, 300); echo $memcache -> get('name');
//$memcache -> delete('name', 5);
printf "stats\r\n" | nc 127.0.0.1 11211
telnet localhost 11211 stats quit 退出
Redis 的配置文件 埠 6379
/etc/redis.conf 啟動 Redis
redis-server /etc/redis.conf 插入一個值
redis-cli set test "phper.yang" 獲取鍵值
redis-cli get test 關閉 Redis
redis-cli shutdown 關閉所有
redis-cli -p 6379 shutdown <?php
$redis=new
Redis(); $redis->connect('127.0.0.1',6379); $redis->set('test',
'Hello World'); echo $redis->get('test'); Mongodb
apt-get install mongo mongo 可以進入 shell 命令行
pecl install mongo Mongodb 類似 phpmyadmin 操作平台 RockMongo
Ⅳ 內存資料庫主流的有哪些，並給出各自特點！
內存資料庫從范型上可以分為關系型內存資料庫和鍵值型內存資料庫。
在實際應用中內存資料庫主要是配合oracle或mysql等大型關系資料庫使用，關注性能。
作用類似於緩存，並不注重數據完整性和數據一致性。
基於鍵值型的內存資料庫比關系型更加易於使用，性能和可擴展性更好，因此在應用上比關系型的內存資料庫使用更多。
比較FastDB、Memcached和Redis主流內存資料庫的功能特性。
FastDB的特點包括如下方面：
1、FastDB不支持client-server架構因而所有使用FastDB的應用程序必須運行在同一主機上；
2、fastdb假定整個資料庫存在於RAM中，並且依據這個假定優化了查詢演算法和介面。
3、fastdb沒有資料庫緩沖管理開銷，不需要在資料庫文件和緩沖池之間傳輸數據。
4、整個fastdb的搜索演算法和結構是建立在假定所有的數據都存在於內存中的，因此數據換出的效率不會很高。
5、Fastdb支持事務、在線備份以及系統崩潰後的自動恢復。
6、fastdb是一個面向應用的資料庫，資料庫表通過應用程序的類信息來構造。
FastDB不能支持Java API介面，這使得在本應用下不適合使用FastDB。
Memcached
Memcached是一種基於Key-Value開源緩存伺服器系統，主要用做資料庫的數據高速緩沖，並不能完全稱為資料庫。
memcached的API使用三十二位元的循環冗餘校驗（CRC-32）計算鍵值後，將資料分散在不同的機器上。當表格滿了以後，接下來新增的資料會以LRU機制替換掉。由於 memcached通常只是當作緩存系統使用，所以使用memcached的應用程式在寫回較慢的系統時（像是後端的資料庫）需要額外的程序更新memcached內的資料。
memcached具有多種語言的客戶端開發包，包括：Perl、PHP、JAVA、C、Python、Ruby、C#。
Redis
Redis是一個高性能的key-value資料庫。redis的出現，很大程度補償了memcached這類keyvalue存儲的不足，在部分場合可以對關系資料庫起到很好的補充作用。它提供了C++、Java、Python，Ruby，Erlang，PHP客戶端。
Ⅳ Redis和Memcached的區別
Redis的作者Salvatore Sanfilippo曾經對這兩種基於內存的數據存儲系統進行過比較：
1、Redis支持伺服器端的數據操作：Redis相比Memcached來說，擁有更多的數據結構和並支持更豐富的數據操作，通常在Memcached里，你需要將數據拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和數據體積。在Redis中，這些復雜的操作通常和一般的GET/SET一樣高效。所以，如果需要緩存能夠支持更復雜的結構和操作，那麼Redis會是不錯的選擇。
2、內存使用效率對比：使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis採用hash結構來做key-value存儲，由於其組合式的壓縮，其內存利用率會高於Memcached。
3、性能對比：由於Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。
具體為什麼會出現上面的結論，以下為收集到的資料：
1、數據類型支持不同
與Memcached僅支持簡單的key-value結構的數據記錄不同，Redis支持的數據類型要豐富得多。最為常用的數據類型主要由五種：String、Hash、List、Set和Sorted Set。Redis內部使用一個redisObject對象來表示所有的key和value。redisObject最主要的信息如圖所示：
type代表一個value對象具體是何種數據類型，encoding是不同數據類型在redis內部的存儲方式，比如：type=string代表value存儲的是一個普通字元串，那麼對應的encoding可以是raw或者是int，如果是int則代表實際redis內部是按數值型類存儲和表示這個字元串的，當然前提是這個字元串本身可以用數值表示，比如:」123″ 「456」這樣的字元串。只有打開了Redis的虛擬內存功能，vm欄位欄位才會真正的分配內存，該功能默認是關閉狀態的。
1）String
常用命令：set/get/decr/incr/mget等；
應用場景：String是最常用的一種數據類型，普通的key/value存儲都可以歸為此類；
實現方式：String在redis內部存儲默認就是一個字元串，被redisObject所引用，當遇到incr、decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。
常用命令：hget/hset/hgetall等
應用場景：我們要存儲一個用戶信息對象數據，其中包括用戶ID、用戶姓名、年齡和生日，通過用戶ID我們希望獲取該用戶的姓名或者年齡或者生日；
實現方式：Redis的Hash實際是內部存儲的Value為一個HashMap，並提供了直接存取這個Map成員的介面。如圖所示，Key是用戶ID, value是一個Map。這個Map的key是成員的屬性名，value是屬性值。這樣對數據的修改和存取都可以直接通過其內部Map的Key(Redis里稱內部Map的key為field), 也就是通過 key(用戶ID) + field(屬性標簽) 就可以操作對應屬性數據。當前HashMap的實現有兩種方式：當HashMap的成員比較少時Redis為了節省內存會採用類似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，這時對應的value的redisObject的encoding為zipmap，當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。
常用命令：lpush/rpush/lpop/rpop/lrange等；
應用場景：Redis list的應用場景非常多，也是Redis最重要的數據結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現；
實現方式：Redis list的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，Redis內部的很多實現，包括發送緩沖隊列等也都是用的這個數據結構。
常用命令：sadd/spop/smembers/sunion等；
應用場景：Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重復數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的；
實現方式：set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。
常用命令：zadd/zrange/zrem/zcard等；
應用場景：Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過用戶額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重復的集合列表，那麼可以選擇sorted set數據結構，比如twitter 的public timeline可以以發表時間作為score來存儲，這樣獲取時就是自動按時間排好序的。
實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表裡存放的是所有的成員，排序依據是HashMap里存的score,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。
appendfsync no 當設置appendfsync為no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩沖區中的數據寫到磁碟上。
appendfsync everysec 當設置appendfsync為everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩沖區中的數據寫到磁碟。但是當這一次的fsync調用時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鍾。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。所以結論就是，在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鍾會進行一次fsync操作。這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的數據，一次性將日誌寫到磁碟。
appednfsync always 當設置appendfsync為always時，每一次寫操作都會調用一次fsync，這時數據是最安全的，當然，由於每次都會執行fsync，所以其性能也會受到影響。
2）Hash
3）List
4）Set
5）Sorted Set
2、內存管理機制不同
在Redis中，並不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。當物理內存用完時，Redis可以將一些很久沒用到的value交換到磁碟。Redis只會緩存所有的key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據「swappability = age*log(size_in_memory)」計算出哪些key對應的value需要swap到磁碟。然後再將這些key對應的value持久化到磁碟中，同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由於Redis將內存中的數據swap到磁碟中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個操作，直到子線程完成swap操作後才可以進行修改。當從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那麼Redis就需要從swap文件中載入相應數據，然後再返回給請求方。 這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件載入後才會相應。這種策略在客戶端的數量較小，進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大並發的情況的。所以Redis運行我們設置I/O線程池的大小，對需要從swap文件中載入相應數據的讀取請求進行並發操作，減少阻塞的時間。
對於像Redis和Memcached這種基於內存的資料庫系統來說，內存管理的效率高低是影響系統性能的關鍵因素。傳統C語言中的malloc/free函數是最常用的分配和釋放內存的方法，但是這種方法存在著很大的缺陷：首先，對於開發人員來說不匹配的malloc和free容易造成內存泄露；其次頻繁調用會造成大量內存碎片無法回收重新利用，降低內存利用率；最後作為系統調用，其系統開銷遠遠大於一般函數調用。所以，為了提高內存的管理效率，高效的內存管理方案都不會直接使用malloc/free調用。Redis和Memcached均使用了自身設計的內存管理機制，但是實現方法存在很大的差異，下面將會對兩者的內存管理機制分別進行介紹。
Memcached默認使用Slab Allocation機制管理內存，其主要思想是按照預先規定的大小，將分配的內存分割成特定長度的塊以存儲相應長度的key-value數據記錄，以完全解決內存碎片問題。Slab Allocation機制只為存儲外部數據而設計，也就是說所有的key-value數據都存儲在Slab Allocation系統里，而Memcached的其它內存請求則通過普通的malloc/free來申請，因為這些請求的數量和頻率決定了它們不會對整個系統的性能造成影響Slab Allocation的原理相當簡單。 如圖所示，它首先從操作系統申請一大塊內存，並將其分割成各種尺寸的塊Chunk，並把尺寸相同的塊分成組Slab Class。其中，Chunk就是用來存儲key-value數據的最小單位。每個Slab Class的大小，可以在Memcached啟動的時候通過制定Growth Factor來控制。假定圖中Growth Factor的取值為1.25，如果第一組Chunk的大小為88個位元組，第二組Chunk的大小就為112個位元組，依此類推。
當Memcached接收到客戶端發送過來的數據時首先會根據收到數據的大小選擇一個最合適的Slab Class，然後通過查詢Memcached保存著的該Slab Class內空閑Chunk的列表就可以找到一個可用於存儲數據的Chunk。當一條資料庫過期或者丟棄時，該記錄所佔用的Chunk就可以回收，重新添加到空閑列表中。從以上過程我們可以看出Memcached的內存管理制效率高，而且不會造成內存碎片，但是它最大的缺點就是會導致空間浪費。因為每個Chunk都分配了特定長度的內存空間，所以變長數據無法充分利用這些空間。如圖 所示，將100個位元組的數據緩存到128個位元組的Chunk中，剩餘的28個位元組就浪費掉了。
Redis的內存管理主要通過源碼中zmalloc.h和zmalloc.c兩個文件來實現的。Redis為了方便內存的管理，在分配一塊內存之後，會將這塊內存的大小存入內存塊的頭部。如圖所示，real_ptr是redis調用malloc後返回的指針。redis將內存塊的大小size存入頭部，size所佔據的內存大小是已知的，為size_t類型的長度，然後返回ret_ptr。當需要釋放內存的時候，ret_ptr被傳給內存管理程序。通過ret_ptr，程序可以很容易的算出real_ptr的值，然後將real_ptr傳給free釋放內存。
Redis通過定義一個數組來記錄所有的內存分配情況，這個數組的長度為ZMALLOC_MAX_ALLOC_STAT。數組的每一個元素代表當前程序所分配的內存塊的個數，且內存塊的大小為該元素的下標。在源碼中，這個數組為zmalloc_allocations。zmalloc_allocations[16]代表已經分配的長度為16bytes的內存塊的個數。zmalloc.c中有一個靜態變數used_memory用來記錄當前分配的內存總大小。所以，總的來看，Redis採用的是包裝的mallc/free，相較於Memcached的內存管理方法來說，要簡單很多。
3、數據持久化支持
Redis雖然是基於內存的存儲系統，但是它本身是支持內存數據的持久化的，而且提供兩種主要的持久化策略：RDB快照和AOF日誌。而memcached是不支持數據持久化操作的。
1）RDB快照
Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。但是一個持續寫入的資料庫如何生成快照呢？Redis藉助了fork命令的 on write機制。在生成快照時，將當前進程fork出一個子進程，然後在子進程中循環所有的數據，將數據寫成為RDB文件。我們可以通過Redis的save指令來配置RDB快照生成的時機，比如配置10分鍾就生成快照，也可以配置有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規則，不需要重啟Redis。
Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然後通過原子性rename系統調用將臨時文件重命名為RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。RDB有他的不足，就是一旦資料庫出現問題，那麼我們的RDB文件中保存的數據並不是全新的，從上次RDB文件生成到Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的。
2）AOF日誌
AOF日誌的全稱是append only file，它是一個追加寫入的日誌文件。與一般資料庫的binlog不同的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標准命令。只有那些會導致數據發生修改的命令才會追加到AOF文件。每一條修改數據的命令都生成一條日誌，AOF文件會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日誌還是會寫到原來老的AOF文件中，同時還會記錄在內存緩沖區中。當重完操作完成後，會將所有緩沖區中的日誌一次性寫入到臨時文件中。然後調用原子性的rename命令用新的AOF文件取代老的AOF文件。
AOF是一個寫文件操作，其目的是將操作日誌寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的流程。在Redis中對AOF調用write寫入後，通過appendfsync選項來控制調用fsync將其寫到磁碟上的時間，下面appendfsync的三個設置項，安全強度逐漸變強。
對於一般性的業務需求，建議使用RDB的方式進行持久化，原因是RDB的開銷並相比AOF日誌要低很多，對於那些無法忍數據丟失的應用，建議使用AOF日誌。
4、集群管理的不同
Memcached是全內存的數據緩沖系統，Redis雖然支持數據的持久化，但是全內存畢竟才是其高性能的本質。作為基於內存的存儲系統來說，機器物理內存的大小就是系統能夠容納的最大數據量。如果需要處理的數據量超過了單台機器的物理內存大小，就需要構建分布式集群來擴展存儲能力。
Memcached本身並不支持分布式，因此只能在客戶端通過像一致性哈希這樣的分布式演算法來實現Memcached的分布式存儲。下圖給出了Memcached的分布式存儲實現架構。當客戶端向Memcached集群發送數據之前，首先會通過內置的分布式演算法計算出該條數據的目標節點，然後數據會直接發送到該節點上存儲。但客戶端查詢數據時，同樣要計算出查詢數據所在的節點，然後直接向該節點發送查詢請求以獲取數據。
相較於Memcached只能採用客戶端實現分布式存儲，Redis更偏向於在伺服器端構建分布式存儲。最新版本的Redis已經支持了分布式存儲功能。Redis Cluster是一個實現了分布式且允許單點故障的Redis高級版本，它沒有中心節點，具有線性可伸縮的功能。下圖給出Redis Cluster的分布式存儲架構，其中節點與節點之間通過二進制協議進行通信，節點與客戶端之間通過ascii協議進行通信。在數據的放置策略上，Redis Cluster將整個key的數值域分成4096個哈希槽，每個節點上可以存儲一個或多個哈希槽，也就是說當前Redis Cluster支持的最大節點數就是4096。Redis Cluster使用的分布式演算法也很簡單：crc16( key ) % HASH_SLOTS_NUMBER。
為了保證單點故障下的數據可用性，Redis Cluster引入了Master節點和Slave節點。在Redis Cluster中，每個Master節點都會有對應的兩個用於冗餘的Slave節點。這樣在整個集群中，任意兩個節點的宕機都不會導致數據的不可用。當Master節點退出後，集群會自動選擇一個Slave節點成為新的Master節點。
Ⅵ 內存資料庫主流的有哪些，並給出各自特點
目前關系型內存資料庫主要有MySQL（使用內存存儲引擎）、SQL Server（In-Memory OLTP)、數蠶內存資料庫、Oracle 內存資料庫。
MySQL：免費產品，內存存儲引擎使用較少。
SQL Server：微軟的商業化產品，是為了適應大數據等業務產品新添加的存儲引擎，微軟SQL語句兼容性好，商業化成熟度高。
數蠶內存資料庫：數蠶科技針對中小型企業的內存資料庫，查詢響應快，支持多種sql特性。
Oracle 內存資料庫：基於內存計算的關系資料庫， 提供了響應時間極 短且吞吐量極高的應用程序。
非關系型內存資料庫主要有FastDB、Memcached和Redis等主流內存資料庫。結構簡單，支持數據結構多以基礎數據結構為主，一般應用於緩存等非關鍵數據存儲，其優點是數據查詢速度快，對下層編程介面良好。
Ⅶ mysql 怎麼使用memcached
一、Memcached簡介
memcached
常被用來加速應用程序的處理，在這里，我們將著重於介紹將它部署於應用程序和環境中的最佳實踐。這包括應該存儲或不應存儲哪些、如何處理數據的靈活分布以
及如何調節用來更新 memcached 和所存儲數據的方法。我們還將介紹對高可用性的解決方案的支持，比如 IBM WebSphere® eXtreme
Scale。
所有的應用程序，特別是很多 web
應用程序都需要優化它們訪問客戶機和將信息返回至客戶機的速度。可是，通常，返回的都是相同的信息。從數據源(資料庫或文件系統)載入數據十分低效，若是每次想要訪問該信息時都運行相同的查詢，就尤顯低效。
雖然很多 web 伺服器都可被配置成使用緩存發回信息，但那與大多數應用程序的動態特性無法相適。而這正是 memcached
的用武之地。它提供了一個通用的內存存儲器，可保存任何東西，包括本地語言的對象，這就讓您可以存儲各種各樣的信息並可以從諸多的應用程序和環境訪問這些信息。
二、基礎知識
memcached 是一個開源項目，旨在利用多個伺服器內的多餘 RAM
來充當一個可存放經常被訪問信息的內存緩存。這里的關鍵是使用了術語緩存：memcached 為載入自他處的信息提供的是內存中的暫時存儲。
比如，考慮這樣一個典型的基於 web 的應用程序。即便是一個動態網站可能也會有一些組件或信息常量是貫穿頁面整個生命周期的。在一個博客站點內，針對單個
blog post
的類別列表不大可能在頁面查看間經常性地變更。每次都通過一個對資料庫的查詢載入此信息相對比較昂貴，特別是在數據沒有更改的情況下，就更是如此。從圖 1
可以看到一個博客站點內可被緩存的頁面分區。
圖1.一個典型的博客頁面內的可緩存元素
將這種結構放在 blog 站點的其他元素，poster 信息、注釋 — 設置 blog post 本身 —
進行推斷，可以看出為了顯示主頁的內容很可能需要發生 10-20 次資料庫查詢和格式化。
每天對數百甚至數千的的頁面查看重復此過程，那麼您的伺服器和應用程序執行的查詢要遠遠多於為了顯示頁面內容所需執行的查詢。
通過使用 memcached，可以將載入自資料庫的格式化信息存儲為一種可直接用在 Web 頁面上的格式。並且由於信息是從 RAM
而不是通過資料庫和其他處理從磁碟載入的，所以對信息的訪問幾乎是瞬時的。
再強調一下，memcached 是一個用來存儲常用信息的緩存，有了它，您便無需從緩慢的資源，比如磁碟或資料庫，載入並處理信息了。
對 memcached 的介面是通過網路連接提供的。這意味著您可以在多個客戶機間共享單個的 memcached
伺服器(或多個伺服器，如本文稍後所示的)。這個網路介面非常迅速，並且為了改善性能，伺服器會故意不支持身份驗證或安全性通信。但這不應限制部署選項。
memcached 伺服器應該存在於您網路的內部。網路介面的實用性以及可以部署多個 memcached 實例的簡便性讓您可以使用多個機器上的多餘 RAM
來提高您緩存的整體大小。
三、存儲方法
memcached 的存儲方法是一個簡單的鍵/值對，類似於很多語言內的散列或關聯數組。通過提供鍵和值來將信息存儲到 memcached
內，通過按特定的鍵請求信息來恢復信息。
信息會無限期地保留在緩存內，除非發生如下的情況：
為緩存分配的內存耗盡 — 在這種情況下，memcached 使用
LRU(最近最少使用)方法從此緩存刪除條目。最近未曾使用的條目會從此緩存中先刪除，最舊的最先訪問。
條目被明確刪除 — 總是可以從此緩存內刪除條目。
條目過期失效 — 各條目均有一個有效的期限以便針對此鍵存儲的信息在過於陳舊時可從緩存中清除這些條目。
上述這些情況可以與您應用程序的邏輯綜合使用以便確保緩存內的信息是最新的。有了這些基礎知識後，讓我們來看看在應用程序內如何能最好地利用
memcached。
四、何時使用memcached?
在使用 memcached 改進應用程序性能時，可以對一些關鍵的過程和步驟進行修改。
在載入信息時，典型的場景如圖 2 所示。
圖2.載入要顯示的信息的典型順序
一般而言，這些步驟是：
執行一個或多個查詢來從資料庫載入信息
格式化適合於顯示(或進一步處理)的信息
使用或顯示格式化了的數據
在使用 memcached 時，為配合這個緩存，可對應用程序的邏輯進行稍許修改：
盡量從緩存載入信息
如果存在，使用信息的被緩存版本
如果它不存在：
執行一個或多個查詢來從資料庫載入信息
格式化適合於顯示或進一步處理的信息
將信息存儲到緩存內
使用格式化了的數據
圖 3 是對這些步驟的總結。
圖3.在使用memcached時載入適合於顯示的信息
數據載入成為了至多三個步驟的一個過程，從緩存載入數據或從資料庫(視情況而定)載入數據並存儲在緩存內。
當這個過程首次發生時，數據將正常地從資料庫或其他數據源載入，然後再存儲到 memcached 內。當下一次訪問此信息時，它就會從 memcached
拉出，而不是從資料庫載入，節省了時間和 CPU 循環。
問題的另一個方面是要確保如果更改了要存儲在 memcached 內的信息，在更新後端信息的同時還要更新 memcached 的版本。這會讓圖 4
內所示的這個典型順序發生稍許變化，如 圖 5 所示。
圖4.在一個典型的應用程序內更新或存儲數據
圖 5 顯示了使用 memcached 後發生了變化的流程。
圖5.在使用memcached時更新或存儲數據
比如，仍以博客站點為例，在博客系統更新資料庫內的類別列表時，更新應該遵循如下順序：
更新資料庫內的類別列表
格式化信息
將信息存儲到 memcached 內
將信息返回至客戶機
memcached 內的存儲操作是原子的，所以信息的更新不會讓客戶機只獲得部分數據;它們獲得的或者是老版本，或者是新版本。
對於大多數應用程序，這兩個操作是您惟一需要注意的。在訪問他人使用的數據時，它會自動被添加到這個緩存內，而且如果對該數據進行了更改，此緩存內也會自動進行更新。
五、鍵、名稱空間和值
memcached
另一個需要重點考慮的因素是如何組織和命名存儲在緩存內的這些數據。從之前博客站點的例子中，不難看出需要使用一種一致的命名結構以便您能載入博客類別、歷史和其他信息，然後再在載入信息(並更新緩存)時或者在更新數據(同樣也要更新緩存)時使用。
使用的何種具體的命名系統特定於應用程序，但通常可以使用一種與現有應用程序類似的結構，並且這種結構很可能基於某種惟一識別符。當從資料庫拉出信息或在整理信息集時，就會發生這種情況。
以 blog post 為例，可以在一個具有鍵 category-list 的項中存儲類別列表。與此 post ID 對應的單個 post，比如
blogpost-29 相關的值都可以使用，而該項的注釋則可以存儲在 blogcomments-29內，其中 29 就是這個 blog post 的
ID。這樣一來， 您就可以將各種各樣的信息存儲在緩存內，使用不同的前綴來標識這些信息。
memcached 鍵/值存儲的簡便性(以及安全性的缺乏)意味著如果您想要在使用同一個 memcached
伺服器的同時支持多個應用程序，那麼就可以考慮使用其他格式的量詞來標識數據屬於某種特定的應用程序。比如，可以添加像 blogapp:blogpost-29
這樣的應用程序前綴。這些鍵是沒有格式的，所以可以使用任何字元串作為鍵的名稱。
在存儲值的方面，應該確保存儲在緩存內的信息適合於您的應用程序。比如，對於這個博客系統，您可能想要存儲被博客應用程序使用的對象以便格式化博客信息，而不是原始的
HTML。如果同一個基礎結構用在應用程序內的多個地方，這一點更具實用性。
大多數語言的介面，包括 Java™、Perl、PHP 等，都能串列化語言對象以便存儲在 memcached
內。這就讓您可以存儲並隨後從內存存儲恢復全部對象，而不是在您的應用程序內手動重構它們。
很多對象，或它們使用的結構，都基於某種散列或數組結構。對於跨語言的環境，比如在 JSP 環境和 JavaScript
環境間共享相同信息，可以使用一種架構中立的格式，比如 JavaScript Object Notation (JSON) 甚或 XML。
六、填充並使用memcached
作為一種開源產品以及一種最初開發用來工作於現有開源環境內的產品，memcached 受大量環境和平台支持。與 memcached
伺服器通信的介面有很多，並常常具有針對所有語言的多個實現。參見參考資料 以獲得常用的庫和工具箱。
要列出所有受支持的介面和環境不太可能，但它們均支持 memcached 協議提供的基礎
API。這些描述已經被簡化並應用在不同語言的上下文內，在這些語言中，使用不同的值可指示錯誤。主要的函數有：
get(key) — 從存儲了特定鍵的 memcached 獲得信息。 如果鍵不存在，就返回錯誤。
set(key, value [, expiry]) —
使用緩存內的標識符鍵存儲這個特定的值。如果鍵已經存在，那麼它就會被更新。期滿時間的單位為秒，並且如果值小於 30 天
(30*24*60*60)，那麼就用作相對時間，如果值大於 30 天，那麼就用作絕對時間 (epoch)。
add(key, value [, expiry]) —
如果鍵不存在就將這個鍵添加到緩存內，如果鍵已經存在就返回錯誤。如果您想要顯式地添加一個新鍵而又不會因它已經存在而更新它，那麼這個函數將十分有用。
replace(key, value [, expiry]) — 更新此特定鍵的值，如果鍵不存在就返回一個錯誤。
delete(key [, time]) —
從緩存中刪除此鍵/值對。如果您提供一個時間，那麼添加具有此鍵的一個新值就會被阻塞這個特定的時期。超時讓您可以確保此值總是可以重新讀取自您的數據中心。
incr(key [, value]) — 為特定的鍵增 1 或特定的值。只適用於數值。
decr(key [, value]) — 為特定的鍵減 1 或特定的值，只適用於數值。
flush_all — 讓緩存內的所有當前條目無效(或到期失效)。
比如，在 Perl 內，基本 set 操作可以如清單 1 所示的那樣處理。
清單 1. Perl 內的基本 set 操作
use Cache::Memcached;
my $cache = new Cache::Memcached {
'servers' => [
'localhost:11211',
],
};
$cache->set('mykey', 'myvalue');
Ruby 內的相同的基本操作如清單 2 所示。
清單 2. Ruby 內的基本 set 操作
require 'memcache'
memc = MemCache::new '192.168.0.100:11211'
memc["mykey"] = "myvalue"
在兩個例子中可以看到相同的基本結構：設置 memcached 伺服器，然後分配或設置值。其他的介面也可用，包括適合於 Java
技術的那些介面，讓您可以在 WebSphere 應用程序內使用 memcached。memcached 介面類允許將 Java 對象直接序列化到
memcached 以便於存儲和載入復雜的結構。當在像 WebSphere 這樣的環境內進行部署時，有兩個事情非常重要：服務的彈性(在 memcached
不可用時如何做)以及如何提高緩存存儲量來改進在使用多個應用程序伺服器或在使用像 WebSphere eXtreme Scale
這樣的環境時的性能。我們接下來就來看看這兩個問題。
七、彈性和可用性
有關 memcached
最常見的一個問題是：「若緩存不可用了，會發生什麼情況呢?」正如之前章節中明示的，緩存內的信息不應該成為信息的的惟一資源。必須要能夠從其他位置載入存儲在緩存內的數據。
雖然，無法從緩存訪問信息將會減緩應用程序的性能，但它不應該阻止應用程序的運轉。可能會發生這樣幾個場景：
如果 memcached 服務宕掉，應用程序應該回退到從原始數據源載入信息並對信息進行顯示所需的格式化。此應用程序還應繼續嘗試在 memcached
內載入和存儲信息。
一旦 memcached
伺服器恢復可用，應用程序就應該自動嘗試存儲數據。沒有必要強制重載已緩存了的數據，可以使用標準的訪問來用信息載入和填充緩存。最終，緩存將會被最常用的數據重新填充。
再次重申，memcached 是信息的緩存但並非惟一的數據源。memcached 伺服器不可用不應該是應用程序的終結，雖然這意味著在
memcached 伺服器恢復正常之前性能會有所降低。實際上，memcached
伺服器相對簡單，並且雖然不是絕對無故障的，但它的簡單性的結果就是它很少會出錯。
八、分配緩存
memcached 伺服器只是網路上針對一些鍵存儲值的一個緩存。如果有多台機器，那麼很自然地會想要在所有多餘機器上設置一個 memcached
的實例來提供一個超大的聯網 RAM 緩存存儲。
有了這個想法後，還有一種想當然是需要使用某種分配或復制機制來在機器之間復制鍵/值對。這種方式的問題是如果這么做反而會減少可用的 RAM
緩存，而不是增加。如圖 6 所示，可以看出這里有三個應用程序伺服器，每個伺服器都可以訪問一個 memcached 實例。
圖6.多重memcached實例的不正確使用
盡管每個 memcached 實例都是 1 GB 的大小(產生 3 GB 的 RAM 緩存)，但如果每個應用程序伺服器只有其自己的緩存(或者在
memcached 之間存在著數據的復制)，那麼整個安裝也仍只能有 1 GB 的緩存在每個實例間復制。
由於 memcached 通過一個網路介面提供信息，因此單個的客戶機可以從它所能訪問的任何一個 memcached
實例訪問數據。如果數據沒有跨每個實例被復制，那麼最終在每個應用程序伺服器上，就可以有 3 GB 的 RAM 緩存可用，如圖 7 所示。
圖7.多重memcached實例的正確使用
這個方法的問題是選擇哪個伺服器來儲存鍵/值對，以及當想要重新獲得一個值時，如何決定要與哪個 memcached
伺服器對話。問題的解決方案就是忽略復雜的東西，比如查找表，或是寄望 memcached 伺服器來為您處理這個過程。而 memcached
客戶機則必須要力求簡單。
memcached 客戶機不必決定此信息，它只需對在存儲信息時指定的鍵使用一個簡單的散列演算法。當想要從一列 memcached
伺服器存儲或獲取信息時，memcached 客戶機就會用一個一致的散列演算法從這個鍵獲取一個數值。舉個例子，鍵 mykey 被轉換成數值 23875
。是保存還是獲取信息無關緊要，這個鍵將總是被用作惟一標識符來從 memcached 伺服器載入，因此在本例中，「mykey」 散列轉化後對應的值總是
23875。
如果有兩個伺服器，那麼 memcached 客戶機將對這個數值進行一個簡單的運算(例如，系數)來決定它應將此值存儲在第一個還是第二個配置了的
memcached 實例上。
當存儲一個值時，客戶機會從這個鍵確定出散列值以及它原來存儲在哪個伺服器上。當獲取一個值時，客戶機會從這個鍵確定出相同的散列值並會選擇相同的伺服器來獲取信息。
如果在每個應用程序伺服器上使用的是相同的伺服器列表(並且順序相同)，那麼當需要保存或檢索同一個鍵時，每個應用程序伺服器都將選擇同一個
伺服器。現在，在這個例子中，有 3GB 的 memcached 空間可以共享，而不是同一個 1 GB
的空間的復制，這就帶來了更多的可用緩存，並很有可能會提高有多個用戶情況下的應用程序的性能。
九、如何能不使用memcached?
盡管 memcached 很簡單，但 memcached 實例有時候還是會被不正確地使用。
memcached不是一個資料庫
最常見的 memcached 誤用就是把它用作一個數據存儲，而不是一個緩存。memcached
的首要目的就是加快數據的響應時間，否則數據從其他數據源構建或恢復需要很長時間。一個典型的例子就是從一個資料庫中恢復信息，特別是在信息顯示給用戶前
需要對信息進行格式化或處理的時候。Memcached 被設計用來將信息存儲在內存中以避免每次在數據需要恢復時重復執行相同的任務。
切不可將 memcached 用作運行應用程序所需信息的惟一信息源;數據應總是可以從其他信息源獲取。此外，要記住 memcached
只是一個鍵/值的存儲。不能在數據上執行查詢，或者對內容進行迭代來提取信息。應該使用它來存儲數據塊或對象以備批量使用。
不要緩存資料庫行或文件
雖然可以使用 memcached
存儲載入自資料庫的數據行，但這實際上是查詢緩存，並且大多數資料庫都提供各自的查詢緩存的機制。其他的對象，比如文件系統的圖像或文件的情況與此相同。很多應用程序和
web 伺服器針對此類工作已經有了一些很好的解決方案。
如果在載入和格式化後，使用它來存儲全部信息塊，就可以從 memcached
獲得更多的實用工具和性能上的改善。仍以我們的博客站點為例，存儲信息的最佳點是在將博客類別格式化為對象，甚至是在格式化成 HTML 後。博客頁面的構造可通過從
memcached 載入各個組件(比如 blog post、category list、post history 等)並將完成的 HTML
寫回至客戶機實現。
memcached並不安全
為了確保最佳性能，memcached 並未提供任何形式的安全性，沒有身份驗證，也沒有加密。這意味著對 memcached
伺服器的訪問應該這么處理：一是通過將它們放到應用程序部署環境相同的私有側，二是如果安全性是必須的，那麼就使用 UNIX® socket
並只允許當前主機上的應用程序訪問此 memcached 伺服器。
這多少犧牲了一些靈活性和彈性，以及跨網路上的多台機器共享 RAM 緩存的能力，但這是在目前的情況下確保 memcached
數據安全性的惟一一種解決方案。
十、不要限制自己
除了不應該使用 memcached 實例的情況外，memcached 的靈活性不應忽視。由於 memcached
與應用程序處於相同的架構水平，所以很容易集成並連接到它。並且更改應用程序以便利用 memcached 也並不復雜。此外，由於 memcached
只是一個緩存，所以在出現問題時它不會停止應用程序的執行。如果使用正確的話，它所做的是減輕其餘伺服器基礎設施的負載(減少對資料庫和數據源的讀操
作)，這意味著無需更多的硬體就可以支持更多的客戶機。
但請記住，它僅僅是個緩存!
結束語
在本文中，我們了解了 memcached 以及如何最佳地使用它。我們看到了信息如何存儲、如何選擇合理的鍵以及如何選擇要存儲的信息。我們還討論了所有
memcached 用戶都要遇到的一些關鍵的部署問題，包括多伺服器的使用、當 memcached 實例消亡時該怎麼做，以及(也許最為重要的)在哪些情況下不能使用
memcached。
作為一種開源的應用程序並且是目的簡單而直白的應用程序，memcached 的功能和實用性均來自於這種簡單性。通過為信息提供巨大的 RAM
存儲空間、讓它在網路上可用，然後再讓它可通過各種不同的介面和語言訪問到，memcached 可被集成到多種多樣的安裝和環境中。