21中國系統(tǒng)架構(gòu)師大會專場

1、大容量redis方案-Pika陳360基礎架構(gòu)組技術經(jīng)理簡介 13年入職360 基礎架構(gòu)組 Bada Pika Zeppelin Mario, Pink, slash, floyd概要問題 分析問題 解決問題 Pika vs redisIntroduction Pika 是DBA 和 基礎架構(gòu)團隊一起設計開發(fā)的大容量redis的解決方案 完全兼容redis 協(xié)議, 用戶不需要修改任何代碼進行遷移Pika User Redis實例數(shù)量：6000+個 日量：5000+億 Pika數(shù)據(jù)數(shù)量：1000+個 日量：1000+億 覆蓋率：80%以上業(yè)務線 單份數(shù)據(jù)體積：6.8TPikaPika 的出現(xiàn)并不

2、是為了替代 Redis，而是 Redis的場景補充。Pika 力求在完全兼容 Redis 協(xié)議、繼承 Redis 便捷運維設計的前提下通過持久化Redis 在大容量場景下的問題的方式解決Redis 問題 恢復時間長 一主多從, 主從切換代價大 緩沖區(qū)寫滿問題 成本問題Redis 問題 恢復時間長 50G redis 回復時間70分鐘 同時開啟aof 和 rdbRedis 問題 一主多從, 主從切換代價大 主庫掛掉后升級從庫, 所有的從庫全部重傳數(shù)據(jù)Redis 問題 緩沖區(qū)寫滿問題 內(nèi)存是昂貴, 緩沖區(qū)一般設置2G很容易將數(shù)據(jù)堵死, 那么就會發(fā)生大量數(shù)據(jù)重傳Redis 問題 內(nèi)存太貴 線上使用的

3、redis 80% 的空間.是 64G, 96G. 只使用 如果一個redis 的實例是50G, 那么基本一臺只能運行一個redis 實例. 特別的浪費資源Redis 問題90/GB VS 2.6/GB30倍的差距問題分析 成本問題 可用性問題 同步問題 易用性問題問題分析 盡可能兼容redis 協(xié)議 使用基于磁盤的數(shù)據(jù)接口接口引擎rocksdb 實現(xiàn)多庫 添加binlog 模塊Pika 整體結(jié)構(gòu)模塊-Pink 基礎架構(gòu)團隊開發(fā)pg, http等協(xié)議.編程庫, 支持pb, redis, 抽象各種不同類型線程 DispatchThread WorkThread BGThread模塊-Pink 穩(wěn)

4、定行, 在各個項目中使用4年多 易用性 高性能模塊-Pinkclass MyPbConn : public pink:PbConn Public:MyPbConn(int fd, std:string ip_port, pink:Thread* self_thread_ptr = NULL) : pink:PbConn(fd, ip_port) res_ = dynamic_cast<:protobuf:Message*>(&message_);MyPbConn() int DealMessage() message_.ParseFromArray(rbuf_ + cur_

5、pos_ - header_len_, heade _len_);message_.set_name("hello " + message_.name(); uint32_t u =htonl( message_.ByteSize();memcpy(static_cast<void*>(wbuf_), st tic_ca t<void*>(&u), COMMAND_HEADER_LENGTH); message_.SerializeToArray(wbuf_ + COMMAND_HEADER_LENGTH, PB_MAX_MESSAGE);

6、set_is_reply(true);模塊-Pink引擎-Nemo Nemo Pika 的引擎, 基于Rocksdb 實現(xiàn). 實現(xiàn)了Hash,List, Set, Zset 等數(shù)據(jù)結(jié)構(gòu) Rocksdb 啟動只需要加載log 文件 Rocksdb 使用的本地硬盤, 對SSD 盤友好引擎-Nemo引擎-NemoHSET myhash field1"Hello" DB->Put(wop, h6myhashfield1,Hello01477671118) DB->Put(wop, Hmyhash11477671118, 6)引擎-Nemo引擎-NemoLPUSH myl

7、ist "world" DB->Put(wop, l6mylist6,57world01477671118) DB->Put(wop, Lmyhash11477671118, 6071)日志模塊-Binlog Binlog 順序?qū)懳募? 通過Index + offset 進行同步點檢查 解決了緩沖區(qū)小的問題 支持全同步 + 增量同步日志模塊-Binlog主從同步- slaveof主從同步- slaveofPika 遇到問題 秒刪 通過修改Rocksdb, 增加 version, timestamp 字段.刪除只需要修改metadata 支持億級別數(shù)據(jù)秒刪Pika

8、 遇到問題 數(shù)據(jù)compact 修改Rocksdb manual compact 策略, 支持低優(yōu)先級的 manual compact 根據(jù)機型調(diào)整rocksdb 配置, compac線程, memtable 個數(shù) 晚上定期執(zhí)行Pika 遇到問題 數(shù)據(jù)備份 需要rocksdb 和Binlog 配合Pika 運維 線上架構(gòu)LVS讀寫VIPLVS讀寫VIPLVS只讀VIPLVS讀寫VIPMasterMasterMasterSlaveSlaveSlaveSlaveSlave機房B機房A機房B主機房APika 運維 線上架構(gòu)LVS讀寫VIPLVS只讀VIPLVS讀寫VIPLVS只讀VIPMasterM

9、aster斷點續(xù)傳Slave1 提升為主庫主機房ASlave1Slave2Slave3Slave2Slave3主機房A機房B機房BPika 運維 遷移工具 Redis_to_pika 將redis數(shù)據(jù)遷移到pika，基于aof，能據(jù)（Note關閉aof重寫） Pika_to_redis+增量方式同步數(shù) 業(yè)務增長過快，pika逐漸難以支持性能，將pika遷回redis，支持增量數(shù)據(jù)同步 Ssdb_to_pika 將ssdb數(shù)據(jù)遷移到pika，目前不支持增量同步Pika 運維 案例一消息推送服務部分redis遷移到pika 遷移前： SET數(shù)據(jù)結(jié)構(gòu)為主 5套30G左右的redis主從，占用300G

10、內(nèi)存 遷移后： 1套50G左右的pika主從，占用100多G磁盤Pika 運維 案例二數(shù)據(jù)分析業(yè)務redis遷移到pika遷移前：業(yè)務數(shù)據(jù)量增長迅速，上線不到1周數(shù)據(jù)量增長到40G遷移后：1套100G+ Pika主從Pika 開發(fā)現(xiàn)狀 Pika團隊目前有2個主力開發(fā)維護，2個DBA做需求分析討論、性能測試、bug跟蹤、回歸測試。積累1700+個測試用例經(jīng)理匯總問題和用戶反饋,幫用戶問題解決和需求排期開發(fā) 一月一個小版本, 二月一個大版本Pika 開發(fā)現(xiàn)狀支持 Pika_hub 提供多機房寫入支持 支持sentinel 支持codisPika 總結(jié) 恢復時間長 一主多從, 主從切換代價大 緩沖區(qū)寫滿問題 內(nèi)存昂貴問題Pika vs redis 劣勢 由于Pika是基于內(nèi)存和文件來存放數(shù)據(jù), 所以性能肯定比Redis 低一些 優(yōu)勢 容量大 加載db速度快 備份速度快 對 性價比高度高Pika vs redis- CPU: 24 Cores, Intel(R) Xeon(R) CPU E5-2630 v2 2.6