分佈式緩存的主要有點： 高性能與高併發
高性能：內存讀取速度遠高於數據庫
高併發：數據庫瞬間不能支持高併發，通過緩存，可以支持每秒十萬級的請求。普通數據庫每秒響應千級的。
使用緩存存在的常規問題：
1.緩存與數據庫雙寫不一致 常用的是先更新數據庫，然後刪除緩存 這個叫 Cache Aside Pattern，老外發明的。如果先更新數據庫，再刪除緩存，那麼就會出現更新數據庫之前有瞬間數據不是很及時。 可以 先刪緩存，然後寫db，通過訂閱數據庫的binlog在刪除緩存。
2.緩存雪崩 緩存集羣掛了，或者大量緩存同一時間過期的導致大量請求打到db。保證緩存集羣的高可用， 哨兵或者cluster方案。熱點key不要過去，定時去更新。熱點key分部在cluster的不同節點上。
3.緩存擊穿 一個緩存key失效的瞬間，大量請求進入db。 做限流，分佈式鎖，只允許一個請求去查詢db。
4.緩存穿透 大量cache中不存在這個key,請求進入db。 可以在db中查詢沒有的key，在cache中設置一個快速過期的空值。或者使用布隆過濾器，把所有可能存的數據存在一個足夠大的bitmap中，一定不存在的數據就會被攔截在，從而避免對底層數據庫的查詢。
redis的線程模型：
redis基於reactor模式開發了網絡事件處理模型，這個事件叫做文件事件處理模型（file event handler）。這個文件處理器是單線程的，採用IO多路複用機制同時監聽多個socket，根據socket上的事件來選擇對應事件處理器來處理這個事件。
文件事件處理器是單線程運行的，但是通過IO多路複用機制來監聽多個socket，可以實現高性能的網絡通信模型，又可以和內部其他單線程的模塊進行對接，保證了redis內部的線程模型的簡單性。
文件事件處理包含四個部分:多個socket，IO多路複用程序，文件事件分派器，事件處理器(命令請求處理器，命令回覆處理器，連接答應處理器等等)。
多個socket可能併發的產生不同的操作，每個操作對應不同的文件事件，但是IO多路複用機制會監聽多個socket，但是會將socket放入一個隊列中進行排隊，每次從隊列中取出一個socket給事件分派器，事件分派器把socket給對應的事件處理器。然後一個socket的事件處理完成之後，IO多路複用程序纔會將隊列中的下一個socket給事件分配器，事件分配器把socket給具體的事件處理器。
客戶端與redis通信的一次流程。
Redis的客戶端對服務端的每次調用都經歷了發送命令，執行命令，返回結果三個步驟。其中執行命令階段，由於redis是單線程來處理命令的，所以每條到達服務端的命令不會立即被執行，所有命令會進入一個隊列然後逐個被執行。多個客戶端發送的命令的執行順序是不確定的，但是可以確定的是兩個命令不會被同時執行，不會產生併發問題，這就是redis的單線程基本模型。
在redis啓動初始化的時候,redis會將連接應答處理器和跟AE_READABLE事件關聯起來。
當有一個client和redis發起連接，此時會產生一個AE_READABLE事件，然後又對應的事件處理器處理。這個命令處理器就會從socket中讀取相關的數據，然後進行執行和處理。
當客戶端像redis發起請求的時候(不管是讀還是寫請求都一樣)，首先會在socket產生一個AE_READABLE事件，然後由對應的命令請求處理器來處理。這個命令請求處理器就會從socket中讀取相應的數據，然後進行執行和處理。
接着redis準備好了給客戶端的相應數據之後，就會將socket的AE_WRITABLE ;
事件跟命令回覆關聯起來，當客戶端這邊準備好讀取響應數據的時候，就會在socket上產生一個AE_WRITABLE事件，會由對應的命令回覆處理器來處理，就是將準備好的數據寫入socket，供客戶端來讀取。命令回覆處理器寫完之後，就會刪除這個socket的AE_WRITABLE事件和命令回覆處理器的關聯關係。
