redis 是乙個開源的使用 ansi c 語言編寫、支援網路、可基於記憶體亦可持久化的日誌型、key-value 資料庫，並提供多種語言的 api。
如今，網際網路業務的資料正以更快的速度在增長，資料型別越來越豐富，這對資料處理的速度和能力提出了更高要求。redis 是一種開源的記憶體非關係型資料庫，給開發人員帶來的體驗是顛覆性的。在自始至終的設計過程中，都充分考慮高效能，這使得 redis 成為當今速度最快的 nosql 資料庫。
考慮高效能的同時，高可用也是很重要的考慮因素。網際網路 7x24 無間斷服務，在故障期間以最快的速度 failover，能給企業帶來最小的損失。
那麼，在實際應用中，都有哪些高可用架構呢？架構之間有何優劣？我們應該怎麼取捨？有哪些最佳實踐？以下四個方面十個具有典型性和普遍性問題的解答，可以作為了解 redis 高可用及 redis 運維的參考。
一、高可用相關
1：redis 常用高可用架構有哪些？
redis 高可用架構如下：
redis sentinel 集群 + keepalived/haproxy
redis m/s + keepalived
redis cluster
twemproxy
codis
2：redis 高可用架構優劣對比？
—redis sentinel 集群 + 內網 dns + 自定義指令碼
優點：缺點：—redis sentinel 集群 + vip + 自定義指令碼
優點：缺點：—封裝客戶端直連 redis sentinel 埠
優點：缺點：—redis sentinel 集群 + keepalived/haproxy
優點：缺點：—redis m/s +keepalived
優點：缺點：（redis cluster、twemproxy、codis 優劣對比見下個問題）
3：常見的 redis 集群方案有哪些優缺點？
多個同構 twemproxy（配置相同）同時工作，接受客戶端的請求，根據 hash 演算法，**給對應的 redis。
優點：缺點：codis:
codis-config 整合管理工具，有web介面
codis-proxy
codis-redis
優點：缺點：
p2p模式，無中心化。把 key 分成 16384 個 slot，每個例項負責一部分 slot。客戶端請求若不在連線的例項，該例項會**給對應的例項。通過gossip協議同步節點資訊。
優點：缺點：二、redis 通用
1：redis 相對 mysql、postgresql 這些關係型資料庫，有什麼優缺點？
觀點一：
redis 主要是用來做快取，它有持久化，但也只是為了快取的可靠而已。優點是資料全放記憶體，速度快。缺點就是，資料大小不能超過記憶體大小。兩個用在不同業務場景，redis 無法取代傳統關係型資料庫。
觀點二：
redis 首先它是一種記憶體資料庫，最大的優勢在於效率高。尤其在某些特定場合下，例如熱點資料量非常大，而資料從記憶體和磁碟之間的換入換出代價比較高的情況下，redis 就會體現它的價值。
傳統關係型資料庫在於它對資料的一致性保障，它的資料模型正規化是遵循嚴格事務規則的結構化資料，由於其資料的高度抽象化，它排程到記憶體的資料一般場合下不會占用很大的記憶體空間。
總的來說，兩種資料庫各有各的優點和缺點。不同的業務場合有特定的追求目標，redis 首要的是效率，適用的是一些單純二維結構化資料無法表達的資料模型，而關係型資料庫處理的是可以用正規化模型表達的二維資料，追求的是資料的高度一致性。隨著 it 的發展，每一型別的資料庫都會在其特定的場合內發揮出無可比擬的優勢，最終的趨勢是大家趨於平衡，沒有最好，只有最適合。
觀點三：
記住一句話：任何資料庫都有自己的應用場景，應該關注資料流、資料屬性。
個人的經驗來說，redis 不可能取代 mysql 或者 pg。
2：redis 有哪些應用場景，是否可以舉例說明下哪個公司用了？
可以這樣講，redis 適用於 資料實時性要求高、資料儲存有過期和淘汰特徵的、不需要持久化或者只需要保證弱一致性、邏輯簡單的場景。
另外，redis 官網有「who's using redis?」的鏈結。
3：新接手乙個複雜的 redis 集群（sentinel 模式），如何了解它
剛剛接手一套 redis 集群，想要了解這套集群的相關配置。應該如何入手。難道只能通過 info 命令去檢視各個配置嗎？
這是筆者的建議：
三、redis 故障排查
1：redis 例項中，存在大量的 fin_wait2 連線
客戶端 tcp 狀態遷移：
closed->syn_sent->established->fin_wait_1->fin_wait_2->time_wait->closed
伺服器 tcp 狀態遷移：
closed->listen->syn 收到 ->established->close_wait->last_ack->closed
這個狀態存在於主動發起斷開請求的一端，如果伺服器存在大量的這個狀態，那麼這個伺服器就充當客戶端的角色，如網路爬蟲，出現的原因是由於客戶端發起 fin 請求結束連線之後，收到了服務端的應答之後進入 fin_wait2，之後就沒收到服務端傳送的 fin 訊號導致。
ps：線上 web 客戶端用的什麼語言？
2：如何知道，當前 redis 例項是處於阻塞狀態？
請問大神們， 通過什麼方式，能夠知道，當前某個 redis 例項是處於阻塞狀態啊？ 能不能通過某個命令查詢出來 ？ 求解， 謝謝！
解答一：
隨便 get 乙個 key，然後卡著不動就行，簡單粗暴。優雅一點是看 latency 的延遲，blocked_clients 的數量，rejected_connections 的數量等。
解答二：
3：redis 運維的故障有哪些？
回答一：
常見的運維故障
回答二：
我簡單說下 redis 故障的排查方法吧。
更多的排查需要對線上系統的分析。
四、redis 效能優化
1：提高 redis 記憶體資料庫的效能，有哪些措施？
Redis 運維架構
1.2 redis 高可用架構優劣對比？1.3 常見的 redis 集群方案有哪些優缺點？二 redis 通用 三 redis 故障排查 3.2 如何知道，當前 redis 例項是處於阻塞狀態？3.3 redis 運維的故障有哪些？四 redis 效能優化 redis 是乙個開源的使用 ansi c...
運維 Zabbix 監控安裝和架構簡介
wget rpm ivh zabbix release 4.0 2.el7.noarch.rpm rpm ql zabbix release 修改源 vim etc yum.repos.d zabbix.repo 全域性替換，vim開啟檔案後 按 依次複製2行內容並回車 s s gpgcheck 1...
Redis業務層面和運維層面優化
我們在了解了導致redis變慢的原因之後，針對性地優化，就可以讓redis穩定發揮出更高效能。由於我之前寫過很多ugc後端服務，在大量場景下用到了redis，這個過程中也踩過很多坑，所以在使用過程中也總結了一套合理的使用方法。後來做基礎架構，開發codis redis相關的中介軟體，在這個階段關注領...