㈠ 緩存-redis 三種模式搭建和運行原理
標簽： redis 緩存 主從 哨兵 集群
本文簡單的介紹redis三種模式在linux的安裝部署和數據存儲的總結，希望可以相互交流相互提升。
對於Centos7在安裝redis之前需要進行一些常用工具的安裝：
關閉防火牆
正式安裝redis
在redis進行maketest時候會出現一系列的異常，有如下解決方案：
用redis-server啟動一下redis，做一些實驗沒什麼意義。
要把redis作為一個系統的daemon進程去運行的，每次系統啟動，redis進程一起啟動，操作不走如下：
RDB和AOF是redis的一種數據持久化的機制。 持久化 是為了避免系統在發生災難性的系統故障時導致的系統數據丟失。我們一般會將數據存放在本地磁碟，還會定期的將數據上傳到雲伺服器。
RDB 是redis的snapshotting，通過redis.conf中的save配置進行設置，如 save 60 1000:
AOF 是以appendonly方式進行數據的儲存的，開啟AOF模式後，所有存進redis內存的數據都會進入os cache中,然後默認1秒執行一次fsync寫入追加到appendonly.aof文件中。一般我們配置redis.conf中的一下指令：
AOF和RDB模式我們一般在生產環境都會打開，一般而言，redis服務掛掉後進行重啟會優先家在aof中的文件。
當啟動一個slave node的時候，它會發送一個PSYNC命令給master node,如果這是slave node重新連接master node，那麼master node僅僅會復制給slave部分缺少的數據;否則如果是slave node第一次連接master node，那麼會觸發一次full resynchronization;
開始full resynchronization的時候，master會啟動一個後台線程，開始生成一份RDB快照文件，同時還會將從客戶端收到的所有寫命令緩存在內存中。RDB文件生成完畢之後，master會將這個RDB發送給slave，slave會先寫入本地磁碟，然後再從本地磁碟載入到內存中。然後master會將內存中緩存的寫命令發送給slave，slave也會同步這些數據。
slave node如果跟master node有網路故障，斷開了連接，會自動重連。master如果發現有多個slave node都來重新連接，僅僅會啟動一個rdb save操作，用一份數據服務所有slave node。
從redis 2.8開始，就支持主從復制的斷點續傳，如果主從復制過程中，網路連接斷掉了，那麼可以接著上次復制的地方，繼續復制下去，而不是從頭開始復制一份。
master node會在內存中常見一個backlog，master和slave都會保存一個replica offset還有一個master id，offset就是保存在backlog中的。如果master和slave網路連接斷掉了，slave會讓master從上次的replica offset開始繼續復制,但是如果沒有找到對應的offset，那麼就會執行一次resynchronization。
master在內存中直接創建rdb，然後發送給slave，不會在自己本地落地磁碟了，可以有如下配置：
slave不會過期key，只會等待master過期key。如果master過期了一個key，或者通過LRU淘汰了一個key，那麼會模擬一條del命令發送給slave。
在redis.conf配置文件中，上面的參數代表至少需要3個slaves節點與master節點進行連接，並且master和每個slave的數據同步延遲不能超過10秒。一旦上面的設定沒有匹配上，則master不在提供相應的服務。
sdown達成的條件很簡單，如果一個哨兵ping一個master，超過了 is-master-down-after-milliseconds 指定的毫秒數之後，就主觀認為master宕機
sdown到odown轉換的條件很簡單，如果一個哨兵在指定時間內，收到了 quorum 指定數量的其他哨兵也認為那個master是sdown了，那麼就認為是odown了，客觀認為master宕機
如果一個slave跟master斷開連接已經超過了down-after-milliseconds的10倍，外加master宕機的時長，那麼slave就被認為不適合選舉為master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
每次一個哨兵要做主備切換，首先需要quorum數量的哨兵認為odown，然後選舉出一個slave來做切換，這個slave還得得到majority哨兵的授權，才能正式執行切換；
（2）SENTINEL RESET *，在所有sentinal上執行，清理所有的master狀態
（3）SENTINEL MASTER mastername，在所有sentinal上執行，查看所有sentinal對數量是否達成了一致
4.3.2 slave的永久下線
讓master摘除某個已經下線的slave：SENTINEL RESET mastername，在所有的哨兵上面執行.
redis的集群模式為了解決系統的橫向擴展以及海量數據的存儲問題，如果你的數據量很大，那麼就可以用redis cluster。
redis cluster可以支撐N個redis master,一個master上面可以掛載多個slave，一般情況我門掛載一個到兩個slave，master在掛掉以後會主動切換到slave上面，或者當一個master上面的slave都掛掉後，集群會從其他master上面找到冗餘的slave掛載到這個master上面，達到了系統的高可用性。
2.1 redis cluster的重要配置
2.2 在三台機器上啟動6個redis實例
將上面的配置文件，在/etc/redis下放6個，分別為: 7001.conf，7002.conf，7003.conf，7004.conf，7005.conf，7006.conf
每個啟動腳本內，都修改對應的埠號
2.3 創建集群
解決辦法是 先安裝rvm，再把ruby版本提升至2.3.3
使用redis-trib.rb命令創建集群
--replicas: 表示每個master有幾個slave
redis-trib.rb check 192.168.31.187:7001 查看狀體
3.1 加入新master
以上相同配置完成後，設置啟動腳本進行啟動；然後用如下命令進行node節點添加：
3.2 reshard一些數據過去
3.3 添加node作為slave
3.4 刪除node
㈡ 如何使用redis做mysql的緩存
應用Redis實現數據的讀寫，同時利用隊列處理器定時將數據寫入MySQL。
同時要注意避免沖突，在redis啟動時去mysql讀取所有表鍵值存入redis中，往redis寫數據時，對redis主鍵自增並進行讀取，若mysql更新失敗，則需要及時清除緩存及同步redis主鍵。
這樣處理，主要是實時讀寫redis，而mysql數據則通過隊列非同步處理，緩解mysql壓力，不過這種方法應用場景主要基於高並發，而且redis的高可用集群架構相對更復雜，一般不是很推薦。
《內存資料庫和mysql的同步機制》
redis如何做到和mysql資料庫的同步
【方案一】http://www.hu.com/question/23401553?sort=created
程序實現mysql更新、添加、刪除就刪除redis數據。
程序查詢redis，不存在就查詢mysql並保存redis
redis和mysql數據的同步，代碼級別大致可以這樣做：
讀: 讀redis->沒有，讀mysql->把mysql數據寫回redis
寫: 寫mysql->成功，寫redis（捕捉所有mysql的修改，寫入和刪除事件，對redis進行操作）
【方案二】http://www.linuxidc.com/Linux/2015-01/380.htm
實時獲取mysql binlog進行解析，然後修改redis
MySQL到Redis數據方案
無論MySQL還是Redis，自身都帶有數據同步的機制，像比較常用的MySQL的Master/Slave模式，就是由Slave端分析Master的binlog來實現的，這樣的數據其實還是一個非同步過程，只不過當伺服器都在同一內網時，非同步的延遲幾乎可以忽略。
那麼理論上我們也可以用同樣方式，分析MySQL的binlog文件並將數據插入Redis。但是這需要對binlog文件以及MySQL有非常深入的理解，同時由於binlog存在Statement/Row/Mixedlevel多種形式，分析binlog實現同步的工作量是非常大的。
因此這里選擇了一種開發成本更加低廉的方式，借用已經比較成熟的MySQL UDF，將MySQL數據首先放入Gearman中，然後通過一個自己編寫的PHP Gearman Worker，將數據同步到Redis。比分析binlog的方式增加了不少流程，但是實現成本更低，更容易操作。
【方案三】
使用mysql的udf，詳情請看MySQL :: MySQL 5.1 Reference Manual :: 22.3 Adding New Functions to MySQL 然後通過trigger在表update和insert之後進行函數的調用，寫入到redis中去。大致是這個樣子。
【http://www.hu.com/question/27738066】
1.首先明確是不是一定要上緩存，當前架構的瓶頸在哪裡，若瓶頸真是資料庫操作上，再繼續往下看。
2.明確memcached和redis的區別，到底要使用哪個。前者終究是個緩存，不可能永久保存數據（LRU機制），支持分布式，後者除了緩存的同時也支持把數據持久化到磁碟等，redis要自己去實現分布式緩存（貌似最新版本的已集成），自己去實現一致性hash。因為不知道你們的應用場景，不好說一定要用memcache還是redis，說不定用MongoDB會更好，比如在存儲日誌方面。
3.緩存量大但又不常變化的數據，比如評論。
4.你的思路是對的，清晰明了，讀DB前，先讀緩存，如果有直接返回，如果沒有再讀DB，然後寫入緩存層並返回。
5.考慮是否需要主從，讀寫分離，考慮是否分布式部署，考慮是否後續水平伸縮。
6.想要一勞永逸，後續維護和擴展方便，那就將現有的代碼架構優化，按你說的替換資料庫組件需要改動大量代碼，說明當前架構存在問題。可以利用現有的一些框架，比如SpringMVC，將你的應用層和業務層和資料庫層解耦。再上緩存之前把這些做好。
7.把讀取緩存等操作做成服務組件，對業務層提供服務，業務層對應用層提供服務。
8.保留原始資料庫組件，優化成服務組件，方便後續業務層靈活調用緩存或者是資料庫。
9.不建議一次性全量上緩存，最開始不動核心業務，可以將邊緣業務先換成緩存組件，一步步換至核心業務。
10.刷新內存，以memcached為例，新增，修改和刪除操作，一般採用lazy load的策略，即新增時只寫入資料庫，並不會馬上更新Memcached，而是等到再次讀取時才會載入到Memcached中，修改和刪除操作也是更新資料庫，然後將Memcached中的數據標記為失效，等待下次讀取時再載入。
㈢ Docker NextCloud Redis緩存配置
轉自我的博客：https://sleele.com/2019/04/19/docker-nextcloud-redis緩則悄存配置/
前言
nextcloud這個東西真的是挺慢的，文件一多等刷新都要等很久，孫衡渣如果配置了Redis做緩存就會快不少
搭建過程我就不再贅述了，可以參照我上篇博文
https://sleele.com/2019/03/03/linux-qbittorrent和nextcloud安裝筆記/
部署redis
docker run --name redis -d redis
查看docker容器IP
docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq)
之後修改nextcloud的配置文件
首先到本地
docker cp nextcloud:/var/www/html/config/config.php /tmp/
vi /tmp/config.php
添加如下內容
找准位置在攔早【'memcache.local' => '\OC\Memcache\APCu',】 這行後面添加
host那行換成你的redis地址
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => array(
'host' => '172.17.0.5',
'port' => 6379,
),
再回去，注意直接回去會導致nextcloud報錯，需要修改許可權
docker cp config.php nextcloud:/var/www/html/config/
docker exec -it nextcloud bash
cd /var/www/html/config/
chmod 777 config.php
重啟nextcloud，教程結束
docker restart nextcloud
㈣ redis做mysql的緩存
redis緩存其實就是把經常訪問的數據放到redis裡面，用戶查詢的時候先去redis查詢，沒有查到就執行sql語句查詢，同時把數據同步到redis裡面。redis只做讀操作，在內存中查詢速度快。
使用redis做緩存必須解決兩個問題，首先就是確定用何種數據結構存儲來自mysql的數據；確定數據結構之後就是需要確定用什麼標識來作為數據的key。
mysql是按照表存儲數據的，這些表是由若干行組成。每一次執行select查詢，mysql都會返回一個結果集，這個結果是由若干行組成的。redis有五種數據結構：列表list，哈希hash，字元串string，集合set，sorted set(有序集合)，對比幾種數據結構，string和hash是比較適合存儲行的數據結構，可以把數據轉成json字元串存入redis。
全量遍歷鍵： keys pattern keys *
有人說 KEYS 相當於關系性數據的庫的 select * ，在生產環境幾乎是要禁用的
不管上面說的對不對， keys 肯定是有風險的。那我們就換一種方案，在存數據的時候。把數據的鍵存一下，也存到redis裡面選hash類型，那麼取的時候就可以直接通過這個hash獲取所有的值，自我感覺非常好用！
㈤ redis源碼解讀：單線程的redis是如何實現高速緩存的
redis可能是最近幾年最火的緩存資料庫方案了，在各個高並發領域都有應用。
這篇文章，我們將從源代碼的角度來分析一下，為何如此一個高性能，高應用的緩存，會是單線程的方案，當然一個方案的高性能，高並發是多方面的綜合因素，其它的因素我們將在後續解讀。後續分析主要以LINUX操作系統為基礎，這也是redis應用最廣的平台。
單線程最大的受限是什麼？就是CPU，現在伺服器一般已經是多CPU，而單線程只能使用到其中的一個核。
redis作為一個網路內存緩存資料庫，在實現高性能時，主要有4個點。
1.網路高並發，高流量的數據處理。
一個非同步，高效，且對CPU要求不高的網路模型，這個模型主要是由OS來提供的，目前在LINUX最主流使用的是EPOLL，這個網上介紹很多，主要是基於事件驅動的一個非同步模型。
2.程序內部的合理構架，調用邏輯，內存管理。
redis在採用純C實現時，整體調用邏輯很短，但在內存方面，適當的合並了一些對象和對齊，比如sds等，在底層使用了內存池，在不同情況下使用的不太一樣。
但整體處理上沒有NGINX的內池設計巧妙，當然二者不太一樣，NGINX是基於請求釋放的邏輯來設計的，因此針對請求，可以一次申請大塊，分量使用，再最後統一釋放。
3.數據復制的代價，不管是讀取數據或是寫入數據，一般都是需要有數據復制的過程。
數據復制其實就是一次內存，真正的代價是在於存在大VALUE，當value值長度超過16KB時，性能會開始下降。因為單線程的原因，如果存在一個超大VALUE，比如20MB，則會因為這個請求卡住整個線程，導致後續的請求進不來，雖然後面的請求是能快速處理的小請求。
4.redis中數據結構中演算法的代價，有些結構在大數據量時，代價是很高的。
很多時間，大家忽略了演算法的運算代碼，因為像memcached等這類是完全的KV緩存，不存在什麼演算法，除了一個KEY的查找定位HASH演算法。
而redis不一樣，提供了不少高階的數據對象，這些對象具有上層的一些演算法能力，而這些能力是需要比如GEO模塊。