-
让品牌有温度、有情感
专注品牌策划15年
如果 IT 规模比较大，会涉及到当下或未来使用多个服务器品牌的可以考虑购买超融合软件产品自行构建方案；
服务器用量较大，具有议价能力的，也可以考虑通过购买方案降低整体的方案成本；
对于虚拟化、硬件等运维能力强的客户可以使用软件方案，但对于运维能力不强的客户建议一体机方案以便降低维护和服务支持的复杂度。
快照应用场景（快照应用场景有哪些）
发布时间：2023-04-08 14:49:38
稿源：
创意岭 阅读：
76
大家好！今天让创意岭的小编来大家介绍下关于快照应用场景的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。
开始之前先推荐一个非常厉害的Ai人工智能工具，一键生成原创文章、方案、文案、工作计划、工作报告、论文、代码、作文、做题和对话答疑等等
只需要输入关键词，就能返回你想要的内容，越精准，写出的就越详细，有微信小程序端、在线网页版、PC客户端
创意岭作为行业内优秀的企业，服务客户遍布全球各地，如需了解SEO相关业务请拨打电话175-8598-2043，或添加微信：1454722008
本文目录:
一、事实表分类及使用场景
事实表分类
一、周期快照事实表
周期快照事实表中的每行汇总了发生在某一标准周期的多个度量事件，即使周期内没有活动发生，也需要插入一行0或者null的行，所以每个周期数据量比较均匀。如商店库存信息，需要每天存储每种商品的库存剩余量，若商品很多，时间跨度增加到年，则需要很多快照。此时需要对事实表分层次，如周快照、月快照，并且可以分存储的周期长短存不同的表，如近一个月，近一年分别存储。周期快照事实表主要为了查看不同环节的拼劲和负面影响。
在周期快照事实表中，可加事实有时候并不能全可加，因为存在日期粒度，并不是所有维度都可加，所以称为半可加事实。结合库存例子，每天存的是当天的存量，但是加和无意义。
适合长时间的过程
二、事务事实表
事务事实表的一行对应空间或时间上某店的度量事件，仅当发生事务时才增加行。记录了进行了什么操作，行需要存储操作的编号作为维度，如进库编号是a，出库编号是b。例如体现在埋点行为模型，追踪某个流程易变的行为的事实表。
三、累计快照事实表
用于定义过程开始，结束以及期间可区分的里程碑，仅反映当前状态。类似用户全流程转换的事实，过程为用户从活跃到放款的整体过程的事实表，可以存在多个时间戳。最适合对业务用户开展工作流或者流水线的分析，通常包含不同里程碑的时间。一个单位一个流程作为一条数据存储，作为监控某个流程的事实表，包含了一些业务流程在其中，不适用于经常变化的流程。
我理解事务事实表和累积快照事实表互为补充，流程变化不大或较为固定的可以使用累积快照事实表，而变化较频繁的则可以用事务事实表，甚至将事务事实表和无事实事实表结合起来。
适合带有开始和结束的短周期过程
二、谈谈redis，memcache，mongodb的区别和具体应用场景
从以下几个维度，对 redis、memcache、mongoDB 做了对比。
1、性能
都比较高，性能对我们来说应该都不是瓶颈。
总体来讲，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。
2、操作的便利性
memcache 数据结构单一。（key-value）
redis 丰富一些，数据操作方面，redis 更好一些，较少的网络 IO 次数，同时还提供 list，set，
hash 等数据结构的存储。
mongodb 支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富。
3、内存空间的大小和数据量的大小
redis 在 2.0 版本后增加了自己的 VM 特性，突破物理内存的限制；可以对 key value 设置过
期时间（类似 memcache）
memcache 可以修改最大可用内存,采用 LRU 算法。Memcached 代理软件 magent，比如建立
10 台 4G 的 Memcache 集群，就相当于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b
10.1.2.3:14000 mongoDB 适合大数据量的存储，依赖操作系统 VM 做内存管理，吃内存也比较厉害，服务
不要和别的服务在一起。
4、可用性（单点问题）
对于单点问题，
redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整
个快照,无增量复制，因性能和效率问题，
所以单点问题比较复杂；不支持自动 sharding,需要依赖程序设定一致 hash 机制。
一种替代方案是，不用 redis 本身的复制机制，采用自己做主动复制（多份存储），或者改成
增量复制的方式（需要自己实现），一致性问题和性能的权衡
Memcache 本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的 hash 或者环
状的算法，解决单点故障引起的抖动问题。
mongoDB 支持 master-slave,replicaset（内部采用 paxos 选举算法，自动故障恢复）,auto sharding 机制，对客户端屏蔽了故障转移和切分机制。
5、可靠性（持久化）
对于数据持久化和数据恢复，
redis 支持（快照、AOF）：依赖快照进行持久化，aof 增强了可靠性的同时，对性能有所影
响
memcache 不支持，通常用在做缓存,提升性能；
MongoDB 从 1.8 版本开始采用 binlog 方式支持持久化的可靠性
6、数据一致性（事务支持）
Memcache 在并发场景下，用 cas 保证一致性redis 事务支持比较弱，只能保证事务中的每个操作连续执行
mongoDB 不支持事务
7、数据分析
mongoDB 内置了数据分析的功能(mapreduce),其他不支持
8、应用场景
redis：数据量较小的更性能操作和运算上
memcache：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写
少，对于数据量比较大，可以采用 sharding）
MongoDB:主要解决海量数据的访问效率问题。
表格比较：
memcache redis 类型 内存数据库 内存数据库
数据类型 在定义 value 时就要固定数据类型 不需要
有字符串，链表，集 合和有序集合
虚拟内存 不支持 支持
过期策略 支持 支持
分布式 magent master-slave，一主一从或一主多从
存储数据安全 不支持 使用 save 存储到 dump.rdb 中
灾难恢复 不支持 append only file(aof)用于数据恢复
性能
1、类型——memcache 和 redis 都是将数据存放在内存，所以是内存数据库。当然，memcache 也可用于缓存其他东西，例如图片等等。
2、 数据类型——Memcache 在添加数据时就要指定数据的字节长度,而 redis 不需要。
3、 虚拟内存——当物理内存用完时，可以将一些很久没用到的 value 交换到磁盘。
4、 过期策略——memcache 在 set 时就指定，例如 set key1 0 0 8,即永不过期。Redis 可以通
过例如 expire 设定，例如 expire name 10。
5、 分布式——设定 memcache 集群，利用 magent 做一主多从;redis 可以做一主多从。都可
以一主一从。
6、 存储数据安全——memcache 断电就断了，数据没了；redis 可以定期 save 到磁盘。
7、 灾难恢复——memcache 同上，redis 丢了后可以通过 aof 恢复。
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 启动一个守护进程
-p 端口
-m 分配的内存是 M
-c 最大运行并发数-P memcache 的 pid
//0 压缩（是否 MEMCACHE_COMPRESSED） 30 秒失效时间
//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 启动 Redis
redis-server /etc/redis.conf 插入一个值
redis-cli set test "phper.yang" 获取键值
redis-cli get test 关闭 Redis
redis-cli shutdown 关闭所有
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 可以进入 shell 命令行
pecl install mongo Mongodb 类似 phpmyadmin 操作平台 RockMongo
三、超融合软件解决方案可以适用哪些场景？
首先，软件方案和一体机方案如何选择？
其次，超融合可以适用于哪些场景？
具体可以参考Gartner 在其报告《Critical Capabilities for Hyperconverged Infrastructure》。里面提到了超融合的 6 大适用场景与 11 个评估关键点。
Consolidated：以降低 TCO 为目标的不同层级 IT 设施整合的数据中心超融合项目。
Business-Critical：用于承载类似 ERP 等关键业务，并用于提升可靠性与可扩展性的超融合相关项目。
Cloud：用于承载基于私有云设计的新型应用或重新设计的核心应用。
Edge：支持和 IoT 设备接口，并基于边缘计算相关应用、微服务的超融合相关项目。
ROBO：被远程管理的非主数据中心，亦可用于作为 IoT / 边缘计算的桥接基础架构。
VDI：VDI 架构可通过 LAN/WAN 的方式，通过远程显示协议访问，通过超融合简化部署而受益。
以上 Gartner 定义的六大场景包含重要信息：
超融合最早被广泛的应用的场景以 VDI 和 ROBO 为主，即使是生产环境，也用于非核心生产系统，但时至今日， 超融合已经完全覆盖了传统架构中块存储覆盖的所有的领域，甚至包含企业级核心应用。
超融合作为私有云的重要基础，同样成为超融合的一个重要应用场景。
目前热点的边缘计算和物联网领域，也成为超融合的一个重要应用场景。
四、Loki 日志系统分布式部署实践三 redis
这里支持 redis 主从、哨兵、集群三种模式，我这里选择主从即可，集群模式测试异常，没能解决
安装 redis 主从模式：
编写配置文件：
安装：
查看密码：
连接 master：
连接 slave：
读写分离：
读写：
只读：
错误 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 来设置 pod 的 sysctl，而不需要 initContainer 了：
错误 2：
解决：
使用 initContainer 去修改 sysctl 的方案在生产环境正常，这里却报错了，应该是 securityContext 或 PSP 的问题，这里没有启用 PSP，那就剩下 securityContext 了：
我这里尝试写入如下权限，最终都被修改掉了：
这里暂时没有找到解决方案，但是发现虽然报错了，下面 sysctl 修改是生效了的，因为日志不再报错了
错误 3：
解决：
因为 bitnami/minideb:buster 镜像里没有 sysctl
方法一：替换镜像
方法二：直接安装包，但是这个比较慢
错误 4：
解决：
参考： https://github.com/docker-library/redis/issues/55
参考： https://github.com/prometheus/node_exporter/issues/703
注意：它将修改调度了容器的节点的内核设置，从而影响该节点上运行的其他容器。这就是为什么您需要运行特权的 initContainer 或设置 securityContext.sysctls 的原因。
错误 5：
解决：
因为将宿主机的 /sys 挂载到容器内的路径变成了 /host-sys
所以要修改路径：
错误 6：
解决：
这里暂时看不受影响
错误 7：
解决：
因为 master 挂掉了
错误 8：
解决：
Redis 提供两种相对有效的备份方法：
利用 RDB 快照的持久化方式不是非常可靠，当运行 Redis 的计算机停止工作、意外掉电、意外杀掉了 Redis 进程那么最近写入 Redis 的数据将会丢。对于某些应用这或许不成问题，但对于持久化要求非常高的应用场景快照方式不是理想的选择。
利用 AOF 文件是一个替代方案，用以最大限度的持久化数据。同样，可以通过配置文件来开闭 AOF。
打开 AOF 持久化功能后，Redis 处理完每个事件后会调用 write(2) 将变化写入 kernel 的 buffer，如果此时 write(2) 被阻塞，Redis 就不能处理下一个事件。
Linux 规定执行 write(2) 时，如果对同一个文件正在执行 fdatasync(2) 将 kernel buffer 写入物理磁盘，或者有 system wide sync 在执行，write(2) 会被 Block 住，整个 Redis 被 Block 住。
如果系统 IO 繁忙，比如有别的应用在写盘，或者 Redis 自己在 AOF rewrite 或 RDB snapshot(虽然此时写入的是另一个临时文件，虽然各自都在连续写，但两个文件间的切换使得磁盘磁头的寻道时间加长），就可能导致 fdatasync(2) 迟迟未能完成从而 Block 住 write(2)，Block 住整个 Redis。
为了更清晰的看到 fdatasync(2) 的执行时长，可以使用下面命令跟踪，但会影响系统性能：
Redis 提供了一个自救的方式，当发现文件有在执行 fdatasync(2) 时，就先不调用 write(2)，只存在 cache 里，免得被 Block。但如果已经超过两秒都还是这个样子，则会硬着头皮执行 write(2)，即使 redis 会被 Block 住。
此时那句要命的 log 会打印：Asynchronous 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。
因此，对于 fsync 设为 everysec 时丢失数据的可能性的最严谨说法是：
如果有 fdatasync 在长时间的执行，此时 redis 意外关闭会造成文件里不多于两秒的数据丢失。
如果 fdatasync 运行正常，redis 意外关闭没有影响，只有当操作系统 crash 时才会造成少于 1 秒的数据丢失。
方法一：关闭 AOF
如果采用 redis 主从 + sentinel 方式的话，主节点挂了从节点会自己提升为主点，主节点恢复后全量同步一次数据就可以了，关系也不是太大
方法二：修改系统配置
原来是 AOF rewrite 时一直埋头的调用 write(2)，由系统自己去触发 sync。默认配置 vm.dirty_background_ratio=10，也就是占用了 10% 的可用内存才会开始后台 flush
而我的服务器有 8G 内存，很明显一次 flush 太多数据会造成阻塞，所以最后果断设置了sysctl vm.dirty_bytes=33554432(32M) 问题解决
错误 9：
解决：
看着是启动的时候加载 AOF 文件到内存，然后被 liveness 杀掉了
随着命令不断写入 AOF，文件会越来越大，为了解决这个问题，redis 引入了 AOF 重写机制压缩文件。文件能缩小的原因是：
AOF 重写可以手动触发和自动触发：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 16mb
所以这里处理下，控制 AOF 文件大小：
注意：这里依旧没能解决问题，文件依旧很大，而且会造成大量的磁盘 IO，最终导致 redis 失去响应
彻底解决：
之后 dump.rdb 文件一直稳定在 255M
以上就是关于快照应用场景相关问题的回答。希望能帮到你，如有更多相关问题，您也可以联系我们的客服进行咨询，客服也会为您讲解更多精彩的知识和内容。
推荐阅读：
创建aow快照失败怎么弄（创建aow快照失败腾讯手游助手什么情况）
快照是某一时间点云盘的数据状态（快照是某一时间点云盘的数据状态文件 数据制作）
赣公网安备 50019002502384号
