memcache哈希演算法

⑴ 哈希演算法是什麼呢

哈希演算法就是一種特殊的函數，不論輸入多長的一串字元，只要通過這個函數都可以得到一個固定長度的輸出值，這就好像身份證號碼一樣，永遠都是十八位而且全國唯一。哈希演算法的輸出值就叫做哈希值。

原理：

哈希演算法有三個特點，它們賦予了區塊鏈不可篡改、匿名等特性，並保證了整個區塊鏈體系的完整。

第一個特點是具有單向性。比如輸入一串數據，通過哈希演算法可以獲得一個哈希值，但是通過這個哈希值是沒有辦法反推回來得到輸入的那串數據的。這就是單向性，也正是基於這一點，區塊鏈才有效保護了我們信息的安全性。

哈希演算法的第二個特點是抗篡改能力，對於任意一個輸入，哪怕是很小的改動，其哈希值的變化也會非常大。

它的這個特性，在區塊與區塊的連接中就起到了關鍵性的作用。區塊鏈的每個區塊都會以上一個區塊的哈希值作為標示，除非有人能夠破解整條鏈上的所有哈希值，否則數據一旦記錄在鏈上，就不可能進行篡改。

哈希演算法的第三個特點就是抗碰撞能力。所謂碰撞，就是輸入兩個不同的數據，最後得到了一個相同的輸入。

就跟我們逛街時撞衫一樣，而坑碰撞就是大部分的輸入都能得到一個獨一無二的輸出。在區塊鏈的世界中，任何一筆交易或者賬戶的地址都是完全依託於哈希演算法生產的。這也就保證了交易或者賬戶地址在區塊鏈網路中的唯一性。

無論這筆轉賬轉了多少錢，轉給了多少個人，在區塊鏈這個大賬本中都是唯一的存在。它就像人體體內的白細胞，不僅區塊鏈的每個部分都離不開它，而且它還賦予了區塊鏈種種特點，保護著整個區塊鏈體系的安全。

⑵ php memacne緩存可靠嗎

你說的memcache吧 是的話下面實在網上隨便找的,總結的到位了 反正就那幾個
優點
一.部分容災
假設只用一台memcache，如果這台memcache伺服器掛掉了，那麼請求將不斷的沖擊資料庫，這樣有可能搞死資料庫，從而引發」雪崩「。如果使用多台memcache伺服器，由於memcache使用一致性哈希演算法，萬一其中一台掛掉了，部分請求還是可以在memcache中命中，為修復系統贏得一些時間。
二.容量問題
一台memcache伺服器的容量畢竟有限，可以使用多台memcache伺服器，增加緩存容量。
三.均衡請求
使用多台memcache伺服器，可以均衡請求，避免所有請求都沖進一台memcache伺服器，導致伺服器掛掉。
四.利用memcache分布式特性
使用一台memcache伺服器，並沒有利用memcache的數據分布式特性。
缺點
1.不能持久化存儲
2.存儲數據有限制：1M 【大於1M，認為就行分割】（內存碎片）
3.mm存儲數據只能key-value
4.集群數據沒有復制和同步機制 【崩潰不會影響程序，會從資料庫中取數據】
5.內存回收不能及時 LRU(演算法)：未使用內存》過期內存》最近最少使用內存 這是惰性刪除

⑶ memcache 怎麼設置一致性哈希

memcache 是一個分布式的緩存系統，但是本身沒有提供集群功能，在大型應用的情況下容易成為瓶頸。但是客戶端這個時候可以自由擴展，分兩階段實現。第一階段：key 要先根據一定的演算法映射到一台memcache伺服器。第二階段從伺服器中取出緩存的值。但是有一個問題，比如其中一台伺服器掛了，或者需要增加一台服務 的時候，這個時候第一階段的演算法就很重要了，怎樣使得原來的數據盡可能的繼續有效，減少擴展節點或縮減節點帶來的沖擊。考慮通常的 hash 演算法都是將 value 映射到一個 32 為的 key 值，也即是 0~2^32-1 次方的數值空間；我們可以將這個空間想像成一個首（ 0）尾（ 2^32-1 ）相接的圓環

⑷ 哈希的演算法是什麼

哈希演算法是一個廣義的演算法，也可以認為是一種思想，使用Hash演算法可以提高存儲空間的利用率，可以提高數據的查詢效率，也可以做數字簽名來保障數據傳遞的安全性。所以Hash演算法被廣泛地應用在互聯網應用中。

哈希演算法也被稱為散列演算法，Hash演算法雖然被稱為演算法，但實際上它更像是一種思想。Hash演算法沒有一個固定的公式，只要符合散列思想的演算法都可以被稱為是Hash演算法。

特點：

加密哈希跟普通哈希的區別就是安全性，一般原則是只要一種哈希演算法出現過碰撞，就會不被推薦成為加密哈希了，只有安全度高的哈希演算法才能用作加密哈希。

同時加密哈希其實也能當普通哈希來用，Git 版本控制工具就是用 SHA-1 這個加密哈希演算法來做完整性校驗的。一般來講越安全的哈希演算法，處理速度也就越慢，所以並不是所有的場合都適合用加密哈希來替代普通哈希。

⑸ redis使用什麼演算法來解決hash沖突

因為Memcached的哈希策略是在其客戶端實現的，因此不同的客戶端實現也有區別，以Spymemcache、Xmemcache為例，都是使用了KETAMA作為其實現。
因此，我們也可以使用一致性hash演算法來解決Redis分布式這個問題。在介紹一致性hash演算法之前，先介紹一下我之前想的一個方法，怎麼把Key均勻的映射到多台Redis Server上。

⑹ Memcache 連接超時 什麼原因

Memcached存儲單個item最大數據是在1MB內，如果數據超過1M,存取set和get是都是返回false，而且引起性能的問題。

我們之前對排行榜的數據進行緩存，由於排行榜在我們所有sql select查詢裡面佔了30%，而且我們排行榜每小時更新一次，所以必須對數據做緩存。為了清除緩存方便，把所有的用戶的數據放在同一key中，由於memcached:set的時候沒有壓縮數據。在測試服測試的時候，沒發現問題，當上線的時候，結果發現，在線人數剛剛490人的時候，伺服器load average飄到7.9。然後我們去掉緩存，一下子就下降到0.59。

所以Memcahce不適合緩存大數據，超過1MB的數據，可以考慮在客戶端壓縮或拆分到多個key中。大的數據在進行load和uppack到內存的時候需要花很長時間，從而降低伺服器的性能。

Memcached支持最大的存儲對象為1M。這個值由其內存分配機制決定的。

memcached默認情況下採用了名為Slab Allocator的機制分配、管理內存。在該機制出現以前，內存的分配是通過對所有記錄簡單地進行malloc和free來進行的。但是，這種方式會導致內存碎片，加重操作系統內存管理器的負擔，最壞的情況下，會導致操作系統比memcached進程本身還慢。Slab Allocator就是為解決該問題而誕生的。Slab Allocator的基本原理是按照預先規定的大小，將分配的內存分割成特定長度的塊，以完全解決內存碎片問題.

今天（2012-03-16）我們重新測試了memcached ::set的數據大小。可能是我們用php的memcached擴展是最新版，set數據的時候是默認壓縮的。set 數據：

$ac = new memcahed();
$data = str_repeat('a', 1024* 1024); //1M的數據
$r = $ac->set('key', $data, 9999);
//或者
$data = str_repeat('a', 1024* 1024*100);//100M的數據
$r = $ac->set('key', $data, 9999);
不論是1M的數據還是100M的數據，都能set成功。後來我發現，memcachedset數據的時候是默認壓縮的。由於這個這個是重復的字元串，壓縮率高達1000倍。因此100M的數據壓縮後實際也就100k而已。

當我設置：

$ac->setOption(memcahed::OPT_COMPRESSION,0); //不壓縮存儲數據。
$data = str_repeat('a', 1024* 1024); //1M數據
$r = $ac->set('key', $data, 9999);//1M的數據set不成功。
也就是說memcached server不能存儲超過1M的數據，但是經過客戶端壓縮數據後，只要小於1M的數據都能存儲成功。

memcached相關知識：

1、memcached的基本設置
1）啟動Memcache的伺服器端
# /usr/local/bin/memcached -d -m 10 -u root -l 192.168.0.200 -p 12000 -c 256 -P /tmp/memcached.pid

-d選項是啟動一個守護進程，
-m是分配給Memcache使用的內存數量，單位是MB，我這里是10MB，
-u是運行Memcache的用戶，我這里是root，
-l是監聽的伺服器IP地址，如果有多個地址的話，我這里指定了伺服器的IP地址192.168.0.200，
-p是設置Memcache監聽的埠，我這里設置了12000，最好是1024以上的埠，
-c選項是最大運行的並發連接數，默認是1024，我這里設置了256，按照你伺服器的負載量來設定，
-P是設置保存Memcache的pid文件，我這里是保存在 /tmp/memcached.pid，

2）如果要結束Memcache進程，執行：

# kill `cat /tmp/memcached.pid`

哈希演算法將任意長度的二進制值映射為固定長度的較小二進制值，這個小的二進制值稱為哈希值。哈希值是一段數據唯一且極其緊湊的數值表示形式。如果散列一段明文而且哪怕只更改該

段落的一個字母，隨後的哈希都將產生不同的值。要找到散列為同一個值的兩個不同的輸入，在計算上是不可能的。

2、適用memcached的業務場景？

1）如果網站包含了訪問量很大的動態網頁，因而資料庫的負載將會很高。由於大部分資料庫請求都是讀操作，那麼memcached可以顯著地減小資料庫負載。

2）如果資料庫服務

⑺ memcache和mysql的區別

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。

2）Hash

• 常用命令：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。

3）List

• 常用命令：lpush/rpush/lpop/rpop/lrange等；

• 應用場景：Redis list的應用場景非常多，也是Redis最重要的數據結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現；

• 實現方式：Redis list的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，Redis內部的很多實現，包括發送緩沖隊列等也都是用的這個數據結構。

4）Set

• 常用命令：sadd/spop/smembers/sunion等；

• 應用場景：Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重復數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的；

• 實現方式：set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

5）Sorted 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,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。

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的三個設置項，安全強度逐漸變強。

• 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，所以其性能也會受到影響。

對於一般性的業務需求，建議使用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節點。

⑻ 如何優化memcached的get操作

基本問題

1、memcached的基本設置
1）啟動Memcache的伺服器端
# /usr/local/bin/memcached -d -m 10 -u root -l 192.168.0.200 -p 12000 -c 256 -P /tmp/memcached.pid

-d選項是啟動一個守護進程，
-m是分配給Memcache使用的內存數量，單位是MB，我這里是10MB，
-u是運行Memcache的用戶，我這里是root，
-l是監聽的伺服器IP地址，如果有多個地址的話，我這里指定了伺服器的IP地址192.168.0.200，
-p是設置Memcache監聽的埠，我這里設置了12000，最好是1024以上的埠，
-c選項是最大運行的並發連接數，默認是1024，我這里設置了256，按照你伺服器的負載量來設定，
-P是設置保存Memcache的pid文件，我這里是保存在 /tmp/memcached.pid，

2）如果要結束Memcache進程，執行：

# kill `cat /tmp/memcached.pid`

哈希演算法將任意長度的二進制值映射為固定長度的較小二進制值，這個小的二進制值稱為哈希值。哈希值是一段數據唯一且極其緊湊的數值表示形式。如果散列一段明文而且哪怕只更改該

段落的一個字母，隨後的哈希都將產生不同的值。要找到散列為同一個值的兩個不同的輸入，在計算上是不可能的。

2、一致性Hash演算法的目的有兩點：一是節點變動後其他節點受影響盡可能小；二是節點變動後數據重新分配盡可能均衡 。

⑼ 分布式session的幾個問題

高並發下分布式Session需解決的問題：

• 透明處理存儲介質的故障轉移

• 動態增刪節點，減小「緩存顛簸」問題

• 保證數據在各個節點的分布均衡

• Session序列化和反序列化

三.保證「基本可用 Basically Available」的分布式Session方案：

Eric A. Brewer 在 1988 年提出的BASE 策略，即Basically Available、Soft state、和Eventually consistent。

互聯網大多數應用更強調可用性，即犧牲高一致性，獲得可用性或可靠性。

基本可用Basically Available的定義：

在分布式系統部分損壞的時候，允許部分內容不可用，但是其他部分仍舊可用。因此稱這種系統為「基本可用」。比如，一個數據存儲系統由五個節點構成。其中一個發生了損壞，這時只有20%的數據不能訪問，其他80%數據仍然可用。那麼就可以稱這種系統為基本可用的。

基於 memcache 的Hash取模演算法（hash() mod n，hash() 取用戶ID，n為節點數） 實現的分布式 Session 方案，就屬於基本可用：

第一，如果節點發生故障，該節點上的所有用戶 Session 丟失，系統無法自恢復。

第二，如果系統壓力突然增大，需要臨時增加機器節點。按照 Hash取模的演算法，在增加機器節點的這一時刻，大量緩存無法命中（其實還都存在之前的節點上），導致大范圍的緩存穿透，壓力會直接打到資料庫上。

第三，根據 LRU 緩存失效演算法，memcache 里存儲的 key/value 有可能被踢出，用戶 Session 容易丟失。

針對 Hash取模 的改進辦法是：

四.基於一致性哈希演算法的 memcache 解決方案

1）一致性哈希幫我們解決的是，當機器節點減少時，緩存數據能進行最少重建。

2）還能解決 Session 數據的分布均衡問題。

3）當機器節點宕機，這部分數據必然丟失。由於節點數目變化，有可能對部分沒有丟失的數據也要重建。

但上面的方案都解決不了「一個節點失敗後，它所存儲的 Session 如何由其他節點獲取以便接替失效節點，實現集群的容錯（Failover）」。

鄭昀先介紹下面幾個概念：

五.Sticky Session、Non-sticky Session和Replicated Sessions

• Sticky Sessions：粘性會話。即同一個會話中的請求必須被轉發到同一個節點上，除非該節點宕機才轉發到故障轉移節點。一個節點宕機，所存儲的 Sessions 完全丟失。通俗的話就是，將用戶「粘」在某一個伺服器節點上。

• Non-Sticky Sessions：非粘性會話。每一次請求都可能轉發到不同節點。

• Replicated Sessions：把一個節點上的 Sessions 復制到集群的其他節點上，防止數據丟失，允許失效無縫轉移。如node 0復制到node 5，node 1復制到node 6，以此類推。多數應用伺服器（如 Tomcat ）都支持會話復制機制。

當用戶數量和集群數量達到一定規模後，Session 復制就可能成為性能瓶頸。於是人們提出了從第三方緩存恢復失效節點數據的方案，開源產品Memcached-Session-Manager（下面簡稱MSM）就是基於這個思想。

六.MSM的工作原理

MSM 支持 Tomcat 6 和 7，即它主要解決的是 Tomcat 的高可用性。

它的特性為：

• 支持 sticky sessions 和 non-ticky sessions 模式。

• 沒有單點故障。

• 能處理 tomcat 故障轉移

• 能處理 memcache 故障轉移

• pluggable session serialization

• 允許非同步存儲 session，提高響應速度

• sessions 只有真正被修改時，才會發給 memcache