redis集群在大街網(wǎng)應(yīng)用實踐

Redis集群在大街網(wǎng)的應(yīng)用實踐@大街網(wǎng)大街Redis緩存架構(gòu)遇到的坑大街Redis自動化單節(jié)點自建hash集群Redis

Cluster（1）Redis主從架構(gòu)：LVS+Keepalive+Redis主從程序通過VIP+端口來

Redis問題：部署為單機多實例，基于服務(wù)器級別的故障切換，只有當(dāng)部署在主服務(wù)器上的Redis全部掛掉或者主服務(wù)器宕機的情況下，才能切換到備服務(wù)器上的redis。RedisRedisRedisRedisZK程序中間層（Proxy）Hash

node1Hash

node2Hash

node3Hash

node4優(yōu)點：避免單節(jié)點的瓶頸缺點：中間層控制hash路由規(guī)則，導(dǎo)致程序比較重，而且keys分布不均，仍然無法解決高可用問題，其中任何一個節(jié)點宕機，都會對程序產(chǎn)生影響(3)Redis

Cluster簡介1、優(yōu)點:12、高可用、高性能、擴展性好、支持分片34、豐富集群管理命令:cluster

xxx2、缺點不支持多keys操作(如果keys在同一個hashslot是可以的)；只能用0號數(shù)據(jù)庫；缺少大規(guī)模線上使用，不知道有多少坑。（4）Redis

Cluster簡介20億+300+幾十臺服務(wù)器1TCommand/day:Instance:Servers：Memoryused:RedisSlaveRedisRedisRedisRedisRedisRedisZK程序中間層RedisSlaveRedisSlaveRedisSlaveRedisSlaveRedisSlave特點：1、基于配置中心，對程序透明，并且保證數(shù)據(jù)源只要有一個可用，集群就不受影響。2、根據(jù)業(yè)務(wù)來劃分集群，避免不同業(yè)務(wù)公用同一集群帶來的相互影響。（1）最大內(nèi)存、內(nèi)存過期策略、keys過期時間設(shè)定2內(nèi)存碎片率(mem_fragmentation_ratio)Redis

Cluster

參數(shù)配置keys

*、flushdb

命令連接周期性異常3456bgsave導(dǎo)致的集群阻塞問題（AOF

orRdb？）1、最大內(nèi)存沒有設(shè)定config

set

maxmemory=?2、Keys過期時間根據(jù)需求：

ORCacheCache：設(shè)定ttl避免內(nèi)存超限：不設(shè)定，必須

內(nèi)存使用并自動調(diào)整內(nèi)存3、合理配置Redis的過期策略volatile-lru：使用LRU算法從已設(shè)置過期時間的數(shù)據(jù)集合中淘汰數(shù)據(jù)。volatile-ttl：從已設(shè)置過期時間的數(shù)據(jù)集合中挑選即將過期的數(shù)據(jù)淘汰。

volatile-random：從已設(shè)置過期時間的數(shù)據(jù)集合中隨機挑選數(shù)據(jù)淘汰。allkeys-lru：使用LRU算法從所有數(shù)據(jù)集合中淘汰數(shù)據(jù)。allkeys-random：從數(shù)據(jù)集合中任意選擇數(shù)據(jù)淘汰no-enviction：

淘汰數(shù)據(jù)。mem_fragmentation_ratio=used_memory_rss/used_memory1、mem_fragmentation_ratio>1問題原因：Redis沒有內(nèi)存回收機制，如果批量過期數(shù)據(jù)或者刪除數(shù)據(jù)，內(nèi)存的碎片可能就比較大。解決方式：重啟Redis實例2、mem_fragmentation_ratio<1問題產(chǎn)生原因:一般發(fā)生在內(nèi)存緊張的服務(wù)器，就是本身內(nèi)存剩余不多，redis申請不到足夠的內(nèi)存，這樣就會使用swap解決方式：增加物理內(nèi)存，或者減少redis內(nèi)存占用(刪除一些keys)1、cluster-node-timeout

50002、cluster-require-full-coverage

noRedis異常，大量的5XX1、問題描述線上Service2、問題分析查看慢日志：執(zhí)行keys*時間跟Service

Error時間一致

127.0.0.1:XXXX>SLOWLOG

get

101)

(integer)

545(integer))

(integer)

80389734)

1)

"keys"2)"*visit_uid”mysql>

select

from_unixtime(1446775933);+

+|

from_unixtime(1446775933)|+

+|

2015-11-06

10:12:13

|+

+1

row

in

set(0.01

sec)3、問題解決在配置文件中禁用命令：keys

rename‘’使用Redis自帶客戶端：redis-cli-h-p–scan

–pattern‘*visit’實現(xiàn)同樣的功能1、問題描述某個redis節(jié)點，發(fā)現(xiàn)每隔半個小時連接數(shù)突增10倍以上2、問題分析統(tǒng)計一段時間的redis連接發(fā)現(xiàn)，redis瞬時連接都正常，初步判定是某個ip頻繁創(chuàng)建和關(guān)閉連接導(dǎo)致3、問題解決通過tcpflow來抓取問題時間段的連接數(shù)據(jù)包情況，最終定位到具體的ip，并且找到原因。tcpflow

-c

-p

-i

em1

dst

192.168.1.30

and

port

6379

>

dxl2.log1、問題現(xiàn)象：線上官客、job大量的5XX2、問題排查：查看job集群的Redis

log，發(fā)現(xiàn)aof寫入異常：disk

is

busy？查看服務(wù)器的IO負載情況，發(fā)現(xiàn)在16點03和10分有2個IO峰值，跟job抖動的時間重合3、問題定位：查看這個時間段的高IO操作，因為這個是redis服務(wù)器，導(dǎo)致高IO只能是rdb數(shù)據(jù)落地。最終發(fā)現(xiàn)是profile業(yè)務(wù)的bgsave導(dǎo)致。4、問題解決：AOF

or

RDB？加操作

日志文件(append

only

file)

。

并所有寫入操作，如果有類似flushdb操作，只需要刪除文件中AOF：優(yōu)點：aof文件是一個只且有序的保存了對數(shù)據(jù)庫執(zhí)flushdb的操作，重啟redis即可缺點：aof文件比較大，根據(jù)不同的fsync策略，aof的速度可能比rdb慢RDB：優(yōu)點：文件緊湊，非常適合備份以及快速恢復(fù)缺點：只是某一時刻的內(nèi)存快照，即數(shù)據(jù)不是

，適合緩存集群，不適合集群?？偨Y(jié)：根據(jù)需求選擇，緩存集群使用RDB備份，集群使用AOF，采用SSD設(shè)備；遷移集群到新服務(wù)器（1）自動化之規(guī)范2自動化部署、配置(修改內(nèi)存等配置)3自動化4redis自動化遷移工具5集群擴容6自動化備份7分析(slowlog分析、keys分布)1、keys命名規(guī)范：出現(xiàn)redis的key命名盡量簡單明確，最好根據(jù)子業(yè)務(wù)名(或者縮寫)命名，keys命名各種復(fù)雜符號。比如下面的keys，下面的key首先過長、然后有空格、還有&符號test_guangzhou

spengler

automated

vending

technologies

reaserch

&

development

co.,2、Redis使用規(guī)范：將大量的成員

到一個hash

key中連接線上redis執(zhí)行keys

*dxl這種方式來過濾keyskeys建議設(shè)定過期時間，除非是把redis當(dāng)

用。合理使用Redis的數(shù)據(jù)類型緣由：由于人工設(shè)定內(nèi)存

導(dǎo)致集群節(jié)點不可用目的：自動化

來智能配置內(nèi)存RedisRedisRedisRedisRedisRedisRedis

ClusterRedisRedis：基于redis

port功能：實現(xiàn)單節(jié)點中部分keys的遷移單redis遷移到redis

cluster自建hash集群遷移到redis

clusterRedis

ETL1Buff23Rdb4567可以使用2種方式對集群擴容：1、為集群所有節(jié)點擴