redis資料結構

標籤：sort   hashmap   最新   執行緒模式   命中率   init   sub   blog   技術分享   

1 MySQL+Memcached架構的問題

　　Memcached採用用戶端-伺服器的架構，用戶端和伺服器端的通訊使用自訂的協議標準，只要滿足協議格式要求，用戶端Library可以用任何語言實現.

　　Memcached伺服器使用基於Slab的記憶體管理方式，有利於減少記憶體片段和頻繁分配銷毀記憶體所帶來的開銷。各個Slab按需動態分配一個page的記憶體（和4Kpage的概念不同，這裡預設page為1M），page內部按照不同slab class的尺寸再劃分為記憶體chunk供伺服器儲存KV索引值對使用（slab機制相當於記憶體池機制, 實現從作業系統分配一大塊記憶體, 然後 memcached 自己管理這塊記憶體, 負責分配與回收。）

      實際MySQL是適合進行海量資料存放區的，通過Memcached將熱點資料載入到cache，加速訪問，很多公司都曾經使用過這樣的架構，但隨著業務資料量的不斷增加，和訪問量的持續增長，我們遇到了很多問題：

　　1.MySQL需要不斷進行拆庫拆表，Memcached也需不斷跟著擴容，擴容和維護工作佔據大量開發時間。

　　2.Memcached與MySQL資料庫資料一致性問題。

　　3.Memcached資料命中率低或down機，大量訪問直接穿透到DB，MySQL無法支撐。

　　4.跨機房cache同步問題。

　　而且memcache不適合儲存大資料，單個item最大為1M，如果資料超過1M,存取set和get是都是返回false，而且引起效能的問題。item對象的到期時間最長可以達到30天。memcached把傳入的到期時間（時間段）解釋成時間點後，一旦到了這個時間點，memcached就把item置為失效狀態，這是一個簡單但obscure的機制。

memcached是原子的嗎？

所有的被發送到memcached的單個命令是完全原子的。如果您針對同一份資料同時發送了一個set命令和一個get命令，它們不會影響對方。它們將被序列化、先後執行。即使在多線程模式，所有的命令都是原子的。然是，命令序列不是原子的。如果首先通過get命令擷取了一個item，修改了它，然後再把它set回memcached，系統不保證這個item沒有被其他進程（process，未必是作業系統中的進程）操作過。memcached 1.2.5以及更高版本，提供了gets和cas命令，它們可以解決上面的問題。如果使用gets命令查詢某個key的item，memcached會返回該item當前值的唯一標識。如果用戶端程式覆寫了這個item並想把它寫回到memcached中，可以通過cas命令把那個唯一標識一起發送給memcached。如果該item存放在memcached中的唯一標識與您提供的一致，寫操作將會成功。如果另一個進程在這期間也修改了這個item，那麼該item存放在memcached中的唯一標識將會改變，寫操作就會

失敗。

2關於NOSQL:

眾多NoSQL百花齊放，如何選擇

　　最近幾年，業界不斷湧現出很多各種各樣的NoSQL產品，那麼如何才能正確地使用好這些產品，最大化地發揮其長處，是我們需要深入研究和思考的問題，實際歸根結底最重要的是瞭解這些產品的定位，並且瞭解到每款產品的tradeoffs，在實際應用中做到揚長避短，總體上這些NoSQL主要用於解決以下幾種問題

　　1.少量資料存放區，高速讀寫訪問。此類產品通過資料全部in-momery 的方式來保證高速訪問，同時提供資料落地的功能，實際這正是Redis最主要的適用情境。

　　2.海量資料存放區，分布式系統支援，資料一致性保證，方便的叢集節點添加/刪除。

　　3.Schema free，auto-sharding等。比如目前常見的一些文檔資料庫都是支援schema-free的，直接儲存json格式資料，並且支援auto-sharding等功能，比如MongoDB。

　　面對這些不同類型的NoSQL產品,我們需要根據我們的業務情境選擇最合適的產品。

       Redis最適合所有資料in-momory的情境，雖然Redis也提供持久化功能，但實際更多的是一個disk-backed的功能，跟傳統意義上的持久化有比較大的差別，那麼可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那麼何時使用Memcached,何時使用Redis呢?

memcache和redis的比較：

• 效能方面：沒有必要過多的關心效能，因為二者的效能都已經足夠高了。由於Redis只使用單核，而Memcached可以使用多核，所以在比較上，平均每一個核上Redis在儲存小資料時比Memcached效能更高。而在100k以上的資料中，Memcached效能要高於Redis，雖然Redis最近也在儲存大資料的效能上進行最佳化，但是比起Memcached，還是稍有遜色。說了這麼多，結論是，無論你使用哪一個，每秒處理請求的次數都不會成為瓶頸。（比如瓶頸可能會在網卡）
• 記憶體使用量效率：使用簡單的key-value儲存的話，Memcached的記憶體利用率更高，而如果Redis採用hash結構來做key-value儲存，由於其組合式的壓縮，其記憶體利用率會高於Memcached。當然，這和你的應用情境和資料特性有關。

• 資料持久化：如果你對資料持久化和資料同步有所要求，那麼推薦你選擇Redis，因為這兩個特性Memcached都不具備。即使你只是希望在升級或者重啟系統後快取資料不會丟失，選擇Redis也是明智的。

• 資料結構:當然，最後還得說到你的具體應用需求。Redis相比Memcached來說，擁有更多的資料結構和並支援更豐富的資料操作，通常在Memcached裡，你需要將資料拿到用戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和資料體積。在Redis中，這些複雜的操作通常和一般的GET/SET一樣高效。所以，如果你需要緩衝能夠支援更複雜的結構和操作，那麼Redis會是不錯的選擇。

• 網路IO模型方面：Memcached是多線程，分為監聽線程、worker線程，引入鎖，帶來了效能損耗。Redis使用單線程的IO複用模型，將速度優勢發揮到最大，也提供了較簡單的計算功能 

• 記憶體管理方面：Memcached使用預分配的記憶體池的方式，帶來一定程度的空間浪費 並且在記憶體仍然有很大空間時，新的資料也可能會被剔除，而Redis使用現場申請記憶體的方式來儲存資料，不會剔除任何非臨時資料 Redis更適合作為儲存而不是cache 

• 資料的一致性方面：Memcached提供了cas命令來保證.而Redis提供了事務的功能，可以保證一串 命令的原子性，中間不會被任何操作打斷 

•   如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：

       1 、Redis不僅僅支援簡單的k/v類型的資料，同時還提供list，set，zset，hash等資料結構的儲存。

       2 、Redis支援資料的備份，即master-slave模式的資料備份。

       3 、Redis支援資料的持久化，可以將記憶體中的資料保持在磁碟中，重啟的時候可以再次載入進行使用。

       4、Redis可以實現主從複製，實現故障恢複。

       5、Redis的Sharding技術： 很容易將資料分布到多個Redis執行個體

3.Redis常用資料類型

     String

     Hash

     List

     Set

     Sorted set

     pub/sub

     Transactions

     1.Strings 資料結構是簡單的key-value類型，value其實不僅是String，也可以是數字.

• 常用命令:  set,get,decr,incr,mget 等。 

• 應用情境：String是最常用的一種資料類型，普通的key/ value 儲存都可以歸為此類.即可以完全實現目前 Memcached 的功能，並且效率更高。還可以享受Redis的定時持久化，動作記錄及 Replication等功能。除了提供與 Memcached 一樣的get、set、incr、decr 等操作外，Redis還提供了下面一些操作

  • 擷取字串長度
  • 往字串append內容
  • 設定和擷取字串的某一段內容
  • 設定及擷取字串的某一位（bit）
  • 大量設定一系列字串的內容.
  • 實現方式：String在redis內部儲存預設就是一個字串，被redisObject所引用，當遇到incr,decr等操作時會轉成數值型進行計算，此時
  • redisObject的encoding欄位為int
  • 2.hash

  常用命令：hget,hset,hgetall 等。

  應用情境：在Memcached中，我們經常將一些結構化的資訊打包成HashMap，在用戶端序列化後儲存為一個字串的值，比如使用者的暱稱、年齡、性別、積分等，這時候在需要修改其中某一項時，通常需要將所有值取出還原序列化後，修改某一項的值，再序列化儲存回去。這樣不僅增大了開銷，也不適用於一些可能並行作業的場合（比如兩個並發的操作都需要修改積分）。而Redis的Hash結構可以使你像在資料庫中Update一個屬性一樣只修改某一項屬性值。

          我們簡單舉個執行個體來描述下Hash的應用情境，比如我們要儲存一個使用者資訊對象資料，包含以下資訊：

  使用者ID為尋找的key，儲存的value使用者物件包含姓名，年齡，生日等資訊，如果用普通的key/value結構來儲存，主要有以下2種儲存方式：

• 第一種方式將使用者ID作為尋找key,把其他資訊封裝成一個對象以序列化的方式儲存，這種方式的缺點是，增加了序列化/還原序列化的開銷，並且在需要修改其中一項資訊時，需要把整個對象取回，並且修改操作需要對並發進行保護，引入CAS等複雜問題。

• 也就是說，Key仍然是使用者ID, value是一個Map，這個Map的key是成員的屬性名稱，value是屬性值，這樣對資料的修改和存取都可以直接通過其內部Map的Key(Redis裡稱內部Map的key為field), 也就是通過 key(使用者ID) + field(屬性標籤) 就可以操作對應屬性資料了，既不需要重複儲存資料，也不會帶來序列化和並發修改控制的問題。很好的解決了問題。

  這裡同時需要注意，Redis提供了介面(hgetall)可以直接取到全部的屬性資料,但是如果內部Map的成員很多，那麼涉及到遍曆整個內部Map的操作，由於Redis單執行緒模式的緣故，這個遍曆操作可能會比較耗時，而另其它用戶端的請求完全不響應，這點需要格外注意。

  實現方式：

  上面已經說到Redis Hash對應Value內部實際就是一個HashMap，實際這裡會有2種不同實現，這個Hash的成員比較少時Redis為了節省記憶體會採用類似一維數組的方式來緊湊儲存，而不會採用真正的HashMap結構，對應的value redisObject的encoding為zipmap,當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht.

• 3List
• 常用命令：lpush,rpush,lpop,rpop,lrange等
• 應用情境：Redis list的應用情境非常多，也是Redis最重要的資料結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現。
• Lists 就是鏈表，相信略有資料結構知識的人都應該能理解其結構。使用Lists結構，我們可以輕鬆地實現最新訊息排行等功能。Lists的另一個應用就是訊息佇列，可以利用Lists的PUSH操作，將任務存在Lists中，然後背景工作執行緒再用POP操作將任務取出進行執行。Redis還提供了操作Lists中某一段的api，你可以直接查詢，刪除Lists中某一段的元素。實現方式：Redis list的實現為一個雙向鏈表，即可以支援反向尋找和遍曆，更方便操作，不過帶來了部分額外的記憶體開銷，Redis內部的很多實現，包括髮送緩衝隊列等也都是用的這個資料結構。
• 4 Set
• 常用命令：sadd,spop,smembers,sunion 等。

• 應用情境：

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

  Sets 集合的概念就是一堆不重複值的組合。利用Redis提供的Sets資料結構，可以儲存一些集合性的資料，比如在微博應用中，可以將一個使用者所有的關注人存在一個集合中，將其所有粉絲存在一個集合。Redis還為集合提供了求交集、並集、差集等操作，可以非常方便的實現如共同關注、共同喜好、二度好友等功能，對上面的所有集合操作，你還可以使用不同的命令選擇將結果返回給用戶端還是存集到一個新的集合中。

  實現方式：

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

  • Sorted Set

  常用命令：

  zadd,zrange,zrem,zcard等

  使用情境：

  Redis sorted set的使用情境與set類似，區別是set不是自動有序的，而sorted set可以通過使用者額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重複的集合列表，那麼可以選擇sorted set資料結構，比如twitter 的public timeline可以以發表時間作為score來儲存，這樣擷取時就是自動按時間排好序的。

  另外還可以用Sorted Sets來做帶權重的隊列，比如普通訊息的score為1，重要訊息的score為2，然後背景工作執行緒可以選擇按score的倒序來擷取工作任務。讓重要的任務優先執行。

  實現方式：

  Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證資料的儲存和有序，HashMap裡放的是成員到score的映射，而跳躍表裡存放的是所有的成員，排序依據是HashMap裡存的score,使用跳躍表的結構可以獲得比較高的尋找效率，並且在實現上比較簡單

redis資料結構