一、
問題一：為什麼要有分布式快取？什麼時候用分布式快取？
鎖機制，有可能會造成死鎖，簡單點就是伺服器卡死，宕機（cpu 100%）！先普及一下資料庫鎖機制：
select * from table1//此時會給這個表加上s鎖（共享鎖）
update table1
set colum="
somedata"//
此時給table1加上x鎖
t1:乙個表上可以有很多個s鎖，但是乙個表上只會有乙個x鎖存在，也就是說，在update的時候這條資料只能被乙個使用者使用，別人是無法查詢或者修改的。begin tran
select * from table (holdlock) (holdlock意思是加共享鎖，直到事物結束才釋放)
update table set column1='hello'
t2:begin tran
select * from table(holdlock)
update table set column1='world'
假設t1和t2同時達到select，t1對table加共享鎖，t2也對加共享鎖，當
t1的select執行完，準備執行update時，根據鎖機制，t1的共享鎖需要公升
級到排他鎖才能執行接下來的update.在公升級排他鎖前，必須等table上的
其它共享鎖釋放，但因為holdlock這樣的共享鎖只有等事務結束後才釋放，
所以因為t2的共享鎖不釋放而導致t1等(等t2釋放共享鎖，自己好公升級成排
他鎖），同理，也因為t1的共享鎖不釋放而導致t2等。死鎖產生了。
隨著訪問量的增大，併發機率就會增高，所謂併發就是同意時間操作同乙個資料。
因為讀取資料庫是通過磁碟讀取的，磁碟的讀取速度和記憶體的讀取速度是沒法比的，此時就可以使用memcache或者redis來解決這個問題。
二、memcache和redis的區別
小僧自己認為主要區別有以下幾點：
1、最主要的就是redis支援資料持久化，mm不支援。
2. mm是多執行緒的，redis是單執行緒運作。
3.redis支援的資料型別比較多(佇列)，而mm只支援key-value.
具體的配置資訊，大家可以去別的部落格拷貝，不用記，用的時候直接複製貼上
三、重點是redis、mm怎麼和當前的資料庫資訊進行同步，實際開發中是怎麼運用的？
額 這個問題需要畫一張圖來解釋一下了
下面詳細講解一下開發過程：
1.客戶端的查詢語句邏輯：先查詢快取中有沒有需要的資料，如果沒有，就查詢資料庫
if2.客戶端的修改操作邏輯：先修改快取中的資料，再將update語句寫入快取redis的佇列中（這樣就能保證使用者修改資料後能夠直接看到修改的資料），後台處理程式就會去抓取佇列中的sql語句執行，這樣就解決的高併發。修改的就不上**了 。（**略，太簡單）(getdata())
else
3.客戶端刪除操作邏輯：先刪除資料庫，再刪除快取（這樣做的優點是：確認資料庫沒有資料了才刪除快取，資料的準確性）。
（**略，太簡單）
同樣分布式快取最集群讀寫分離也是很方便的memcache是通過客戶端配置，而redis是通過伺服器端配置。
這樣整個專案的crud都採用這樣的分布式快取，分布式快取對資料實時性比較高的專案是怎麼適合！
（注：資料庫讀寫分離也可以解決高併發問題，但是超高併發是不行的，向雙十一這種，要用到分布式快取了）
memcache redis原理對比
一 問題 資料庫表資料量極大 千萬條 要求讓伺服器更加快速地響應使用者的需求。二 解決方案 1.通過高速伺服器cache快取資料庫資料 2.記憶體資料庫 這裡僅從資料快取方面考慮，當然，後期可以採用hadoop hbase hive等分布式儲存分析平台 三 主流解cache和資料庫對比 上述技術基本...
memcache redis原理對比
一 問題 資料庫表資料量極大 千萬條 要求讓伺服器更加快速地響應使用者的需求。二 解決方案 1.通過高速伺服器cache快取資料庫資料 2.記憶體資料庫 這裡僅從資料快取方面考慮，當然，後期可以採用hadoop hbase hive等分布式儲存分析平台 三 主流解cache和資料庫對比 上述技術基本...
Memcache Redis快取構建
二 構建快取伺服器 2.2 redis儲存 總結許多web應用都將資料儲存到 rdbms relational database management system，關聯式資料庫管理系統 中，應用伺服器從中讀取資料並在瀏覽器中顯示。但隨著資料量的增大 訪問的集中，就會出現rdbms的負擔加重 資料庫...