中文字幕在线观看,亚洲а∨天堂久久精品9966,亚洲成a人片在线观看你懂的,亚洲av成人片无码网站,亚洲国产精品无码久久久五月天

這些年,我們一起追過(guò)的緩存數(shù)據(jù)庫(kù)

2020-12-04    來(lái)源:raincent

容器云強(qiáng)勢(shì)上線!快速搭建集群,上萬(wàn)Linux鏡像隨意使用

李曉峰

人生不過(guò)如此,且行且珍惜。自己永遠(yuǎn)是自己的主角,不要總在別人的戲劇里充當(dāng)著配角。

我以林語(yǔ)堂的《人生不過(guò)如此》中一句話來(lái)開(kāi)篇。

背景

在互聯(lián)網(wǎng)高速發(fā)展、快速演化的時(shí)代,想必在你的系統(tǒng)架構(gòu)設(shè)計(jì)中,緩存服務(wù)是不是已經(jīng)成為必不可少的一層,豐富的數(shù)據(jù)結(jié)構(gòu)、高性能的讀寫(xiě)、簡(jiǎn)單的協(xié)議,讓緩存數(shù)據(jù)庫(kù)很好的承擔(dān)起關(guān)系型數(shù)據(jù)庫(kù)的上層。暢途網(wǎng)為了解決節(jié)假日或高峰期的車(chē)次查詢(xún)、搶票等大數(shù)據(jù)量的訪問(wèn)請(qǐng)求,很早以前就引進(jìn)了 Redis,來(lái)作為數(shù)據(jù)庫(kù)的上游緩存層,緩解底層數(shù)據(jù)庫(kù)的讀寫(xiě)壓力。

REDIS HA 架構(gòu)

世界上唯一可以不勞而獲的就是貧窮,唯一可以無(wú)中生有的是夢(mèng)想。沒(méi)有哪件事,不動(dòng)手就可以實(shí)現(xiàn)。世界雖然殘酷,但只要你愿意走,總會(huì)有路;看不到美好,是因?yàn)槟銢](méi)有堅(jiān)持走下去。人生貴在行動(dòng),遲疑不決時(shí),不妨先邁出小小一步。前進(jìn)不必遺憾,若是美好,叫做精彩;若是糟糕,叫做經(jīng)歷。**——林語(yǔ)堂《人生不過(guò)如此》

2014 年 10 月,為了避免單點(diǎn)故障,我們嘗試在生產(chǎn)環(huán)境的 Redis 主從架構(gòu)中,引入了 Redis Sentinel,實(shí)現(xiàn)了 Redis 服務(wù)的 failover。當(dāng) Redis-Master 主機(jī)異常宕機(jī)或 Redis-Master 服務(wù)異常崩潰時(shí),原有的 Redis-Slave 自動(dòng)升級(jí)為 master 角色,當(dāng)原有 Redis-Master 恢復(fù)后,自動(dòng)恢復(fù)為 slave 角色。

由于 Redis Sentinel 只能做到 Redis 服務(wù)級(jí)別的切換,無(wú)法做到 IP 地址的切換,無(wú)法完全滿(mǎn)足現(xiàn)網(wǎng)系統(tǒng)架構(gòu)的需要,我們又嘗試在 HA 架構(gòu)中加入了負(fù)載均衡器設(shè)備,引用了浮動(dòng) IP,所有應(yīng)用程序訪問(wèn)浮動(dòng) IP,IP 地址的切換操作由負(fù)載均衡器設(shè)備來(lái)實(shí)現(xiàn)。

 

 

Redis Sentinel 配置文件

vi /appl/redis/etc/sentinel.conf
# Redis-ha redis-sent-0-17 redis-sent-0-18
port 26379
dir /appl/redis/database
logfile /appl/redis/log/sentinel.log
sentinel monitor redis-sent-0-17 172.19.0.17 6379 3
sentinel down-after-milliseconds redis-sent-0-17 20000
sentinel failover-timeout redis-sent-0-17 60000
sentinel can-failover redis-sent-0-17 yes
sentinel parallel-syncs redis-sent-0-17 1

測(cè)試小結(jié):

主 Redis 服務(wù)器:redis-sent-0-17

從 Redis 服務(wù)器:redis-sent-0-18

域名:redis-sent.cache.changtu.pvt

重啟 redis-sent-0-17 節(jié)點(diǎn),60 秒后,redis-sent-0-18 節(jié)點(diǎn)成為 master,用戶(hù)訪問(wèn) redis-sent.cache.changtu.pvt 域名 redis 服務(wù)恢復(fù)正常,2 分鐘后,redis-sent-0-17 節(jié)點(diǎn)重啟完成,自動(dòng)成為 slave;

重啟 redis-sent-0-18 節(jié)點(diǎn),60 秒后,redis-sent-0-17 節(jié)點(diǎn)成為 master,用戶(hù)訪問(wèn) redis-sent.cache.changtu.pvt 域名 redis 服務(wù)恢復(fù)正常,2 分鐘后,redis-sent-0-18 節(jié)點(diǎn)重啟完成,自動(dòng)成為 slave。

對(duì)應(yīng)用程序的要求

緩存應(yīng)用服務(wù)統(tǒng)一通過(guò)域名訪問(wèn)。

緩存應(yīng)用服務(wù)對(duì) Redis 域名的訪問(wèn)有斷點(diǎn)重連的功能。

2015 年新增 2 臺(tái) Redis Sentinel 服務(wù)器,負(fù)責(zé)平臺(tái)所有 Redis 服務(wù)器集群管理。并對(duì)平臺(tái)現(xiàn)有 Redis 服務(wù)進(jìn)行改造,逐步升級(jí)為 Redis HA 架構(gòu)。

CODIS 分布式集群

你可以一輩子不登山,但你心中一定要有座山。它使你總往高處爬,它使你總有個(gè)奮斗的方向,它使你任何一刻抬起頭,都能看到自己的希望。——林語(yǔ)堂《人生不過(guò)如此》

隨著暢途網(wǎng)業(yè)務(wù)量上漲,數(shù)據(jù)量猛增,單點(diǎn)的 Redis 容量受限于服務(wù)器的內(nèi)存,Redis 主從架構(gòu)已經(jīng)力不從心了。在業(yè)務(wù)系統(tǒng)對(duì)性能要求逐漸提高情況下,我們更希望將數(shù)據(jù)能存在內(nèi)存中,本地持久化,而不希望寫(xiě)入數(shù)據(jù)庫(kù)中。雖然當(dāng)時(shí)用 SSD 將內(nèi)存換成磁盤(pán),以獲取更大的容量,但是我們更想如何將 redis 變成一個(gè)可以水平擴(kuò)展的分布式緩存服務(wù)?

在 Codis 發(fā)布之前,業(yè)界只有 Twemproxy,Twemproxy 本身是一個(gè)靜態(tài)的分布式 Redis 方案,進(jìn)行擴(kuò)容、縮容對(duì)運(yùn)維要求非常高,而且很難做到平滑的擴(kuò)縮容。Codis 的目標(biāo)就是盡量兼容 Twemproxy,并且加上數(shù)據(jù)遷移的功能以實(shí)現(xiàn)擴(kuò)容和縮容,最終替換 Twemproxy。本文省略了對(duì) Twemproxy 的介紹。

REDIS-CLUSTER

與 Codis 同時(shí)期發(fā)布的官方 redis-cluster,采用 P2P 的模式,完全去中心化架構(gòu), 其實(shí)我們花了大精力研究測(cè)試過(guò),由于當(dāng)時(shí)對(duì) failover 判斷方式提出懷疑,高耦合的模塊設(shè)計(jì)思想、客戶(hù)端問(wèn)題、不太友好的維護(hù)等方面, 我司目前沒(méi)有投入生產(chǎn),沒(méi)有了實(shí)際的生產(chǎn)維護(hù)經(jīng)驗(yàn),我先不發(fā)表看法。抱拳,我知道在緩存數(shù)據(jù)庫(kù)里最不應(yīng)該缺少的就是 Redis-cluster 了,以后有機(jī)會(huì)單獨(dú)介紹吧!

 

 

容我感嘆一下,別指望所有的人都能懂你,因?yàn)樘}卜白菜,各有所愛(ài)。你做了蘿卜,自然就做不成青菜。

好了,回歸正題,先簡(jiǎn)單介紹一下 Codis,由豌豆莢于 2014 年 11 月開(kāi)源,基于 Go 和 C 開(kāi)發(fā),引用作者的一段原話, Codis 采用一層無(wú)狀態(tài)的 proxy 層,將分布式邏輯寫(xiě)在 proxy 上,底層的存儲(chǔ)引擎是 Redis,數(shù)據(jù)的分布狀態(tài)存儲(chǔ)于 zookeeper(etcd) 中,底層的數(shù)據(jù)存儲(chǔ)變成了可插拔的部件。各個(gè)部件是可以動(dòng)態(tài)水平擴(kuò)展的,尤其無(wú)狀態(tài)的 proxy 對(duì)于動(dòng)態(tài)的負(fù)載均衡,對(duì)業(yè)務(wù)而言完全是透明的。*

 

 

核心組件說(shuō)明

1. ZooKeeper:

用來(lái)存放數(shù)據(jù)路由表和 Codis-proxy 節(jié)點(diǎn)的元信息,Codis-config 發(fā)起的命令都會(huì)通過(guò) ZooKeeper 同步到各個(gè)存活的 Codis-proxy 中。

2. Codis-Proxy :

是客戶(hù)端連接的 Redis 代理服務(wù),本身是沒(méi)狀態(tài)的,Codis-proxy 實(shí)現(xiàn)了 Redis 協(xié)議,對(duì)于一個(gè)業(yè)務(wù)來(lái)說(shuō),可以部署多個(gè) Codis-proxy, 提供連接集群 Redis 服務(wù)的入口。

3. Codis-Config :

是 Codis 的集成管理工具,支持添加 / 刪除 Redis 節(jié)點(diǎn)、添加 / 刪除 Proxy 節(jié)點(diǎn)、以及發(fā)起數(shù)據(jù)遷移等操作,Codis-config 還自帶了 http server,會(huì)啟動(dòng) dashboard,用戶(hù)可以在 WEB 上監(jiān)控 Codis 集群的狀態(tài)。

4. Codis-Server:

是 Codis 項(xiàng)目維護(hù)的一個(gè) Redis 分支,基于 redis-2.8.21 分支開(kāi)發(fā),增加了額外的數(shù)據(jù)結(jié)構(gòu),以支持 slot 有關(guān)的操作以及數(shù)據(jù)遷移指令。

5.Pre-Sharding 技術(shù)

Codis 采用 Pre-Sharding 的技術(shù)來(lái)實(shí)現(xiàn)數(shù)據(jù)的分片, 默認(rèn)分成 1024 個(gè) slots (0-1023), 對(duì)于每個(gè) key 來(lái)說(shuō), 通過(guò)以下公式確定所屬的 Slot Id : SlotId = crc32(key) % 1024,每一個(gè) slot 都會(huì)有一個(gè)特定的 server group id 來(lái)表示這個(gè) slot 的數(shù)據(jù)由哪個(gè) server group 來(lái)提供。

在 2016 年 6 月左右,我們引進(jìn)了 Codis(當(dāng)時(shí)版本是 3.0,并沒(méi)有 Redis-Sentinel、Codis-fe 等組件,1 年后,才升級(jí)到 3.2 的,文章主要以 3.0 版本為背景),首先介紹一下基礎(chǔ)環(huán)境。

192.168.0.** codis-server1
192.168.0.** codis-server2
192.168.0.** codis-server3

192.168.0.** codis-ha1 (zookeeper-3)
192.168.0.** codis-ha2 (zookeeper-2)
192.168.0.** codis-ha3 (zookeeper-1)

系統(tǒng)架構(gòu)

在公司硬件資源有限條件下,我們計(jì)劃用 6 臺(tái)服務(wù)器部署 Codis,簡(jiǎn)單分了兩層,Codis-Proxy 層和 Codis-Server 層。

Codis-Proxy 層用了三臺(tái)配置相對(duì)較低服務(wù)器,部署了 ZooKeeper、Codis-Proxy、Keepalived、LVS 等 ,3 個(gè)節(jié)點(diǎn)都做了負(fù)載均衡。

Codis-Server 層用來(lái)三臺(tái)配置相對(duì)較高的服務(wù)器,并用 SSD,3 個(gè) Codis-group,每個(gè) group 有一主一從,交叉部署,每個(gè)主從分配 30G 內(nèi)存。

maxclients 30000
maxmemory 30gb

 

 

 

我們分別通過(guò) jredis 編寫(xiě)測(cè)試程序和使用 redis-benchmark 工具模擬壓力測(cè)試(請(qǐng)求量:1000 萬(wàn)~1 億,并發(fā)數(shù):1000~50000,長(zhǎng)度:固定 / 可變):

在性能方面:基本上能達(dá)到我們的預(yù)期,理想情況 Codis 性能值能達(dá)到 50~60K OP/S,各個(gè) codis-group 中 master-slave 實(shí)例數(shù)據(jù)能實(shí)時(shí)同步,詳情可以參考《Codis 高可用集群性能測(cè)試報(bào)告 _20160315》。

數(shù)據(jù)一致性問(wèn)題:一方面,Codis 的 HA 并不能保證數(shù)據(jù)完全不丟失,由于 M-S 是異步復(fù)制,當(dāng) master 節(jié)點(diǎn)異常或崩潰,將 slave 切換成 master 后,剛剛沒(méi)來(lái)得及同步的數(shù)據(jù)就會(huì)丟失。另一方面,Codis 支持的 mget/mset 命令是無(wú)法保證單點(diǎn)時(shí)的原子語(yǔ)義的,如果 mset 指定 KEY 分布在不同 slot 上,從而導(dǎo)致 KEY 在不同機(jī)器上,造成要不一起成功,不要一起失敗。所以對(duì)于分布式事務(wù)的問(wèn)題,這是一個(gè)痛點(diǎn)。在實(shí)際場(chǎng)景中,也有人使用了 lua 腳本以擴(kuò)展 Redis 的功能,雖然 Codis 支持,但是并不保證你的腳本操作的數(shù)據(jù)是否在正確的節(jié)點(diǎn)執(zhí)行,僅僅起到一個(gè)轉(zhuǎn)發(fā)功能。如果你并不能保證 lua 操作的 KEY 是否在同一個(gè)機(jī)器上,Codis 只能將這個(gè)腳本分配到參數(shù)列表中的第一個(gè) key 的機(jī)器上執(zhí)行。

不支持命令列表,參考

https://github.com/CodisLabs/codis/blob/release3.2/doc/unsupported_cmds.md

Redis 修改部分(增加若干指令),參考

https://github.com/CodisLabs/codis/blob/release3.2/doc/redis_change_zh.md

倔強(qiáng)的青銅

于是組織研發(fā)同事進(jìn)行多次分析討論,并提出了對(duì)緩存服務(wù)進(jìn)行接口改造,經(jīng)過(guò) 2 個(gè)多月的辛勞,取得了很大進(jìn)展,讓我們 Codis 項(xiàng)目順利上線邁開(kāi)了重要一步,打斷一下,容我在此特別感謝一下同事王慧,在他的主導(dǎo)下,完成公司絕大部分緩存服務(wù)接口改造工作。

幾點(diǎn)改造思路

1. 緩存服務(wù)分類(lèi)。

針對(duì)業(yè)務(wù)緩存服務(wù)不容許數(shù)據(jù)丟失,在現(xiàn)有的邏輯中,Codis 和數(shù)據(jù)庫(kù)都會(huì)保留,優(yōu)先從 Codis 讀取,如讀取不到時(shí),會(huì)從后端數(shù)據(jù)庫(kù)里讀取。

針對(duì)車(chē)次、合作方緩存服務(wù),由于數(shù)據(jù)量大,拉取頻率高的數(shù)據(jù),只會(huì)從 Codis 里讀取。

2. 對(duì)緩存服務(wù)進(jìn)行接口改造,新增基礎(chǔ)緩存服務(wù)層,將生產(chǎn)的 Redis/Codis 相關(guān)的服務(wù)納入基礎(chǔ)緩存服務(wù)進(jìn)行統(tǒng)一管理。

 

 

制定一套標(biāo)準(zhǔn) KEY 命名、管理規(guī)范,包括數(shù)據(jù)類(lèi)型的選擇、長(zhǎng)度、過(guò)期時(shí)間等。我們會(huì)統(tǒng)一在后臺(tái)管理系統(tǒng)公示,限定新數(shù)據(jù)的規(guī)則,限制一切不合規(guī)范的行為。

在基礎(chǔ)緩存服務(wù)層,對(duì)部分 Codis 不支持的命令進(jìn)行改寫(xiě),規(guī)范 Redis/Codis 日常操作。

統(tǒng)計(jì)熱點(diǎn)數(shù)據(jù),維護(hù)熱點(diǎn)數(shù)據(jù),在基礎(chǔ)緩存服務(wù)層上假設(shè)二級(jí)緩存,作為熱點(diǎn)數(shù)據(jù)的快速通道。

3.SLOT 的分配

哈希算法

Codis 采用 Pre-sharding 的技術(shù)來(lái)實(shí)現(xiàn)數(shù)據(jù)的分片, 默認(rèn)分成 1024 個(gè) slots (0-1023), 對(duì)于每個(gè) key 來(lái)說(shuō), 通過(guò)以下公式確定所屬的 Slot Id : SlotId = crc32(key) % 1024。例如 pub_cty_ct018 根據(jù)算法得出的值是 997。

 

 

key 值重定向分配

比如你有一個(gè)腳本是操作某個(gè)用戶(hù)的多個(gè)信息,如 uid1age,uid1sex,uid1name 形如此類(lèi)的 key,如果你不用 hashtag 的話,這些 key 可能會(huì)分散在不同的機(jī)器上,如果使用了 hashtag(用花括號(hào)擴(kuò)住計(jì)算 hash 的區(qū)域):{uid1}age,{uid1}sex,{uid1}name,這樣就保證這些 key 分布在同一個(gè)機(jī)器上。這個(gè)是 twemproxy 引入的一個(gè)語(yǔ)法,我們這邊也支持了。

以 pub_cty 為例,通過(guò) crc32hash 算法得出,key 存放在 237 slot 中,類(lèi)似測(cè)試了{(lán)pub_cty}_ct01,{pub_cty}_ct02…{pub_cty}_ctnn 都存放在 237 slot 中。第一,有了 hashtag 算法支持,我們可以對(duì)特定需求的 key 做一些特需的規(guī)劃,將這些特殊的 key 有序的存放在 codis slot 中,保證 mget/mset, 以及 lua 腳本正常執(zhí)行。我們目前大概管理 200 多個(gè) redis 鍵,統(tǒng)一鎖定到一個(gè) codis-server(slot)中。第二,在某些極端情況(不希望發(fā)生),如某 codis-group 中的 master 異;虮罎r(shí),我們從程序設(shè)計(jì)角度,盡可能對(duì)出現(xiàn)的無(wú)法進(jìn)行操作 KEY 的行為做一些 " 某種意義上 " 保護(hù)。譬如,當(dāng)某 codis-group 的 maser 宕機(jī)時(shí),對(duì) codis 進(jìn)行寫(xiě)操作,如果對(duì)應(yīng)的 key 落到宕機(jī)的主機(jī)上,會(huì)得到異;蛘咤e(cuò)誤,可以通過(guò)捕獲異常信息,將異常的 key 通過(guò)改變 key 名的規(guī)則將其存放到其他 codis-group 上。同理,如果是讀取宕機(jī)主機(jī)上的 key 數(shù)據(jù)時(shí),將其引導(dǎo)到調(diào)整后的 key 上,在一定程度上保障 codis 的完整性(不保障數(shù)據(jù)不丟失,只保證業(yè)務(wù)系統(tǒng)操作緩存數(shù)據(jù)完整性)。

有點(diǎn)意思的整改在長(zhǎng)達(dá)幾年的迭代演變過(guò)程中,維護(hù)團(tuán)隊(duì)推動(dòng)多次緩存服務(wù)架構(gòu)的升級(jí)與優(yōu)化,緩存服務(wù)逐漸完善和穩(wěn)定。 記下了一些“有點(diǎn)意思”的整改,提供大家參考。

熱點(diǎn)數(shù)據(jù)

統(tǒng)計(jì)緩存熱點(diǎn)數(shù)據(jù),在基礎(chǔ)緩存服務(wù)層上假設(shè)二級(jí)緩存,作為熱點(diǎn)數(shù)據(jù)的快速通道,具備可動(dòng)態(tài)獲取,最快訪問(wèn),少變化的特點(diǎn) 。

根據(jù)緩存服務(wù)各主、子鍵關(guān)系,使用 index_{主鍵}的方式來(lái)作為管理主子鍵關(guān)系的 SortedSet 集合,統(tǒng)計(jì)數(shù)據(jù)的使用頻率,抽取 Top100 的數(shù)據(jù),作為熱點(diǎn)數(shù)據(jù)。對(duì)這批數(shù)據(jù)進(jìn)行分析,結(jié)合數(shù)據(jù)的改動(dòng)頻率,制定這批數(shù)據(jù)緩存在內(nèi)存中的時(shí)長(zhǎng)。

 

 

二級(jí)緩存設(shè)計(jì)

緩存數(shù)據(jù)列表生成與維護(hù)

內(nèi)存緩存數(shù)據(jù)的 key 列表由緩存服務(wù)生成和維護(hù),Key 列表包括后臺(tái)手動(dòng)配置(如,10 個(gè))和系統(tǒng)根據(jù)使用熱度生成(如,20 個(gè))共同組成,其中 cache-manager 的 jar 包只負(fù)責(zé)對(duì)該數(shù)據(jù)使用,通過(guò)定時(shí)任務(wù)獲取 codis 中的前 20 位和后臺(tái)手動(dòng)配置的相關(guān)數(shù)據(jù),期間要保證獲取到數(shù)據(jù)的有效性。

 

 

維護(hù)本地內(nèi)存中的數(shù)據(jù)

自然統(tǒng)計(jì)內(nèi)存緩存: 用 sortedSet 集合,統(tǒng)計(jì)各主鍵下的所有鍵 Get 的次數(shù),匯總成 score_{主鍵}方式的集合。利用 ZIncrby 命令統(tǒng)計(jì)對(duì)應(yīng)的子鍵的次數(shù),最終匯總每個(gè)主鍵,統(tǒng)計(jì)出 Top100 的 key,利用 zunionstore 命令將信息統(tǒng)計(jì)匯總作為內(nèi)存緩存的基礎(chǔ),此集合內(nèi)數(shù)據(jù)均從內(nèi)存中獲取。

管理類(lèi)內(nèi)存緩存: 分析和統(tǒng)計(jì)項(xiàng)目主流程的關(guān)鍵的基礎(chǔ)緩存數(shù)據(jù)保存到內(nèi)存中, 保障對(duì)應(yīng)區(qū)域的數(shù)據(jù)獲取與緩存時(shí)間,在離開(kāi)數(shù)據(jù)源后能夠最大程度的展現(xiàn)暢途網(wǎng)的功能。

在發(fā)生手動(dòng)更新時(shí),對(duì)內(nèi)存中對(duì)應(yīng)的主鍵進(jìn)行更新

在發(fā)生更新時(shí),由后臺(tái)發(fā)起,在緩存服務(wù)向 codis 中置入標(biāo)志位,各客戶(hù)端在定時(shí)任務(wù)中獲取標(biāo)志位,如果標(biāo)志位(cache_memory_update_flag)為 Y,則清空內(nèi)存和 Key 規(guī)則表,等到下一個(gè)更新周期來(lái)臨重新獲取數(shù)據(jù)。

總結(jié)

多年后,再回想年少時(shí)的迷茫和執(zhí)著,或許原因都記不得了。青春就是讓你張揚(yáng)的笑,也給你莫名的痛。——林語(yǔ)堂《人生不過(guò)如此》

經(jīng)過(guò)大半年的時(shí)間測(cè)試、緩存服務(wù)接口改造,在 2016 年 9 月份,趕在國(guó)慶前,我們的 Codis3.0 上線了,在車(chē)次查詢(xún)等方面,有了質(zhì)的飛越,尤其節(jié)假日或高峰期期間,平滑的擴(kuò)縮容、數(shù)據(jù)遷移、高可用等方面展示出巨大優(yōu)勢(shì)。

 

 

三個(gè) codis_proxy 節(jié)點(diǎn)的均衡情況:

ipvsadm -Ln
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 3 rr
-> 192.168.0.**:19000 Local 1 1560 7
-> 192.168.0.**:19000 Route 1 1534 5
-> 192.168.0.**:19000 Route 1 1498 1

1 年后,2018 年 8~9 月份,我們將 Codis 升級(jí)到 3.2 的,由之前 6 臺(tái)服務(wù)器,擴(kuò)展到 7 臺(tái),實(shí)際上多一臺(tái) Codis-web 節(jié)點(diǎn),獨(dú)立承擔(dān) Codis-fe、Codis-dashboard 等組件。對(duì)于 Redis-Sentinel、Codis-fe 等組件的引進(jìn),解決了運(yùn)維人員很多問(wèn)題,在此不再描述,有興趣的可以參考。

https://github.com/CodisLabs/codis/blob/3.2.2/doc/tutorial_zh.md

 

 

標(biāo)簽: 緩存數(shù)據(jù) 

版權(quán)申明:本站文章部分自網(wǎng)絡(luò),如有侵權(quán),請(qǐng)聯(lián)系:west999com@outlook.com
特別注意:本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)!
本站所提供的圖片等素材,版權(quán)歸原作者所有,如需使用,請(qǐng)與原作者聯(lián)系。

上一篇:隨機(jī)過(guò)程在數(shù)據(jù)科學(xué)和深度學(xué)習(xí)中有哪些應(yīng)用?

下一篇:Google 科學(xué)家最新整理,給新手推薦的十篇最佳數(shù)據(jù)科學(xué)文章