可以看到，string 型別的底層實現只有一種資料結構，也就是簡單動態字串。而 list、hash、set 和 sorted set 這四種資料型別，都有兩種底層實現結構。通常情況下，我們會把這四種型別稱為集合型別，它們的特點是乙個鍵對應了乙個集合的資料。redis 3.2後引入了quicklist結構
redis 使用了乙個雜湊表來儲存所有鍵值對。
乙個雜湊表，其實就是乙個陣列，陣列的每個元素稱為乙個雜湊桶。所以，我們常說，乙個雜湊表是由多個雜湊桶組成的，每個雜湊桶中儲存了鍵值對資料。
雜湊桶中的元素儲存的並不是值本身，而是指向具體值的指標。
潛在的風險點:
雜湊表的衝突問題
rehash 可能帶來的操作阻塞
當雜湊衝突變多後，將雜湊遍歷退化成煉表遍歷，導致查詢變慢，這時需要rehash來重建雜湊表。
redis 會對雜湊表做 rehash 操作, 為了使 rehash 操作更高效，redis 預設使用了兩個全域性雜湊表:
雜湊表 1
雜湊表 2
一開始，當你剛插入資料時，預設使用雜湊表 1，此時的雜湊表 2 並沒有被分配空間。隨著資料逐步增多，redis 開始執行 rehash，這個過程分為三步：
給雜湊表 2 分配更大的空間，例如是當前雜湊表 1 大小的兩倍；
把雜湊表 1 中的資料重新對映並拷貝到雜湊表 2 中，redis 採用了漸進式 rehash。釋放雜湊表 1 的空間。
簡單來說就是在第二步拷貝資料時，redis 仍然正常處理客戶端請求，每處理乙個請求時，從雜湊表 1 中的第乙個索引位置開始，順帶著將這個索引位置上的所有 entries 拷貝到雜湊表 2 中；等處理下乙個請求時，再順帶拷貝雜湊表 1 中的下乙個索引位置的 entries。如下圖所示：
對於 string 型別來說，找到雜湊桶就能直接增刪改查了，所以，雜湊表的 o(1) 操作複雜度也就是它的複雜度了。
對於集合型別來說，即使找到雜湊桶了，還要在集合中再進一步操作。
集合型別的底層資料結構主要有 5 種：
整數陣列
雙向鍊錶
雜湊表壓縮列表
跳表壓縮列表實際上類似於乙個陣列，陣列中的每乙個元素都對應儲存乙個資料。和陣列不同的是，壓縮列表在表頭有三個字段 zlbytes、zltail 和 zllen，分別表示列表長度、列表尾的偏移量和列表中的 entry 個數；壓縮列表在表尾還有乙個 zlend，表示列表結束。
查詢第乙個或最後乙個元素可以根據屬性, o(1)
其它位置, o(n)
跳表在鍊錶的基礎上，增加了多級索引，通過索引位置的幾個跳轉，實現資料的快速定位，如下圖所示
集合常見操作的複雜度:
單元素操作是基礎；o(1)
範圍操作非常耗時；o(n)
統計操作通常高效；o(1), 比如計算集合的長度, 因為內部記錄統計資訊, 可以直接獲取
例外情況只有幾個；o(1), 比如操作雙向鍊錶的頭/尾
redis 之所以能快速操作鍵值對，一方面是因為 o(1) 複雜度的雜湊表被廣泛使用，包括 string、hash 和 set，它們的操作複雜度基本由雜湊表決定，另一方面，sorted set 也採用了 o(logn) 複雜度的跳表。不過，集合型別的範圍操作，因為要遍歷底層資料結構，複雜度通常是 o(n)。這裡，我的建議是：用其他命令來替代，例如可以用 scan 來代替，避免在 redis 內部產生費時的全集合遍歷操作。
網頁載入慢，有哪些原因？
1.頻寬不足，首先想到的就是自己網速的問題，但是一般網速在1m以上的，開啟網頁一般不會是很慢的。伺服器的頻寬不夠的話，當大量使用者訪問的時候，網頁的載入也是很慢的，這就是網路的出口端和入口端兩個方面 2.硬體配置低，本機的配置也會是一方面的，但是只要不是老賽揚單核 512m的配置，一般不會是電腦配置...
Redis有哪些資料型別
1.redis有哪些資料型別？s tring hash set，zset list 2.redis和memcache的區別是什麼？從儲存大小 memcached單個key value大小有限，乙個value最大只支援1mb key 最大250個字元 而redis最大支援512mb 從可靠性 memc...
Redis有哪些適合的場景？
會話快取 session cache 用redis快取會話比其他儲存 如memcached 的優勢在於 redis提供持久化。當維護乙個不是嚴格要求一致性的快取時，如果使用者的購物車資訊全部丟失，大部分人都會不高興。全頁快取 fpc 除基本的會話token之外，redis還提供很簡便的fpc平台。佇...