Spark SQL 在極光的建設(shè)實(shí)踐
Locust性能測試工具的使用
數(shù)據(jù)質(zhì)量建設(shè)實(shí)踐
百億級數(shù)據(jù)的實(shí)時存取優(yōu)化與實(shí)踐
極光clickhouse千億級數(shù)據(jù)分析實(shí)踐之路
當(dāng)前的舊系統(tǒng)中主要存儲標(biāo)簽/別名與注冊ID的相互映射關(guān)系, 使用Key-Value結(jié)構(gòu)存儲, 考慮到一個注冊ID可能有多個標(biāo)簽, 同時一個標(biāo)簽也存在多個不同的注冊ID, 這部分?jǐn)?shù)據(jù)使用Redis存儲中的Set數(shù)據(jù)結(jié)構(gòu); 而一個注冊ID只有一個別名, 同時一個別名也存在多個不同的注冊ID, 這部分?jǐn)?shù)據(jù)使用String/Set數(shù)據(jù)結(jié)構(gòu)。由于此部分?jǐn)?shù)據(jù)量過大, 考慮到存儲成本, Redis使用的單Master模式, 而最終數(shù)據(jù)的落地使用Pika存儲(一種類Redis的文件存儲)。Pika與Redis中的數(shù)據(jù)由業(yè)務(wù)方保持一致, Redis正?？捎脮r, 讀Redis; 當(dāng)Redis不可用時讀Pika, Redis恢復(fù)可用后, 從Pika恢復(fù)數(shù)據(jù)到Redis, 重新讀Redis。舊系統(tǒng)的存儲架構(gòu)如下:
從上面的架構(gòu)圖可以看到, Redis/Pika均采用主從模式, 其中Redis只有Master, 配置管理模塊用來維護(hù)Redis/Pika集群的主從關(guān)系, 配置寫入ZooKeeper中, 業(yè)務(wù)模塊從ZooKeeper中讀取配置, 不做配置變更。所有的配置變更由配置管理模塊負(fù)責(zé). 當(dāng)需要遷移, 擴(kuò)容, 縮容的時候, 必須通過配置管理模塊操作。這個舊系統(tǒng)的優(yōu)缺點(diǎn)如下:
優(yōu)點(diǎn):
缺點(diǎn):
舊系統(tǒng)缺點(diǎn)分析
考慮到舊系統(tǒng)存在以上的缺點(diǎn), 主要從以下幾個方向解決:
分析: 舊系統(tǒng)中Redis與Pika數(shù)據(jù)不一致主要是Pika早期版本Set數(shù)據(jù)結(jié)構(gòu)操作效率不高, String數(shù)據(jù)結(jié)構(gòu)操作的效率比較高, 但獲取標(biāo)簽/別名下的所有注冊ID時需要遍歷所有Pika實(shí)例, 這個操作非常耗時, 考慮到最新版本Pika已經(jīng)優(yōu)化Set數(shù)據(jù)結(jié)構(gòu), 提高了Set數(shù)據(jù)結(jié)構(gòu)的讀寫性能, 應(yīng)該保持Redis與Pika數(shù)據(jù)結(jié)構(gòu)的一致性。
分析: Redis單Master模式風(fēng)險極大。需要優(yōu)化為主從模式, 這樣能夠在某個Master故障時能夠進(jìn)行主從切換, 不再從Pika中恢復(fù)數(shù)據(jù), 減少故障恢復(fù)時間, 減少數(shù)據(jù)不一致的可能性。
分析: 這個系統(tǒng)恢復(fù)時間過長是由于Redis是單Master模式, 且沒有持久化, 需要把Redis優(yōu)化成主從模式且必須開啟持久化, 從而幾乎不需要從Pika恢復(fù)數(shù)據(jù)了, 除非Redis的主從實(shí)例全部同時不可用。不需要從Pika恢復(fù)數(shù)據(jù)后, 那么Redis中的數(shù)據(jù)在Redis主從實(shí)例發(fā)生故障時, 就和Pika中的數(shù)據(jù)一致了。
分析: 配置管理模塊手動干預(yù)操作過多, 非常容易出錯, 這部分應(yīng)盡量減少手動操作, 考慮引入Redis哨兵, 能夠替換大部分的手動操作步驟。
分析: 通過對Redis中的各個不同維度數(shù)據(jù)進(jìn)行數(shù)據(jù)量和訪問量以及訪問來源分析(如下圖)。外部請求量(估算) 這欄的數(shù)據(jù)反應(yīng)了各個不同Key的單位時間內(nèi)訪問量情況。
Redis的存儲數(shù)據(jù)主要分為標(biāo)簽/別名到注冊ID和注冊ID到標(biāo)簽/別名兩部分?jǐn)?shù)據(jù). 通過分析得知, 標(biāo)簽/別名到注冊ID的數(shù)據(jù)約占1/3左右的存儲空間, 訪問量占到80%; 注冊ID到標(biāo)簽/別名的數(shù)據(jù)約占2/3左右的存儲空間, 訪問量占到20%。可以看到, 紅色數(shù)字部分為訪問的Pika,黑色部分訪問的Redis, 3.7%這項(xiàng)的數(shù)據(jù)可以優(yōu)化成訪問Redis,那么可以得出結(jié)論, 紅色的數(shù)據(jù)在Redis中是永遠(yuǎn)訪問不到的。所以可以考慮將Redis中注冊ID到標(biāo)簽/別名這部分?jǐn)?shù)據(jù)刪掉, 訪問此部分?jǐn)?shù)據(jù)請求到Pika, 能夠節(jié)省約2/3的存儲空間, 同時還能保證整個系統(tǒng)的讀性能。
分析: 這部分主要由于其中一項(xiàng)服務(wù)為非高可用, 而且整個系統(tǒng)架構(gòu)的復(fù)雜性較高, 以及數(shù)據(jù)一致性相對比較難保證, 導(dǎo)致故障恢復(fù)時間長, 考慮應(yīng)將所有服務(wù)均優(yōu)化為高可用, 同時簡化整個系統(tǒng)的架構(gòu)。
分析: 配置手動管理風(fēng)險也非常大, Pika主從關(guān)系通過配置文件手動指定, 配錯后將導(dǎo)致數(shù)據(jù)錯亂, 產(chǎn)生臟數(shù)據(jù).需要使用Redis哨兵模式, 用哨兵管理Redis/Pika, 配置管理模塊不再直接管理所有Redis/Pika節(jié)點(diǎn), 而是通過哨兵管理, 同時再發(fā)生主從切換或者節(jié)點(diǎn)故障時通知配置管理模塊, 自動更新配置到Zookeeper中,遷移/擴(kuò)容/縮容時也基本不用手動干預(yù)。
分析: 這部分手動操作, 應(yīng)該優(yōu)化為自動觸發(fā),自動完成遷移, 減少人工干預(yù), 節(jié)省人力成本。
Redis哨兵模式
Redis哨兵為Redis/Pika提供了高可用性, 可以在無需人工干預(yù)的情況下抵抗某些類型的故障, 還支持監(jiān)視, 通知, 自動故障轉(zhuǎn)移, 配置管理等功能:
同時, 哨兵還具有分布式性質(zhì), 哨兵本身被設(shè)計為可以多個哨兵進(jìn)程協(xié)同工作, 當(dāng)多個哨兵就給定的主機(jī)不再可用這一事實(shí)達(dá)成共識時, 將執(zhí)行故障檢測, 這降低了誤報的可能性。 即使不是所有的哨兵進(jìn)程都在工作, 哨兵仍能正常工作, 從而使系統(tǒng)能夠應(yīng)對故障。
Redis哨兵+主從模式能夠在Redis/Pika發(fā)生故障時及時反饋實(shí)例的健康狀態(tài), 并在必要時進(jìn)行自動主從切換, 同時會通過Redis的sub/pub機(jī)制通知到訂閱此消息的應(yīng)用程序。從而應(yīng)用程序感知這個主從切換, 能夠短時間將鏈接切換到健康的實(shí)例, 保障服務(wù)的正常運(yùn)行。
沒有采用Redis的集群模式, 主要有以下幾點(diǎn)原因：
最終解決方案
綜上, 為了保證整個存儲集群的高可用, 減少故障恢復(fù)的時間, 甚至做到故障時對部分業(yè)務(wù)零影響, 我們采用了Redis哨兵+Redis/Pika主從的模式, Redis哨兵保證整個存儲集群的高可用, Redis主從用來提供查詢標(biāo)簽/別名到注冊ID的數(shù)據(jù), Pika主從用來存儲全量數(shù)據(jù)和一些注冊ID到標(biāo)簽/別名數(shù)據(jù)的查詢。需要業(yè)務(wù)保證所有Redis與Pika數(shù)據(jù)的全量同步。新方案架構(gòu)如下:
從上面架構(gòu)圖來看, 當(dāng)前Redis/Pika都是多主從模式, 同時分別由不同的多個哨兵服務(wù)監(jiān)視, 只要主從實(shí)例中任一個實(shí)例可用, 整個集群就是可用的。Redis/Pika集群內(nèi)包含多個主從實(shí)例, 由業(yè)務(wù)方根據(jù)Key計算slot值, 每個slot根據(jù)配置管理模塊指定的slot與實(shí)例映射關(guān)系。如果某個slot對應(yīng)的Redis主從實(shí)例均不可用,會查詢對應(yīng)的Pika, 這樣就保證整個系統(tǒng)讀請求的高可用。這個新方案的優(yōu)缺點(diǎn)如下:
優(yōu)點(diǎn):
缺點(diǎn):
除了通過以上架構(gòu)優(yōu)化, 本次優(yōu)化還包括以下方面:
展望
未來此系統(tǒng)還可以從以下幾個方面繼續(xù)改進(jìn)和優(yōu)化:
本次系統(tǒng)優(yōu)化在原有存儲組件的基礎(chǔ)上, 根據(jù)服務(wù)和數(shù)據(jù)的特點(diǎn), 合理優(yōu)化服務(wù)間調(diào)用方式, 優(yōu)化數(shù)據(jù)存儲的空間, 將Redis當(dāng)作緩存, 只存儲訪問量較大的數(shù)據(jù), 降低了資源使用率。Pika作為數(shù)據(jù)落地并承載訪問量較小的請求, 根據(jù)不同存儲組件的優(yōu)缺點(diǎn), 合理分配請求方式。同時將所有服務(wù)設(shè)計為高可用, 提高了系統(tǒng)可用性, 穩(wěn)定性。最后通過增加緩存等設(shè)計, 提高了高峰期的查詢QPS, 在不擴(kuò)容的前提下, 保證系統(tǒng)高峰期的響應(yīng)速度。
熱門文章
相關(guān)文章
極光官方微信公眾號
關(guān)注我們，即時獲取最新極光資訊
現(xiàn)在注冊，領(lǐng)取新人大禮包
