文档章节

唯品會大規模 Redis Cluster 的生産實踐

unibigbear
 unibigbear
发布于 2016/06/03 19:28
字数 3311
阅读 23
收藏 2

1、生産應用場景

 

1.1 業務範圍

 

        redis cluster在唯品會主要應用于後端業務,用作內存存儲服務。主要大數據實時推薦/ETL、風控、營銷三大業使用。

        cluster用于取代當前twemproxy三層架構,作爲通用的存儲架構。redis cluster可以大幅度簡化我們的存儲架構,也解決twemproxy架構無法在線擴容節點的問題。

        目前我們在線有生産幾十個cluster集群,約2千個instances,單個集群最大達到250+instances。

        這是我們的生産應用場景,主要是後端業務的存儲,目前沒有作爲cache使用的場景。

 

1.2大數據、風控、營銷系統的特征

 

         cluster 壹般數據量大, 單個cluster集群在幾十個GB到上TB級別內存存儲量。

          作爲後端應用的存儲,數據來源主要以下三種方式:

 

(1)Kafka → Redis Cluster,Storm/Spark實時

(2)Hive →  Redis Cluster,  MapReduce程序

(3)MySQL →  Redis Cluster,Java/C++程序。

 

        數據由離線/實時job生成, 讀寫請求量大, 對讀寫性能也要求高。

 

        業務高峰期請求量急劇上升,幾倍的讀寫量增加,需要多個redis實例承擔業務的讀寫壓力。

        業務需求變化快, schema變化頻繁。如果使用MySQL作爲存儲,那麽將會是頻繁的DLL變更,而且需要做online schema change。

        大促銷活動時擴容頻繁。

 

1.3、爲什麽選擇redis cluster

 

1) cluster適合我們後端生産應用場景

 

        a、在線水平擴展能力,能夠解決我們大量的擴容需求。

        b、Failover能力和高可用性。

        c、雖然cluster不保證主從數據強壹致性,但是後端業務能夠容忍failover後少量的數據丟失。

 

2) 架構簡單

 

        a、無中心架構,各個節點度等。slave節點提供數據冗余,master節點異常時提升爲master。

        b、取代twemproxy三層架構,系統複雜性降低。

        c、可以節約大量的硬件資源,我們的Lvs + Twemproxy層 使用了近上千台物理機器。

        d、少了lvs和twemproxy層,讀寫性能提升明顯。響應時間從100-200us減少到50-100us。

       e、系統瓶頸更少。lvs層網卡和pps吞吐量瓶頸;對于請求長度較大的業務,twemproxy單節點性能低。

 

        總結下,我們選擇redis cluster主要這兩點原因:簡單、擴展性。另外,我們用cluster取代twemproxy集群,三層架構實在是很令人頭疼,複雜、瓶頸多、管理不方面。

 

2、存儲架構演變

 

2.1 架構演變

 

 

      在2014年7月,爲了准備當時的814撒嬌節大促銷活動,我們把單個redis的服務遷移到twemproxy上。twemproxy在後端快速完成數據分片和擴容。爲了避免再次擴容,我們靜態分配足夠多的資源。

 

        之後,twemproxy暴露出來的系統瓶頸很多,資源使用很多,也存在壹定的浪費。我們決定用redis cluster取代這種複雜的三層架構。

 

        redis cluster GA之後,我們就開始上線使用。最初是3.0.2 版本,後面大量使用3.0.3 ,上個月開始使用3.0.7版本。

 

        下面簡單對比下兩種架構,解析下他們的優缺點。

 

2.2 Twemproxy架構

 

1)優點

 

a、sharding邏輯對開發透明,讀寫方式和單個redis壹致。

b、可以作爲cache和storage的proxy(by auto-eject)。

 

2)缺點

 

a、架構複雜,層次多。包括lvs、twemproxy、redis、sentinel和其控制層程序。

b、管理成本和硬件成本很高。

c、2 * 1Gbps 網卡的lvs機器,最大能支撐140萬pps。

d、流量高的系統,proxy節點數和redis個數接近。

e、Redis層仍然擴容能力差,預分配足夠的redis存儲節點。

 

 

        這是twemproxy的架構,客戶端直接連接最上面的lvs(LB),第二層是同構的twemproxy節點,下面的redis master節點以及熱備的slave節點,另外還有獨立的sentinel集群和切換控制程序,twemproxy先介紹到這裏。

 

2.3 Redis Cluster架構

 

1)優點

 

a、無中心架構。

b、數據按照slot存儲分布在多個redis實例上。

c、增加slave做standby數據副本,用于failover,使集群快速恢複。

d、實現故障auto failover。節點之間通過gossip協議交換狀態信息;投票機制         完成slave到master角色的提升。

e、亦可manual failover,爲升級和遷移提供可操作方案。

f、降低硬件成本和運維成本,提高系統的擴展性和可用性。

 

2)缺點

 

a、client實現複雜,驅動要求實現smart client,緩存slots mapping信息並及時      更新。

b、目前僅JedisCluster相對成熟,異常處理部分還不完善,比如常見的“max re       direct exception”。

c、客戶端的不成熟,影響應用的穩定性,提高開發難度。

d、節點會因爲某些原因發生阻塞(阻塞時間大于clutser-node-timeout),被判斷下線。這種failover是沒有必要,sentinel也存在這種切換場景。

 

cluster的架構如下:

 

 

 

        圖上只有master節點(slave略去),所有節點構成壹個完全圖,slave節點在集群中與master只有角色和功能的區別。

 

        架構演變講完了,開始講第三部分,也是大家最感興趣的壹部分.

 

3、應用最佳實踐

 

本部分包括內容如下:

 

a、redis cluster的穩定性如何?

b、存在哪些坑?

c、develop guideline & best practice

 

3.1 穩定性

 

a、不擴容時集群非常穩定。

b、擴容resharding時候,早期版本的Jedis端有時會出現“max-redirect”異常。

      分析Jedis源碼,請求重試次數達到了上限,仍然沒有請求成功。兩方面分         析:redis連接不上?還是集群節點信息不壹致?

c、存活檢測機制缺陷

     redis 存活檢測機制可能因爲master 節點上慢查詢、阻塞式命令、或者其它        的性能問題導致長時間沒有響應,這個節點會認爲處于failed狀態,並進行        切換。這種切換是沒必要的。

 

優化策略:

 

a) 默認的cluster-node-timeout爲15s,可以適當增大;

 

b) 避免使用會引起長時間阻塞的命令,比如save/flushdb等阻塞操作,或者keys pattern這種慢查詢。

 

        總體來說,redis cluster已經非常穩定了,但是要注意壹些應用中的小問題,下面是5個坑,大家注意了.

 

3.2 有哪些坑?

 

1)遷移過程中Jedis“Max Redirect”異常。

 

a、github上討論的結果是程序retry。

b、max redirt issues:https://github.com/xetorthio/jedis/issues/1238

c、retry時間應該大于failover 時間。

d、Jedis參數優化調整:增大jedis中的‘DEFAULT_MAX_REDIRECTIONS’參           數,默認值是5.

e、避免使用multi-keys操作,比如mset/mget. multi-key操作有些客戶端沒有支      持實現。

 

2)長時間阻塞引起的不必要的failover

 

a、阻塞的命令。比如save/flushall/flushdb

b、慢查詢。keys *、大key的操作、O(N)操作

c、rename危險操作:

     · rename-command FLUSHDB REDIS_FLUSHDB

     · rename-command FLUSHALL REDIS_FLUSHALL

     · rename-command KEYS REDIS_KEYS

 

3)同時支持ipv4和ipv6偵聽服務埋下的坑

 

        具體現象:redis啓動正常,節點的協議端口只有ipv6 socket創建正常。異常節點也無法加入到集群中,也無法獲取epoch。

 

        解決方法:啓動時指定網卡ipv4地址,也可以是0.0.0.0,配置文件中添加:bind 0.0.0.0

 

        這個是在setup集群的時候發生過的壹個問題,bind 0.0.0.0雖然存在壹些安全性問題,但是是比較簡單通用的解決方法。

 

4)數據遷移速度較慢

 

· 主要使用的redis-trib.rb reshard來完成數據遷移。

· redis-3.0.6版本以前migrate操作是單個key逐壹操作。從redis-3.0.6開始,支持單次遷移多個key。

· redis集群內部最多只允許壹個slot處于遷移狀態,不能並發的遷移slots。

· redis-trib.rb reshard如果執行中斷,用redis-trib.rb fix修複集群狀態。

 

5)版本選擇/升級建議

 

· 我們已經開始使用3.0.7版本,很多3.2.0修複的bug已經backport到這個版本。

· 另外我們也開始測試3.2.0版本,內存空間優化很大。

· Tips

     · redis-trib.rb支持resharding/rebalance,分配權重。

     · redis-trib.rb支持從單個redis遷移數據到cluster集群中。

 

      後面2點不算坑把,算是不足,tips也很實用。開始分享下最佳實踐。

 

4、最佳實踐

 

4.1 應用做好容錯機制

 

· 連接或者請求異常,進行連接retry和reconnect。

· 重試時間應該大于cluster-node-time時間. 

     

       還是強調容錯,這個不是針對cluster,所有的應用設計都適用。

 

4.2 制定開發規範

 

· 慢查詢,進程cpu 100%、客戶端請求變慢,甚至超時。

· 避免産生hot-key,導致節點成爲系統的短板。

· 避免産生big-key,導致網卡打爆、慢查詢。

· TTL, 設置合理的ttl,釋放內存。避免大量key在同壹時間段過期,雖然redis已· 經做了很多優化,仍然會導致請求變慢。

· key命名規則。

· 避免使用阻塞操作,不建議使用事務。

· 開發規範,使妳們的開發按照最優的方式使用nosql。

 

4.3 優化連接池使用

 

· 主要避免server端維持大量的連接。

· 合理的連接池大小。

· 合理的心跳檢測時間。

· 快速釋放使用完的連接。

· Jedis壹個連接創建異常問題(fixed):

· https://github.com/xetorthio/jedis/issues/1252  

· 連接問題是redis開發使用中最常見的問題,connection timeout/read timeout,還有borrow connection的問題。

 

4.4 區分redis/twemproxy和cluster的使用

 

· redis建議使用pipeline和multi-keys操作,減少RTT次數,提高請求效率。

· twemproxy也支持pipeline, 支持部分的multi-key可以操作。

· redis cluster不建議使用pipeline和multi-keys操作,減少max redirect産生的場景。

· 區分redis 和 cluster的使用,壹方面是數據分片引起的;另壹方面,與client的實現支持相關。

 

4.5 幾個需要調整的參數

 

1)設置系統參數vm.overcommit_memory=1,可以避免bgsave/aofrewrite失敗。

 

2)設置timeout值大于0,可以使redis主動釋放空閑連接。

 

3)設置repl-backlog-size 64mb。默認值是1M,當寫入量很大時,backlog溢出會導致增量複制不成功。

 

4)client buffer參數調整

     client-output-buffer-limit normal 256mb 128mb 60

     client-output-buffer-limit slave  512mb  256mb 180

 

5、運維經驗總結

 

5.1 自動化管理

 

· CMDB管理所有的資源信息。

· Agent方式上報硬軟件信息。

· 標准化基礎設置。機型、OS內核參數、軟件版本。

· Puppet管理和下發標准化的配置文件、公用的任務計劃、軟件包、運維工具。

· 資源申請自助服務。

 

5.2 自動化監控

 

· zabbix作爲主要的監控數據收集工具。

· 開發實時性能dashboard,對開發提供查詢。

· 單機部署多個redis,借助于zabbix discovery。

· 開發DB響應時間監控工具Titan。

· 基本思想來源于pt-query-degest,通過分析tcp應答報文産生日志。flume agent + kafka收集,spark實時計算,hbase作爲存儲。最終得到hotquery/slowquery,request source等性能數據。

 

5.3 自動化運維

 

· 資源申請自助服務化。

· 如果申請合理,壹鍵即可完成cluster集群部署。

  能不動手的,就堅決不動手,另外,監控數據對開發開發很重要,讓他們了解自己服務性能,有時候開發會更早發現集群的壹些異常行爲,比如數據不過期這種問題,運維就講這麽多了,後面是幹貨中的幹貨,由deep同學開發的幾個實用工具。

 

5.4 redis開源工具介紹

 

 redis實時數據遷移工具

 

1)在線實時遷移

2)redis/twemproxy/cluster 異構集群之間相互遷移。

3)github:https://github.com/vipshop/redis-migrate-tool 

 

redis cluster管理工具

 

1)批量更改集群參數

2)clusterrebalance

3)很多功能,具體看github :

https://github.com/deep011/redis-cluster-tool

 

多線程版本Twemproxy

 

1)大幅度提升單個proxy的吞吐量,線程數可配置。

2)壓測情況下,20線程達到50w+qps,最優6線程達到29w。

3)完全兼容twemproxy。

4)github:

https://github.com/vipshop/twemproxies

 

在開發的中的多線redis

 

1)Github:

https://github.com/vipshop/vire

(本文为连刊,预知菜鸟的逆袭,请继续关注,直接扫描以下二维码并关注,便可查阅菜鸟逆袭全刊!加入我们,摇身一变“高富帅”“白富美”,掌握好技术,拿高薪、买房买车!走向人生巅峰!!!快来吧!!!)

 

由于上传附件及文字限制,有时部分图片、文字可能显示不了,详情请见:http://mp.weixin.qq.com/s?__biz=MzI5ODI3NzY2MA==&mid=100000731&idx=2&sn=5951fb3d54b70790240c97056c05112f#rd
欢迎大家一起交流。
扫描以下二维码,获取更多更精美文章!(扫码关注有意向不到的惊喜的哦!!)
 
关注我们微信订阅号( uniguytech100) 与服务号(uniguytech),获取更多更精美文章!
也欢迎加入【大家技术网讨论QQ群】,群号码:256175955,请备注你个人的介绍!让我们一起聊聊it的那些事!

本文转载自:http://mp.weixin.qq.com/s?__biz=MzI5ODI3NzY2MA==&mid=100000731&idx=2&sn=5951fb3d54b70790240c97056...

unibigbear
粉丝 1
博文 70
码字总数 5874
作品 0
闵行
私信 提问
(挖坑)為什麼要去折騰一個自己的信息管理系統?

一切都是從「想要一個更好的飯否搜索🔍」開始的,在實作的過程中,慢慢開始了對數據、信息管理的思考。 實做「自己的信息管理系統」以後,改變了很多以前堅信不移的看法,甚至品味。比如對...

Pope怯懦懦地
04/21
0
0
[深圳]兩年苦B Java 程式員求解脫,求安撫,求指導

去年在北京實習一年,2012年七月畢業的,從12年八月開始在深圳一家世界500強做了五個月了,技術絕對講不一定很強,但是相對和我同“級別”的實在是太強了,和我一起的同事都以為我有個三五年...

MrDing
2013/01/22
3.7K
43
為什麼 Node.js 不適合大型和商業專案?

JavaScript 和 Node.js 一直都是這幾年的話題,無論是前端還是後端,到處都可見 JavaScript,就好像爬滿了你全身上下,他們不斷地對你說道「嘿!老兄!快來用我吧!」。 為什麼 Node.js 會這...

临江仙卜算子
2018/05/25
0
0
用Charles攔截iOS APP HTTPS請求

用Charles攔截iOS APP HTTPS請求 晴耕雨讀2017-12-221 阅读 appiOShttps 實踐環境 Charles 4.2 iOS 11.2.1 安裝證書 按照Charles菜單(Help -> SSL Proxying -> Install Charles Root Certif......

晴耕雨讀
2017/12/22
0
0
香蕉派 Banana pi 里程牌: 基金会正式成立

重大的里程碑 : 2015年8月1日開始,BananaPi 的原創單位已將相關事務委託給 富昌OSS基金會來主導,目前,基金會正在配合進行改組及規劃,除了已經透過募款支援 真理大學內蒙志工團隊外,也將...

bananapi
2015/09/10
40
1

没有更多内容

加载失败,请刷新页面

加载更多

Netty源码学习(一)--导入IDEA并编译

1.从github下载最新的Netty稳定版本源码 2.解压源码文件夹 3.导入IDEA 4.跳过checkstyle和xml validate <plugin> <artifactId>maven-checkstyle-plugin</artifactId> <version>2.12.......

湖之风情
26分钟前
2
0
电商网站用户端FE

需求拆分原则 1、单个迭代不宜太大 2、需求可交付,能够形成功能闭环 3、有成本意识,遵循二八原则 4、有预期的价值体现 提炼核心需求 用户端:商品、购物车、下单、支付、订单、用户 后台管...

星闪海洋
38分钟前
1
0
Awesome Blockchain 区块链技术导航

区块链技术导航:收集整理最全面最优质的区块链(BlockChain)技术开发相关资源。 以后找不到文档资料的时候去导航站看看。 先亮个像,我长这样: 导航站内容 区块链开发所涉及的资源: 如 项目...

Tiny熊
41分钟前
1
0
聊聊我的第一篇10万+,同时反驳某些评论

元旦的时候,我立了一个Flag,今年要写一篇10万+,现在目标算是完成一半了。 终于有了一篇10万+ 知乎后台显示我的回答《如何衡量一个人的 JavaScript 水平?》的阅读量已经超过了10万,具体截...

Fundebug
48分钟前
5
0
ping的用法

ping的用法: -t ping指定的主机,直到停止。若要查看统计信息并继续操作-请键入 Control-Break; 若要停止-请键入Control-C。 -a 将地址解析成主机名。 -n count 要发送的回显请求数。 -l s...

WinkJie
49分钟前
2
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部