建站
咨詢
售后
建站咨詢
新聞中心
Redis 是一個(gè)開(kāi)源的使用 ANSI C 語(yǔ)言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value 數(shù)據(jù)庫(kù)，并提供多種語(yǔ)言的 API。
創(chuàng)新互聯(lián)成立與2013年，先為新林等服務(wù)建站，新林等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為新林企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。
如今，互聯(lián)網(wǎng)業(yè)務(wù)的數(shù)據(jù)正以更快的速度在增長(zhǎng)，數(shù)據(jù)類型越來(lái)越豐富，這對(duì)數(shù)據(jù)處理的速度和能力提出了更高要求。Redis 是一種開(kāi)源的內(nèi)存非關(guān)系型數(shù)據(jù)庫(kù)，給開(kāi)發(fā)人員帶來(lái)的體驗(yàn)是顛覆性的。在自始至終的設(shè)計(jì)過(guò)程中，都充分考慮高性能，這使得 Redis 成為當(dāng)今速度最快的 NoSQL 數(shù)據(jù)庫(kù)。
考慮高性能的同時(shí)，高可用也是很重要的考慮因素。互聯(lián)網(wǎng) 7x24 無(wú)間斷服務(wù)，在故障期間以最快的速度 Failover，能給企業(yè)帶來(lái)最小的損失。
那么，在實(shí)際應(yīng)用中，都有哪些高可用架構(gòu)呢？架構(gòu)之間有何優(yōu)劣？我們應(yīng)該怎么取舍？有哪些***實(shí)踐？以下四個(gè)方面十個(gè)具有典型性和普遍性問(wèn)題的解答，可以作為了解 Redis 高可用及 Redis 運(yùn)維的參考。
一、高可用相關(guān)
1：Redis 常用高可用架構(gòu)有哪些？
Redis 高可用架構(gòu)如下：
- Redis Sentinel 集群 + 內(nèi)網(wǎng) DNS + 自定義腳本
- Redis Sentinel 集群 + VIP + 自定義腳本
- 封裝客戶端直連 Redis Sentinel 端口
JedisSentinelPool，適合 Java
PHP 基于 phpredis 自行封裝
- Redis Sentinel 集群 + Keepalived/Haproxy
- Redis M/S + Keepalived
- Redis Cluster
- Twemproxy
- Codis
2：Redis 高可用架構(gòu)優(yōu)劣對(duì)比？
—Redis Sentinel 集群 + 內(nèi)網(wǎng) DNS + 自定義腳本
優(yōu)點(diǎn)：
- 秒級(jí)切換
- 腳本自定義，架構(gòu)可控
- 對(duì)應(yīng)用透明
缺點(diǎn)：
- 維護(hù)成本略高
- 依賴 DNS，存在解析延時(shí)
- Sentinel 模式存在短時(shí)間的服務(wù)不可用
- —Redis Sentinel 集群 + VIP + 自定義腳本
優(yōu)點(diǎn)：
- 秒級(jí)切換
- 腳本自定義，架構(gòu)可控
- 對(duì)應(yīng)用透明
缺點(diǎn)：
- 維護(hù)成本略高
- Sentinel 模式存在短時(shí)間的服務(wù)不可用
- —封裝客戶端直連 Redis Sentinel 端口
優(yōu)點(diǎn)：
- 服務(wù)探測(cè)故障及時(shí)
- DBA 維護(hù)成本低
缺點(diǎn)：
- 依賴客戶端支持 Sentinel
- Sentinel 服務(wù)器需要開(kāi)放訪問(wèn)權(quán)限
- 對(duì)應(yīng)用有侵入性
- —Redis Sentinel 集群 + Keepalived/Haproxy
優(yōu)點(diǎn)：
- 秒級(jí)切換
- 對(duì)應(yīng)用透明
缺點(diǎn)：
- 維護(hù)成本高
- 存在腦裂
- Sentinel 模式存在短時(shí)間的服務(wù)不可用
- —Redis M/S +Keepalived
優(yōu)點(diǎn)：
- 秒級(jí)切換
- 對(duì)應(yīng)用透明
- 部署簡(jiǎn)單，維護(hù)成本低
缺點(diǎn)：
- 需要腳本實(shí)現(xiàn)切換功能
- 存在腦裂
（Redis Cluster、Twemproxy、Codis 優(yōu)劣對(duì)比見(jiàn)下個(gè)問(wèn)題）
3：常見(jiàn)的 Redis 集群方案有哪些優(yōu)缺點(diǎn)？
Twemproxy:
多個(gè)同構(gòu) Twemproxy（配置相同）同時(shí)工作，接受客戶端的請(qǐng)求，根據(jù) hash 算法，轉(zhuǎn)發(fā)給對(duì)應(yīng)的 Redis。
優(yōu)點(diǎn)：
- 開(kāi)發(fā)簡(jiǎn)單，對(duì)應(yīng)用幾乎透明
- 歷史悠久，方案成熟
缺點(diǎn)：
- 代理影響性能
- LVS 和 Twemproxy 會(huì)有節(jié)點(diǎn)性能瓶頸
- Redis 擴(kuò)容非常麻煩
- Twitter 內(nèi)部已放棄使用該方案，新使用的架構(gòu)未開(kāi)源
Codis:
ZooKeeper
存放路由表和代理節(jié)點(diǎn)元數(shù)據(jù)
分發(fā)Codis-Config的命令
Codis-Config 集成管理工具，有web界面
Codis-Proxy
無(wú)狀態(tài)代理，兼容Redis協(xié)議
對(duì)業(yè)務(wù)透明
Codis-Redis
基于2.8版本，二次開(kāi)發(fā)
加入slot支持和遷移命令
優(yōu)點(diǎn)：
- 開(kāi)發(fā)簡(jiǎn)單，對(duì)應(yīng)用幾乎透明
- 性能比 Twemproxy 好
- 有圖形化界面，擴(kuò)容容易，運(yùn)維方便
缺點(diǎn)：
- 代理依舊影響性能
- 組件過(guò)多，需要很多機(jī)器資源
- 修改了 Redis 代碼，導(dǎo)致和官方無(wú)法同步，新特性跟進(jìn)緩慢
- 開(kāi)發(fā)團(tuán)隊(duì)準(zhǔn)備主推基于 Redis 改造的 reborndb
Redis Cluster:
P2P模式，無(wú)中心化。把 key 分成 16384 個(gè) slot，每個(gè)實(shí)例負(fù)責(zé)一部分 slot?？蛻舳苏?qǐng)求若不在連接的實(shí)例，該實(shí)例會(huì)轉(zhuǎn)發(fā)給對(duì)應(yīng)的實(shí)例。通過(guò)Gossip協(xié)議同步節(jié)點(diǎn)信息。
優(yōu)點(diǎn)：
- 組件 all-in-box，部署簡(jiǎn)單，節(jié)約機(jī)器資源
- 性能比 proxy 模式好
- 自動(dòng)故障轉(zhuǎn)移、Slot 遷移中數(shù)據(jù)可用
- 官方原生集群方案，更新與支持有保障
缺點(diǎn)：
- 架構(gòu)比較新，***實(shí)踐較少
- 多鍵操作支持有限（驅(qū)動(dòng)可以曲線救國(guó)）
- 為了性能提升，客戶端需要緩存路由表信息
- 節(jié)點(diǎn)發(fā)現(xiàn)、reshard 操作不夠自動(dòng)化
二、Redis 通用
1：Redis 相對(duì) MySQL、PostgreSQL 這些關(guān)系型數(shù)據(jù)庫(kù)，有什么優(yōu)缺點(diǎn)？
觀點(diǎn)一：
Redis 主要是用來(lái)做緩存，它有持久化，但也只是為了緩存的可靠而已。優(yōu)點(diǎn)是數(shù)據(jù)全放內(nèi)存，速度快。缺點(diǎn)就是，數(shù)據(jù)大小不能超過(guò)內(nèi)存大小。兩個(gè)用在不同業(yè)務(wù)場(chǎng)景，Redis 無(wú)法取代傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)。
觀點(diǎn)二：
Redis 首先它是一種內(nèi)存數(shù)據(jù)庫(kù)，***的優(yōu)勢(shì)在于效率高。尤其在某些特定場(chǎng)合下，例如熱點(diǎn)數(shù)據(jù)量非常大，而數(shù)據(jù)從內(nèi)存和磁盤之間的換入換出代價(jià)比較高的情況下，Redis 就會(huì)體現(xiàn)它的價(jià)值。
傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)在于它對(duì)數(shù)據(jù)的一致性保障，它的數(shù)據(jù)模型范式是遵循嚴(yán)格事務(wù)規(guī)則的結(jié)構(gòu)化數(shù)據(jù)，由于其數(shù)據(jù)的高度抽象化，它調(diào)度到內(nèi)存的數(shù)據(jù)一般場(chǎng)合下不會(huì)占用很大的內(nèi)存空間。
總的來(lái)說(shuō)，兩種數(shù)據(jù)庫(kù)各有各的優(yōu)點(diǎn)和缺點(diǎn)。不同的業(yè)務(wù)場(chǎng)合有特定的追求目標(biāo)，redis 首要的是效率，適用的是一些單純二維結(jié)構(gòu)化數(shù)據(jù)無(wú)法表達(dá)的數(shù)據(jù)模型，而關(guān)系型數(shù)據(jù)庫(kù)處理的是可以用范式模型表達(dá)的二維數(shù)據(jù)，追求的是數(shù)據(jù)的高度一致性。隨著 IT 的發(fā)展，每一類型的數(shù)據(jù)庫(kù)都會(huì)在其特定的場(chǎng)合內(nèi)發(fā)揮出無(wú)可比擬的優(yōu)勢(shì)，最終的趨勢(shì)是大家趨于平衡，沒(méi)有***，只有最適合。
觀點(diǎn)三：
記住一句話：任何數(shù)據(jù)庫(kù)都有自己的應(yīng)用場(chǎng)景，應(yīng)該關(guān)注數(shù)據(jù)流、數(shù)據(jù)屬性。
個(gè)人的經(jīng)驗(yàn)來(lái)說(shuō)，Redis 不可能取代 MySQL 或者 PG。
2：Redis 有哪些應(yīng)用場(chǎng)景，是否可以舉例說(shuō)明下哪個(gè)公司用了？
Redis 是一個(gè)高性能的緩存，一般應(yīng)用在 Session 緩存、隊(duì)列、排行榜、計(jì)數(shù)器、最近最熱文章、最近最熱評(píng)論、發(fā)布訂閱等。
更多應(yīng)用場(chǎng)景，可以參考此處。
可以這樣講，Redis 適用于 數(shù)據(jù)實(shí)時(shí)性要求高、數(shù)據(jù)存儲(chǔ)有過(guò)期和淘汰特征的、不需要持久化或者只需要保證弱一致性、邏輯簡(jiǎn)單的場(chǎng)景。
國(guó)內(nèi)的互聯(lián)網(wǎng)公司，據(jù)我了解，基本是都在用，其中新浪對(duì) Redis 在國(guó)內(nèi)普及起了重要的作用。
另外，Redis 官網(wǎng)有「Who's using Redis?」的鏈接。
3：新接手一個(gè)復(fù)雜的 Redis 集群（Sentinel 模式），如何了解它
剛剛接手一套 Redis 集群，想要了解這套集群的相關(guān)配置。應(yīng)該如何入手。難道只能通過(guò) info 命令去查看各個(gè)配置嗎？
這是筆者的建議：
通讀 Sentinel 官方文檔：https://redis.io/topics/sentinel
Google 搜索 Redis Sentinel，找?guī)灼杏⑽牡奈恼驴纯?/p>
進(jìn)入 Sentinel 集群后，使用 info 查看集群信息
查看 Sentinel 配置文件，配合文檔搞清楚每個(gè)參數(shù)的含義
使用幾臺(tái)虛擬機(jī)模擬線上環(huán)境，然后做測(cè)試，在實(shí)踐中深入理解
思考當(dāng)前 Sentinel 集群是否有不合理的地方，如有，提出并改進(jìn)
三、Redis 故障排查
1：Redis 實(shí)例中，存在大量的 FIN_WAIT2 連接
客戶端 TCP 狀態(tài)遷移：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服務(wù)器 TCP 狀態(tài)遷移：
CLOSED->LISTEN->SYN 收到 ->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED
這個(gè)狀態(tài)存在于主動(dòng)發(fā)起斷開(kāi)請(qǐng)求的一端，如果服務(wù)器存在大量的這個(gè)狀態(tài)，那么這個(gè)服務(wù)器就充當(dāng)客戶端的角色，如網(wǎng)絡(luò)爬蟲，出現(xiàn)的原因是由于客戶端發(fā)起 FIN 請(qǐng)求結(jié)束連接之后，收到了服務(wù)端的應(yīng)答之后進(jìn)入 FIN_WAIT2，之后就沒(méi)收到服務(wù)端發(fā)送的 FIN 信號(hào)導(dǎo)致。
PS：線上 Web 客戶端用的什么語(yǔ)言？
此問(wèn)題的評(píng)論值得一看：http://www.aixchina.net/Question/231035-1406575
2：如何知道，當(dāng)前 Redis 實(shí)例是處于阻塞狀態(tài)？
請(qǐng)問(wèn)大神們， 通過(guò)什么方式，能夠知道，當(dāng)前某個(gè) Redis 實(shí)例是處于阻塞狀態(tài)??？ 能不能通過(guò)某個(gè)命令查詢出來(lái) ？ 求解， 謝謝！
解答一：
隨便 get 一個(gè) key，然后卡著不動(dòng)就行，簡(jiǎn)單粗暴。優(yōu)雅一點(diǎn)是看 latency 的延遲，blocked_clients 的數(shù)量，rejected_connections 的數(shù)量等。
解答二：
方法一：登錄 Redis，執(zhí)行 info，查看 blocked_clients
方法二：執(zhí)行 redis-cli --latency -h -p 查看延時(shí)情況
3：Redis 運(yùn)維的故障有哪些？
回答一：
常見(jiàn)的運(yùn)維故障
使用 keys * 把庫(kù)堵死，——建議使用別名把這個(gè)命令改名
超過(guò)內(nèi)存使用后，部分?jǐn)?shù)據(jù)被刪除——這個(gè)有刪除策略的，選擇適合自己的即可
沒(méi)開(kāi)持久化，卻重啟了實(shí)例，數(shù)據(jù)全掉——記得非緩存的信息需要打開(kāi)持久化
RDB 的持久化需要 vm.overcommit_memory=1，否則會(huì)持久化失敗
沒(méi)有持久化情況下，主從，主重啟太快，從還沒(méi)認(rèn)為主掛的情況下，從會(huì)清空自己的數(shù)據(jù)——人為重啟主節(jié)點(diǎn)前，先關(guān)閉從節(jié)點(diǎn)的同步
回答二：
我簡(jiǎn)單說(shuō)下 Redis 故障的排查方法吧。
了解清楚業(yè)務(wù)數(shù)據(jù)流是怎么樣的
結(jié)合 Redis 監(jiān)控查看 QPS、緩存***率、內(nèi)存使用率等信息
確認(rèn)機(jī)器層面的資源是否有異常
故障時(shí)及時(shí)上機(jī)，使用 redis-cli monitor 打印出操作日志，然后分析（事后分析此條失效）
和研發(fā)溝通，確認(rèn)是否有大 Key 在堵塞（大 Key 也可以在日常的巡檢中獲得）
和組內(nèi)同事溝通，確實(shí)是否有誤操作
和運(yùn)維同事、研發(fā)一起排查流量是否正常，是否存在被刷的情況
更多的排查需要對(duì)線上系統(tǒng)的分析。
四、Redis 性能優(yōu)化
1：提高 Redis 內(nèi)存數(shù)據(jù)庫(kù)的性能，有哪些措施？
這個(gè)問(wèn)題有點(diǎn)偏題了，還是回答下吧。整理下工作中積累的經(jīng)驗(yàn)：
- 根據(jù)不同業(yè)務(wù)選擇數(shù)據(jù)類型，有必要時(shí)對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行審核，減少數(shù)據(jù)冗余
- 精簡(jiǎn)鍵名和鍵值，控制鍵值的大小
- 使用前綴管理好 key
- 使用 scan 代替 keys，將遍歷 Redis DB 中所有 key 的操作放到客戶端來(lái)做
- 避免使用 O(N) 復(fù)雜度的命令
- 配置使用 ziplist 來(lái)優(yōu)化 list
- 合理配置 maxmemory
- 數(shù)據(jù)量大的情況，做好 key 和 value 的壓縮
- 利用管道，批量處理命令
- 根據(jù)不同業(yè)務(wù)選擇短鏈接或者長(zhǎng)鏈接
- 定期使用 redis-cli --big-keys 檢測(cè)大 Key
本文題目：十個(gè)問(wèn)答助你了解Redis高可用架構(gòu)及Redis運(yùn)維
文章出自：http://www.5511xx.com/article/dhipdog.html
