正文

快照應(yīng)用場景（快照應(yīng)用場景有哪些）

發(fā)布時(shí)間：2023-04-08 14:49:38 稿源：創(chuàng)意嶺閱讀： 76

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于快照應(yīng)用場景的問題，以下是小編對(duì)此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個(gè)非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對(duì)話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內(nèi)優(yōu)秀的企業(yè)，服務(wù)客戶遍布全球各地，如需了解SEO相關(guān)業(yè)務(wù)請(qǐng)撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

1、事實(shí)表分類及使用場景
2、談?wù)剅edis，memcache，mongodb的區(qū)別和具體應(yīng)用場景
3、超融合軟件解決方案可以適用哪些場景？
4、Loki 日志系統(tǒng)分布式部署實(shí)踐三 redis

快照應(yīng)用場景（快照應(yīng)用場景有哪些）

一、事實(shí)表分類及使用場景

事實(shí)表分類

一、周期快照事實(shí)表

周期快照事實(shí)表中的每行匯總了發(fā)生在某一標(biāo)準(zhǔn)周期的多個(gè)度量事件，即使周期內(nèi)沒有活動(dòng)發(fā)生，也需要插入一行0或者null的行，所以每個(gè)周期數(shù)據(jù)量比較均勻。如商店庫存信息，需要每天存儲(chǔ)每種商品的庫存剩余量，若商品很多，時(shí)間跨度增加到年，則需要很多快照。此時(shí)需要對(duì)事實(shí)表分層次，如周快照、月快照，并且可以分存儲(chǔ)的周期長短存不同的表，如近一個(gè)月，近一年分別存儲(chǔ)。周期快照事實(shí)表主要為了查看不同環(huán)節(jié)的拼勁和負(fù)面影響。

在周期快照事實(shí)表中，可加事實(shí)有時(shí)候并不能全可加，因?yàn)榇嬖谌掌诹６?，并不是所有維度都可加，所以稱為半可加事實(shí)。結(jié)合庫存例子，每天存的是當(dāng)天的存量，但是加和無意義。

適合長時(shí)間的過程

二、事務(wù)事實(shí)表

事務(wù)事實(shí)表的一行對(duì)應(yīng)空間或時(shí)間上某店的度量事件，僅當(dāng)發(fā)生事務(wù)時(shí)才增加行。記錄了進(jìn)行了什么操作，行需要存儲(chǔ)操作的編號(hào)作為維度，如進(jìn)庫編號(hào)是a，出庫編號(hào)是b。例如體現(xiàn)在埋點(diǎn)行為模型，追蹤某個(gè)流程易變的行為的事實(shí)表。

三、累計(jì)快照事實(shí)表

用于定義過程開始，結(jié)束以及期間可區(qū)分的里程碑，僅反映當(dāng)前狀態(tài)。類似用戶全流程轉(zhuǎn)換的事實(shí)，過程為用戶從活躍到放款的整體過程的事實(shí)表，可以存在多個(gè)時(shí)間戳。最適合對(duì)業(yè)務(wù)用戶開展工作流或者流水線的分析，通常包含不同里程碑的時(shí)間。一個(gè)單位一個(gè)流程作為一條數(shù)據(jù)存儲(chǔ)，作為監(jiān)控某個(gè)流程的事實(shí)表，包含了一些業(yè)務(wù)流程在其中，不適用于經(jīng)常變化的流程。

我理解事務(wù)事實(shí)表和累積快照事實(shí)表互為補(bǔ)充，流程變化不大或較為固定的可以使用累積快照事實(shí)表，而變化較頻繁的則可以用事務(wù)事實(shí)表，甚至將事務(wù)事實(shí)表和無事實(shí)事實(shí)表結(jié)合起來。

適合帶有開始和結(jié)束的短周期過程

二、談?wù)剅edis，memcache，mongodb的區(qū)別和具體應(yīng)用場景

從以下幾個(gè)維度，對(duì) redis、memcache、mongoDB 做了對(duì)比。

1、性能

都比較高，性能對(duì)我們來說應(yīng)該都不是瓶頸。

總體來講，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。

2、操作的便利性

memcache 數(shù)據(jù)結(jié)構(gòu)單一。（key-value）

redis 豐富一些，數(shù)據(jù)操作方面，redis 更好一些，較少的網(wǎng)絡(luò) IO 次數(shù)，同時(shí)還提供 list，set，

hash 等數(shù)據(jù)結(jié)構(gòu)的存儲(chǔ)。

mongodb 支持豐富的數(shù)據(jù)表達(dá)，索引，最類似關(guān)系型數(shù)據(jù)庫，支持的查詢語言非常豐富。

3、內(nèi)存空間的大小和數(shù)據(jù)量的大小

redis 在 2.0 版本后增加了自己的 VM 特性，突破物理內(nèi)存的限制；可以對(duì) key value 設(shè)置過

期時(shí)間（類似 memcache）

memcache 可以修改最大可用內(nèi)存,采用 LRU 算法。Memcached 代理軟件 magent，比如建立

10 臺(tái) 4G 的 Memcache 集群，就相當(dāng)于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b

10.1.2.3:14000 mongoDB 適合大數(shù)據(jù)量的存儲(chǔ)，依賴操作系統(tǒng) VM 做內(nèi)存管理，吃內(nèi)存也比較厲害，服務(wù)

不要和別的服務(wù)在一起。

4、可用性（單點(diǎn)問題）

對(duì)于單點(diǎn)問題，

redis，依賴客戶端來實(shí)現(xiàn)分布式讀寫；主從復(fù)制時(shí)，每次從節(jié)點(diǎn)重新連接主節(jié)點(diǎn)都要依賴整

個(gè)快照,無增量復(fù)制，因性能和效率問題，

所以單點(diǎn)問題比較復(fù)雜；不支持自動(dòng) sharding,需要依賴程序設(shè)定一致 hash 機(jī)制。

一種替代方案是，不用 redis 本身的復(fù)制機(jī)制，采用自己做主動(dòng)復(fù)制（多份存儲(chǔ)），或者改成

增量復(fù)制的方式（需要自己實(shí)現(xiàn)），一致性問題和性能的權(quán)衡

Memcache 本身沒有數(shù)據(jù)冗余機(jī)制，也沒必要；對(duì)于故障預(yù)防，采用依賴成熟的 hash 或者環(huán)

狀的算法，解決單點(diǎn)故障引起的抖動(dòng)問題。

mongoDB 支持 master-slave,replicaset（內(nèi)部采用 paxos 選舉算法，自動(dòng)故障恢復(fù)）,auto sharding 機(jī)制，對(duì)客戶端屏蔽了故障轉(zhuǎn)移和切分機(jī)制。

5、可靠性（持久化）

對(duì)于數(shù)據(jù)持久化和數(shù)據(jù)恢復(fù)，

redis 支持（快照、AOF）：依賴快照進(jìn)行持久化，aof 增強(qiáng)了可靠性的同時(shí)，對(duì)性能有所影

響

memcache 不支持，通常用在做緩存,提升性能；

MongoDB 從 1.8 版本開始采用 binlog 方式支持持久化的可靠性

6、數(shù)據(jù)一致性（事務(wù)支持）

Memcache 在并發(fā)場景下，用 cas 保證一致性redis 事務(wù)支持比較弱，只能保證事務(wù)中的每個(gè)操作連續(xù)執(zhí)行

mongoDB 不支持事務(wù)

7、數(shù)據(jù)分析

mongoDB 內(nèi)置了數(shù)據(jù)分析的功能(mapreduce),其他不支持

8、應(yīng)用場景

redis：數(shù)據(jù)量較小的更性能操作和運(yùn)算上

memcache：用于在動(dòng)態(tài)系統(tǒng)中減少數(shù)據(jù)庫負(fù)載，提升性能;做緩存，提高性能（適合讀多寫

少，對(duì)于數(shù)據(jù)量比較大，可以采用 sharding）

MongoDB:主要解決海量數(shù)據(jù)的訪問效率問題。

表格比較：

memcache redis 類型內(nèi)存數(shù)據(jù)庫內(nèi)存數(shù)據(jù)庫

數(shù)據(jù)類型在定義 value 時(shí)就要固定數(shù)據(jù)類型不需要

有字符串，鏈表，集合和有序集合

虛擬內(nèi)存不支持支持

過期策略支持支持

分布式 magent master-slave，一主一從或一主多從

存儲(chǔ)數(shù)據(jù)安全不支持使用 save 存儲(chǔ)到 dump.rdb 中

災(zāi)難恢復(fù) 不支持 append only file(aof)用于數(shù)據(jù)恢復(fù)

性能

1、類型——memcache 和 redis 都是將數(shù)據(jù)存放在內(nèi)存，所以是內(nèi)存數(shù)據(jù)庫。當(dāng)然，memcache 也可用于緩存其他東西，例如圖片等等。

2、數(shù)據(jù)類型——Memcache 在添加數(shù)據(jù)時(shí)就要指定數(shù)據(jù)的字節(jié)長度,而 redis 不需要。

3、虛擬內(nèi)存——當(dāng)物理內(nèi)存用完時(shí)，可以將一些很久沒用到的 value 交換到磁盤。

4、過期策略——memcache 在 set 時(shí)就指定，例如 set key1 0 0 8,即永不過期。Redis 可以通

過例如 expire 設(shè)定，例如 expire name 10。

5、分布式——設(shè)定 memcache 集群，利用 magent 做一主多從;redis 可以做一主多從。都可

以一主一從。

6、存儲(chǔ)數(shù)據(jù)安全——memcache 斷電就斷了，數(shù)據(jù)沒了；redis 可以定期 save 到磁盤。

7、災(zāi)難恢復(fù)——memcache 同上，redis 丟了后可以通過 aof 恢復(fù)。

Memecache 端口 11211

yum -y install memcached

yum -y install php-pecl-memcache

/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid

-d 啟動(dòng)一個(gè)守護(hù)進(jìn)程

-p 端口

-m 分配的內(nèi)存是 M

-c 最大運(yùn)行并發(fā)數(shù)-P memcache 的 pid

//0 壓縮（是否 MEMCACHE_COMPRESSED） 30 秒失效時(shí)間

//delete 5 是 timeout <?php

$memcache = new Memcache; $memcache -> connect('127.0.0.1', 11211); $memcache -> set('name','yang',0,30);

if(!$memcache->add('name','susan',0, 30)) {

//echo 'susan is exist'; }$memcache -> replace('name', 'lion', 0, 300); echo $memcache -> get('name');

//$memcache -> delete('name', 5);

printf "stats\r\n" | nc 127.0.0.1 11211

telnet localhost 11211 stats quit 退出

Redis 的配置文件端口 6379

/etc/redis.conf 啟動(dòng) Redis

redis-server /etc/redis.conf 插入一個(gè)值

redis-cli set test "phper.yang" 獲取鍵值

redis-cli get test 關(guān)閉 Redis

redis-cli shutdown 關(guān)閉所有

redis-cli -p 6379 shutdown <?php

$redis=new

Redis(); $redis->connect('127.0.0.1',6379); $redis->set('test',

'Hello World'); echo $redis->get('test'); Mongodb

apt-get install mongo mongo 可以進(jìn)入 shell 命令行

pecl install mongo Mongodb 類似 phpmyadmin 操作平臺(tái) RockMongo

三、超融合軟件解決方案可以適用哪些場景？

首先，軟件方案和一體機(jī)方案如何選擇？

快照應(yīng)用場景（快照應(yīng)用場景有哪些）

如果 IT 規(guī)模比較大，會(huì)涉及到當(dāng)下或未來使用多個(gè)服務(wù)器品牌的可以考慮購買超融合軟件產(chǎn)品自行構(gòu)建方案；
服務(wù)器用量較大，具有議價(jià)能力的，也可以考慮通過購買方案降低整體的方案成本；
對(duì)于虛擬化、硬件等運(yùn)維能力強(qiáng)的客戶可以使用軟件方案，但對(duì)于運(yùn)維能力不強(qiáng)的客戶建議一體機(jī)方案以便降低維護(hù)和服務(wù)支持的復(fù)雜度。

其次，超融合可以適用于哪些場景？

具體可以參考Gartner 在其報(bào)告《Critical Capabilities for Hyperconverged Infrastructure》。里面提到了超融合的 6 大適用場景與 11 個(gè)評(píng)估關(guān)鍵點(diǎn)。

Consolidated：以降低 TCO 為目標(biāo)的不同層級(jí) IT 設(shè)施整合的數(shù)據(jù)中心超融合項(xiàng)目。

Business-Critical：用于承載類似 ERP 等關(guān)鍵業(yè)務(wù)，并用于提升可靠性與可擴(kuò)展性的超融合相關(guān)項(xiàng)目。

Cloud：用于承載基于私有云設(shè)計(jì)的新型應(yīng)用或重新設(shè)計(jì)的核心應(yīng)用。

Edge：支持和 IoT 設(shè)備接口，并基于邊緣計(jì)算相關(guān)應(yīng)用、微服務(wù)的超融合相關(guān)項(xiàng)目。

ROBO：被遠(yuǎn)程管理的非主數(shù)據(jù)中心，亦可用于作為 IoT / 邊緣計(jì)算的橋接基礎(chǔ)架構(gòu)。

VDI：VDI 架構(gòu)可通過 LAN/WAN 的方式，通過遠(yuǎn)程顯示協(xié)議訪問，通過超融合簡化部署而受益。

以上 Gartner 定義的六大場景包含重要信息：

超融合最早被廣泛的應(yīng)用的場景以 VDI 和 ROBO 為主，即使是生產(chǎn)環(huán)境，也用于非核心生產(chǎn)系統(tǒng)，但時(shí)至今日，超融合已經(jīng)完全覆蓋了傳統(tǒng)架構(gòu)中塊存儲(chǔ)覆蓋的所有的領(lǐng)域，甚至包含企業(yè)級(jí)核心應(yīng)用。

超融合作為私有云的重要基礎(chǔ)，同樣成為超融合的一個(gè)重要應(yīng)用場景。

目前熱點(diǎn)的邊緣計(jì)算和物聯(lián)網(wǎng)領(lǐng)域，也成為超融合的一個(gè)重要應(yīng)用場景。

快照應(yīng)用場景（快照應(yīng)用場景有哪些）

四、Loki 日志系統(tǒng)分布式部署實(shí)踐三 redis

這里支持 redis 主從、哨兵、集群三種模式，我這里選擇主從即可，集群模式測試異常，沒能解決

安裝 redis 主從模式：

編寫配置文件：

安裝：

查看密碼：

連接 master：

連接 slave：

讀寫分離：

讀寫：

只讀：

錯(cuò)誤 1：

解決：

參考： https://github.com/helm/charts/issues/10666

參考： https://docs.bitnami.com/kubernetes/infrastructure/redis/administration/kernel-settings/

參考： https://github.com/helm/charts/tree/master/stable/redis/#user-content-host-kernel-settings

注意：Kubernetes 1.12+ 可以使用 securityContext.sysctls 來設(shè)置 pod 的 sysctl，而不需要 initContainer 了：

錯(cuò)誤 2：

解決：

使用 initContainer 去修改 sysctl 的方案在生產(chǎn)環(huán)境正常，這里卻報(bào)錯(cuò)了，應(yīng)該是 securityContext 或 PSP 的問題，這里沒有啟用 PSP，那就剩下 securityContext 了：

我這里嘗試寫入如下權(quán)限，最終都被修改掉了：

這里暫時(shí)沒有找到解決方案，但是發(fā)現(xiàn)雖然報(bào)錯(cuò)了，下面 sysctl 修改是生效了的，因?yàn)槿罩静辉賵?bào)錯(cuò)了

錯(cuò)誤 3：

解決：

因?yàn)?bitnami/minideb:buster 鏡像里沒有 sysctl

方法一：替換鏡像

方法二：直接安裝包，但是這個(gè)比較慢

錯(cuò)誤 4：

解決：

參考： https://github.com/docker-library/redis/issues/55

參考： https://github.com/prometheus/node_exporter/issues/703

注意：它將修改調(diào)度了容器的節(jié)點(diǎn)的內(nèi)核設(shè)置，從而影響該節(jié)點(diǎn)上運(yùn)行的其他容器。這就是為什么您需要運(yùn)行特權(quán)的 initContainer 或設(shè)置 securityContext.sysctls 的原因。

錯(cuò)誤 5：

解決：

因?yàn)閷⑺拗鳈C(jī)的 /sys 掛載到容器內(nèi)的路徑變成了 /host-sys

所以要修改路徑：

錯(cuò)誤 6：

解決：

這里暫時(shí)看不受影響

錯(cuò)誤 7：

解決：

因?yàn)?master 掛掉了

錯(cuò)誤 8：

解決：

Redis 提供兩種相對(duì)有效的備份方法：

利用 RDB 快照的持久化方式不是非?？煽?，當(dāng)運(yùn)行 Redis 的計(jì)算機(jī)停止工作、意外掉電、意外殺掉了 Redis 進(jìn)程那么最近寫入 Redis 的數(shù)據(jù)將會(huì)丟。對(duì)于某些應(yīng)用這或許不成問題，但對(duì)于持久化要求非常高的應(yīng)用場景快照方式不是理想的選擇。

利用 AOF 文件是一個(gè)替代方案，用以最大限度的持久化數(shù)據(jù)。同樣，可以通過配置文件來開閉 AOF。

打開 AOF 持久化功能后，Redis 處理完每個(gè)事件后會(huì)調(diào)用 write(2) 將變化寫入 kernel 的 buffer，如果此時(shí) write(2) 被阻塞，Redis 就不能處理下一個(gè)事件。

Linux 規(guī)定執(zhí)行 write(2) 時(shí)，如果對(duì)同一個(gè)文件正在執(zhí)行 fdatasync(2) 將 kernel buffer 寫入物理磁盤，或者有 system wide sync 在執(zhí)行，write(2) 會(huì)被 Block 住，整個(gè) Redis 被 Block 住。

如果系統(tǒng) IO 繁忙，比如有別的應(yīng)用在寫盤，或者 Redis 自己在 AOF rewrite 或 RDB snapshot(雖然此時(shí)寫入的是另一個(gè)臨時(shí)文件，雖然各自都在連續(xù)寫，但兩個(gè)文件間的切換使得磁盤磁頭的尋道時(shí)間加長），就可能導(dǎo)致 fdatasync(2) 遲遲未能完成從而 Block 住 write(2)，Block 住整個(gè) Redis。

為了更清晰的看到 fdatasync(2) 的執(zhí)行時(shí)長，可以使用下面命令跟蹤，但會(huì)影響系統(tǒng)性能：

Redis 提供了一個(gè)自救的方式，當(dāng)發(fā)現(xiàn)文件有在執(zhí)行 fdatasync(2) 時(shí)，就先不調(diào)用 write(2)，只存在 cache 里，免得被 Block。但如果已經(jīng)超過兩秒都還是這個(gè)樣子，則會(huì)硬著頭皮執(zhí)行 write(2)，即使 redis 會(huì)被 Block 住。

此時(shí)那句要命的 log 會(huì)打?。篈synchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

之后用 redis-cli INFO 可以看到 aof_delayed_fsync 的值被加 1。

因此，對(duì)于 fsync 設(shè)為 everysec 時(shí)丟失數(shù)據(jù)的可能性的最嚴(yán)謹(jǐn)說法是：

如果有 fdatasync 在長時(shí)間的執(zhí)行，此時(shí) redis 意外關(guān)閉會(huì)造成文件里不多于兩秒的數(shù)據(jù)丟失。

如果 fdatasync 運(yùn)行正常，redis 意外關(guān)閉沒有影響，只有當(dāng)操作系統(tǒng) crash 時(shí)才會(huì)造成少于 1 秒的數(shù)據(jù)丟失。

方法一：關(guān)閉 AOF

如果采用 redis 主從 + sentinel 方式的話，主節(jié)點(diǎn)掛了從節(jié)點(diǎn)會(huì)自己提升為主點(diǎn)，主節(jié)點(diǎn)恢復(fù)后全量同步一次數(shù)據(jù)就可以了，關(guān)系也不是太大

方法二：修改系統(tǒng)配置

原來是 AOF rewrite 時(shí)一直埋頭的調(diào)用 write(2)，由系統(tǒng)自己去觸發(fā) sync。默認(rèn)配置 vm.dirty_background_ratio=10，也就是占用了 10% 的可用內(nèi)存才會(huì)開始后臺(tái) flush

而我的服務(wù)器有 8G 內(nèi)存，很明顯一次 flush 太多數(shù)據(jù)會(huì)造成阻塞，所以最后果斷設(shè)置了sysctl vm.dirty_bytes=33554432(32M) 問題解決

錯(cuò)誤 9：

解決：

看著是啟動(dòng)的時(shí)候加載 AOF 文件到內(nèi)存，然后被 liveness 殺掉了

隨著命令不斷寫入 AOF，文件會(huì)越來越大，為了解決這個(gè)問題，redis 引入了 AOF 重寫機(jī)制壓縮文件。文件能縮小的原因是：

AOF 重寫可以手動(dòng)觸發(fā)和自動(dòng)觸發(fā)：

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 16mb

所以這里處理下，控制 AOF 文件大?。?/p>

注意：這里依舊沒能解決問題，文件依舊很大，而且會(huì)造成大量的磁盤 IO，最終導(dǎo)致 redis 失去響應(yīng)

徹底解決：

之后 dump.rdb 文件一直穩(wěn)定在 255M