基於Hash散列的數據緩存

Ⅰ 常用的緩存技術

第一章 常用的緩存技術
1、常見的兩種緩存

本地緩存：不需要序列化，速度快，緩存的數量與大小受限於本機內存
分布式緩存：需要序列化，速度相較於本地緩存較慢，但是理論上緩存的數量與大小無限（因為緩存機器可以不斷擴展）
2、本地緩存

Google guava cache：當下最好用的本地緩存
Ehcache：spring默認集成的一個緩存，以spring cache的底層緩存實現類形式去操作緩存的話，非常方便，但是欠缺靈活，如果想要靈活使用，還是要單獨使用Ehcache
Oscache：最經典簡單的頁面緩存
3、分布式緩存

memcached：分布式緩存的標配
Redis：新一代的分布式緩存，有替代memcached的趨勢
3.1、memcached

經典的一致性hash演算法
基於slab的內存模型有效防止內存碎片的產生（但同時也需要估計好啟動參數，否則會浪費很多的內存）
集群中機器之間互不通信（相較於Jboss cache等集群中機器之間的相互通信的緩存，速度更快<--因為少了同步更新緩存的開銷，且更適合於大型分布式系統中使用）
使用方便（這一點是相較於Redis在構建客戶端的時候而言的，盡管redis的使用也不困難）
很專一（專做緩存，這一點也是相較於Redis而言的）
3.2、Redis

可以存儲復雜的數據結構（5種）
strings-->即簡單的key-value，就是memcached可以存儲的唯一的一種形式，接下來的四種是memcached不能直接存儲的四種格式（當然理論上可以先將下面的一些數據結構中的東西封裝成對象，然後存入memcached，但是不推薦將大對象存入memcached，因為memcached的單一value的最大存儲為1M，可能即使採用了壓縮演算法也不夠，即使夠，可能存取的效率也不高，而redis的value最大為1G）
hashs-->看做hashTable
lists-->看做LinkedList
sets-->看做hashSet，事實上底層是一個hashTable
sorted sets-->底層是一個skipList
有兩種方式可以對緩存數據進行持久化
RDB
AOF
事件調度
發布訂閱等
4、集成緩存

專指spring cache，spring cache自己繼承了ehcache作為了緩存的實現類，我們也可以使用guava cache、memcached、redis自己來實現spring cache的底層。當然，spring cache可以根據實現類來將緩存存在本地還是存在遠程機器上。

5、頁面緩存

在使用jsp的時候，我們會將一些復雜的頁面使用Oscache進行頁面緩存，使用非常簡單，就是幾個標簽的事兒；但是，現在一般的企業，前台都會使用velocity、freemaker這兩種模板引擎，本身速度就已經很快了，頁面緩存使用的也就很少了。

總結：

在實際生產中，我們通常會使用guava cache做本地緩存+redis做分布式緩存+spring cache就集成緩存（底層使用redis來實現）的形式
guava cache使用在更快的獲取緩存數據，同時緩存的數據量並不大的情況
spring cache集成緩存是為了簡單便捷的去使用緩存（以註解的方式即可），使用redis做其實現類是為了可以存更多的數據在機器上
redis緩存單獨使用是為了彌補spring cache集成緩存的不靈活
就我個人而言，如果需要使用分布式緩存，那麼首先redis是必選的，因為在實際開發中，我們會緩存各種各樣的數據類型，在使用了redis的同時，memcached就完全可以舍棄了，但是現在還有很多公司在同時使用memcached和redis兩種緩存。

Ⅱ 哈希（hash） - 哈希演算法的應用

通過之前的學習，我們已經了解了哈希函數在散列表中的應用，哈希函數就是哈希演算法的一個應用。那麼在這里給出哈希的定義： 將任意長度的二進制值串映射為固定長度的二進制值串，這個映射規則就是哈希演算法，得到的二進制值串就是哈希值 。
要設計一個好的哈希演算法並不容易，它應該滿足以下幾點要求：

哈希演算法的應用非常廣泛，在這里就介紹七點應用：

有很多著名的哈希加密演算法：MD5、SHA、DES...它們都是通過哈希進行加密的演算法。
對於加密的哈希演算法來說，有兩點十分重要：一是很難根據哈希值反推導出原始數據；二是散列沖突的概率要很小。
當然，哈希演算法不可能排除散列沖突的可能，這用數學中的 鴿巢原理 就可以很好解釋。以MD5演算法來說，得到的哈希值為一個 128 位的二進制數，它的數據容量最多為 2 ¹²⁸ bit，如果超過這個數據量，必然會出現散列沖突。
在加密解密領域沒有絕對安全的演算法，衫基一般來說，只要解密的計算量極其龐大，我們就可以認為這種加密方法是較為安全的。

假設我們有100萬個圖片，如果我們在圖片中尋找某一個圖片是非常耗時的，這是我們就可以使用哈希演算法的原理為圖片設置唯一標識。比如，我們可以從圖片的二進制碼串開頭取100個位元組，從中間取100個位元組，從結尾取100個位元組，然後將它們合並，並使用哈希演算法計算得到一個哈希值，將其作為圖片的唯一標識。
使用這個唯一標識判斷圖片是否在圖庫中，這可以減少甚多工作量。

在傳輸消息的過程中，我們擔心通信數據被人篡改，這時就可以使用哈希函數進行數據校驗。比如BT協議中就使用哈希栓發進行數據校驗。

在散列表那一篇中我們就講過散列函數的應用，相比於其它應用，散列函數對於散列演算法沖突的要求低很多（我們可以通過開放定址法或鏈表法解決沖突），同時散列函數對於散列演算法是否能逆向解密也並不關心。
散列函數比較在意函數的執行效率，至於其它要求，在之前的我們已經講過，就不再贅述了。

接下來的三個應用主要是在分布式系統中的應用

復雜均衡的演算法很多，如何實現一個會話粘滯的負載均衡演算法呢？也就是說，我們需要在同一個客戶端上，在一次會話中的所有請求都路由到同一個伺服器上。

最簡單的辦法是我們根據客戶端的 IP 地址或會話 ID 創建一個映射關系。但是這樣很浪費內存，客戶端上線下線，伺服器擴容等都會導致映射失效，維護成本很大。

藉助哈希演算法，我們可以很輕松的解決這些問題：對客戶端的 IP 地址或會話 ID 計算哈希值，將取得的哈希值域伺服器的列表的大小進行取模運算，最後得到的值就是被路由到的伺服器的編號。

假設有一個非常大的日誌文件，裡面記錄了用戶的搜索關鍵詞，我們想要快速統計出每個關鍵詞被搜索的次數，該怎麼做呢？

分析一下，這個問題有兩個難點：一是搜索日誌很大，沒辦法放到一台機器的內存中；二是如果用一台機器處理這么大的數據，處理時間會很長。

針對這兩個難點，我們可以先對數據進行分片，然後使用多台機器處理，提高處理速度。具體思路：使用 n 台機器並行處理，從日誌文件中讀出每個搜索關鍵詞，通過哈希局銷函數計算哈希值，然後用 n 取模，最終得到的值就是被分配的機器編號。
這樣，相同的關鍵詞被分配到了相同的機器上，不同機器只要記錄屬於自己那部分的關鍵詞的出現次數，最終合並不同機器上的結果即可。

針對這種海量數據的處理問題，我們都可以採用多機分布式處理。藉助這種分片思路，可以突破單機內存桐塌游、CPU等資源的限制。

處理思路和上面出現的思路類似：對數據進行哈希運算，對機器數取模，最終將存儲數據（可能是硬碟存儲，或者是緩存分配）分配到不同的機器上。

你可以看一下上圖，你會發現之前存儲的數據在新的存儲規則下全部失效，這種情況是災難性的。面對這種情況，我們就需要使用一致性哈希演算法。

哈希演算法是應用非常廣泛的演算法，你可以回顧上面的七個應用感受一下。

其實在這里我想說的是一個思想： 用優勢彌補不足 。
例如，在計算機中，數據的計算主要依賴 CPU ，數據的存儲交換主要依賴內存。兩者一起配合才能實現各種功能，而兩者在性能上依然無法匹配，這種差距主要是： CPU運算性能對內存的要求遠高於現在的內存能提供的性能。
也就是說，CPU運算很快，內存相對較慢，為了抹平這種差距，工程師們想了很多方法。在我看來，散列表的使用就是利用電腦的高計算性能（優勢）去彌補內存速度（不足）的不足，你仔細思考散列表的執行過程，就會明白我的意思。

以上就是哈希的全部內容

Ⅲ 怎麼實現redis的資料庫的緩存(redis實現緩存的流程)

大致為兩種措施：

一、腳本同步：

1、自己寫腳本將資料庫數據寫入到redis/memcached。

2、這就涉及到實時數據變更的問題（mysqlrowbinlog的實時分析），binlog增量訂閱Alibaba的canal，以及緩存層數據丟失/失效後的數據同步恢復問題。

二、純賀業務層實現：

1、先讀取nosql緩存層，沒有數據再讀取mysql層，並寫入數據到nosql。

2、nosql層做好多節點分布式（一致性hash），以及節點失效後替代方案（多層hash尋找相鄰替代節點），和數據震盪恢復了。

redis實現資料庫緩存的分析：

對於變化頻率非常快的數據來說，如果還選擇傳統的靜態緩存方式（Memocached、FileSystem等）展示數據，可能在緩存的存取上會有很大的開銷則褲差，並不能很好的滿足需要，而Redis這樣基於內存的NoSQL資料庫，就非常適合擔任實時數據的容器。

但是往往又有數據可靠性的需求，採用MySQL作為數據存儲，不會因為內存問題而引起數據丟失，同時也可以利用關系資料庫的特性實現很多功能。所以就會很自然的想到是否可以採用MySQL作為數據存孫皮儲引擎，Redis則作為Cache。

MySQL到Redis數據復制方案，無論MySQL還是Redis，自身都帶有數據同步的機制，比較常用的MySQL的Master/Slave模式，就是由Slave端分析Master的binlog來實現的，這樣的數據復制其實還是一個非同步過程，只不過當伺服器都在同一內網時，非同步的延遲幾乎可以忽略。那麼理論上也可用同樣方式，分析MySQL的binlog文件並將數據插入Redis。

因此這里選擇了一種開發成本更加低廉的方式，借用已經比較成熟的MySQLUDF，將MySQL數據首先放入Gearman中，然後通過一個自己編寫的PHPGearmanWorker，將數據同步到Redis。比分析binlog的方式增加了不少流程，但是實現成本更低，更容易操作。