1.Redis集群的搭建流程
網(wǎng)上有很多這樣的blog,在這里就不一一贅述了
Redis 3.0集群模式的搭建
https://www.cnblogs.com/wuxl360/p/5920330.html
Redis三種方式的搭建方式 redis-5.0.0
https://blog.csdn.net/qq_20597727/article/details/83385737
2.Redis的集群完整的配置文件redis.conf
bind "主機地址"
protected-mode no
port 6379
maxmemory 10gb
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile "/redis/6379/data/redis_6379.pid"
loglevel notice
logfile "/redis/6379/log/redis_6379.log"
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump- "主機地址"-6379.rdb"
dir "redis/6379/data"
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
replica-priority 100
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
appendonly no
appendfilename "appendonly- "主機地址"-6379.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 80
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 256
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
stream-node-max-bytes 4096
stream-node-max-entries 100
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 2gb 256mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
dynamic-hz yes
aof-rewrite-incremental-fsync yes
rdb-save-incremental-fsync yes
cluster-enabled yes
cluster-node-timeout 15000
cluster-config-file "/redis/6379/data/nodes-6379.conf"
requirepass "集群密碼"
3.Flink將數(shù)據(jù)結(jié)果寫入到Redis集群時的異常
這里分享一個關(guān)于一次生產(chǎn)環(huán)境上線所遇到的問題请唱，先看異常信息如下：
這個錯誤信息很常見涎永，網(wǎng)上80-90%的人都指出了很有可能是臟數(shù)據(jù)導(dǎo)致的略贮。
在測試的過程中希坚，我們發(fā)現(xiàn)程序一開始會正常運行栅哀，直到遇到window窗口輸出執(zhí)行的時候就會拋出這個異常，從報錯信息上我們找到了那個JedisClusterPipeline類竿秆，發(fā)現(xiàn)是獲取jedis對象的時候拋出的 NullPointerExeception,問題追蹤到這就無從下手了规求，找不到原因所在了 。后來我們懷疑redis的連接池是不是定義的太小了 導(dǎo)致的獲取連接的時候出了問題呢佑女？
然而多次調(diào)整后记靡，問題依舊存在？后來請教了公司架構(gòu)部Redis 大佬珊豹，大佬連接上redis集群查看了一下Redis 的健康狀況（指令：redis-cli -h ip -p 9379 -a password cluster info）簸呈，發(fā)現(xiàn)Redis集群中master和slave副本之間的通訊是 disconnect的狀態(tài)榕订？ 顯然這個redis集群是有問題的 店茶，當(dāng)時我們?nèi)y試Redis集群的時候，只是手動啟動了一個 redis_cli.sh ,查看是否能連接成功劫恒，以此作為判斷Redis集群是否健康的依據(jù)贩幻。很顯然這樣方式是不能說明redis集群的健康的，導(dǎo)致我們浪費了大量的時間两嘴。
總結(jié)：
判斷Redis 集群是否健康丛楚，不能單單是通過指令客戶端的存儲和查詢來判斷。
redis 連接異常時也有可能出現(xiàn) 異常：Could not forward element to next operator
