结合OB Cloud区别于MySQL的4大特性,规划降本方案

任何一家企业想要获得持续性的发展与盈利,“降本增效”都是难以绕开的命题。但是“一刀切”的降本影响往往不太可控,成本的快速收缩往往会给业务带来低效运营和增长缓慢的风险。所以我们所说的降本,是指在成本降低的同时,效率不降反增,这才是企业真正意义上的降本。

在传统集中式数据库统治数据库领域的多年里,“如何实现真正意义上的降本”成为众多企业 IT 部门头疼的问题。本文根据 OceanBase 解决方案架构师高继威在「OB Cloud 公开课」的分享整理而成,通过 OB Cloud 与 MySQL 的对比,分析如何帮助企业实现“降本增效”,并结合中小型公司、大型公司的典型案例,规划可供参考的降本方案。

图片

近年来,各个企业“降本增效”的力度在加大,很多时候企业要通过缩减资源才能达到目标。尤其是对于软件技术架构最底层的基石角色数据库来说,通过缩配来降本,意味着很大的风险。

所以,如何保证在极限吞吐量且不损失、性能稳定的前提下完成降本目标,变得至关重要。这也是 OceanBase 正在做的事——通过技术降本。我们先将 MySQL 与 OceanBase 做一个整体的比较,如下图所示:

图片

  • MySQL 的第一个痛点,实例多且复杂。MySQL 不同的实例资源利用率不平等,有的资源利用率高,有的利用率低;多实例的运维难度也随之增大。而OceanBase是原生分布式数据库,可以单集群通过多租户进行实例整合,降低运维难度的同时提升集群整体的使用率。

  • MySQL 的第二个痛点,数据无压缩。MySQL 是 B+ 树的存储结构,这个结构已经有很多年的历史,但是有个不可绕开的点,就是 B+ 树的每个页内必然会有一定的空隙。而 OceanBase 采用完全自研的 LSM-Tree 存储结构,结合了独特的压缩算法,把原有没经过压缩的数据压缩到 MySQL 的 1/4 到 1/5,甚至更高的压缩比,从而降低存储成本。

  • MySQL 的第三个痛点,弹性差。因为 MySQL 的主备结构,如果要扩容的话,是要更换机器的。而换机器就必然要经过主备切换,此时应用就会发生闪断,影响比较大。为了避免这种情况,往往需要常态化维持业务高峰级别的流量。比如说,大部分时间可能一个 8C 就足够,但是因为在业务高峰有 16C 的要求,所以必须长期保持 16C。OceanBase 具备快速弹性扩容的能力,从而让你可以在需要的时候设置规格,不需要的时候就降下来,节省很多成本。

  • MySQL 的第四个痛点,分析能力弱。MySQL 是纯粹的 OLTP 数据库,为了应对一些分析型报表的业务,需要单独进行数据迁移,再搭建分析型的实例,实际成本也会因此翻倍。而 OceanBase 是 HTAP 的数据库,可以 All in one,让大多数不太复杂的业务都集中在上面去处理,并且无需分析实例,通过二者合一实现降本。

针对 MySQL 架构存在的一些资源利用率不高、冗余浪费较多的固有问题,OceanBase 进行针对性解决,以达成综合降本的效果。OB Cloud 通过技术能让总 TCO 下降 30%,详情可阅读《OB Cloud:如何为用户提供可持续的降本增效?》。

图片

特性解读之前,首先,简单为大家介绍一下 OceanBase 的系统整体架构,大家关注五个关键词:OBProxy、OBServer、Partition、Zone、Paxos。

图片

  • OBProxy:应用连接到 OceanBase 会通过一个名为 OBProxy 的组件,它跟大家认知中的其他中间件不太一样,是一个非常轻量的节点,所以它也不存在 SQL 去做聚合等运算的逻辑,而是只负责 SQL 转发,在 OB Cloud 上的 OBProxy 不用额外付费,所以大家在使用中可以基本忽略这个组件。

  • Zone:Zone 在 OB Cloud 中对应的机房/可用区,OceanBase 集群默认三机房部署。所以说 OceanBase 默认具有机房级的高可用性,一个 Zone 里面可以有一台或者多台 OBserver,一个 Zone 里有很多 Partition 组成。

  • OBServer:即 OceanBase 的服务节点,也就是 SQL 或者存储的主节点。然后一个 Zone 可以有一个或多个 OBServer,OceanBase 可以在横向的每个 Zone 里面去加 OBServer,来实现非常强大的横向拓展能力。

  • Partition:直译是分区,它是 OceanBase 的负载均衡的最小单位,如果表是分析表,那么 Partition 就是分析表的一个分区;如果不是分区表,那么 Partition 就是这个表。

  • Paxos Group:比如图中 P7 分区的三个副本分别分布在三个 Zone 上面,它们是对等的关系。OceanBase 跟 MySQL 的主备模型不同,它是利用 Paxos 的共识算法去实现这个副本的同步。然后 Paxos 的最大特性是自选举,不需要外界来干涉。3 个 P7 会自动选举出 leader,这时候 leader 在 Zone1。

OceanBase 跟 MySQL 的主备模型不同,而是利用 Paxos 的共识算法去实现副本的同步。Paxos 的特性是自选举,不需要外界来干涉。比如图中的 3 个 P7 分区会自动选举出 leader,这时候 leader 在 Zone1。相比于 MySQL 的主从复制,MySQL 的主要把需要同步的数据转成 binlog 逻辑日志,然后再同步给备机转回物理日志。

Paxos 没有这么复杂的转换,所以时延更小,可靠性更高。任何时刻 Paxos 的三个副本里都需要两个副本同意才可以去完成leader的选举和日志的提交,所以OceanBase能够在任何机房级故障下不丢失任何数据。任意级别的故障,OceanBase 都可以在 30 秒之内完成恢复服务,在我们最新版本,这个时间甚至可以降到 8 秒,可用性相比 MySQL 大幅提升。

一、单集群多租户整合实例:提升资源利用率,降低运维难度

左图代表一个应用对应一个数据库实例,是我们目前最常用的部署方案。但下面的多个数据库实例会有个非常常见的问题,资源利用率会非常不平。举例来说:

  • 数据库实例 1 是对内的一个 HR 系统,日常流量非常小,资源利用率可能只有常态化的个位数,5%-10%;

  • 数据库实例 2 是交易波动比较大的系统,如秒杀、电商系统,资源利用率的波动非常大,3%-80%;

  • 数据库实例 3 是比较危险的系统,长期处在比较危险的水位。

这些系统,无论是 DBA 还是运维同学去维护时候,都要同时在控制台上查看多套 MySQL 实例,运维复杂度比较高,风险也比较大。

图片

OceanBase 下有非常多台机器和资源可以部署成一个资源池,然后我们在资源池里,为每个租户定向划分一部分独属于它的资源,由此在 OceanBase 中一个租户就可以承载原来的一个实例,从而让你原来运维多套 RDS 实例或者 MySQL 实例,变为运维一套 OceanBase 集群。

这带来的好处就是租户的规格可以随时随地动态调整,也不用担心业务产生影响,从而可以非常灵活的调度所有资源,提升整体资源利用率,降低成本,并且此时也无需挨个查看 RDS 实例,直接管理一套 OceanBase 集群就可以,运维难度显著降低。

二、LSM-Tree 高级压缩引擎:显著降低存储成本

OceanBase 的存储引擎是基于 LSM-Tree 自研的一套高级压缩的存储引擎,它和 B+ 树不同,其写入会先放在内存,当内存写到一定程度之后,会直接转储到磁盘,然后在每天的业务低峰时间(默认是凌晨两点),将当天的所有转储整理一遍,并且压缩好放在基线 SSTable(ROS)数据里。通过这个被称作合并的过程,LSM 树存储结构的基线数据都是无空隙的,相比于 B+ 树的每个页中都会有一些空隙,所以 OceanBase 天然压缩比就要比 MySQL 好。

图片

此外,OceanBase 在 LSM-Tree 本身能力的基础之上,又进行了两次压缩。

第一次压缩采用行列混存的存储格式,让数据在底层的微块(对应 MySQL 页的一个层次),由行存转成了列存,这样有非常多的好处,比如可以对列存的数据进行数据编码。

图片

看图中的例子,我们在开发过程中经常会碰到重复率很高的字段,比如 RATE_ID 这个字段,就有 4 个值重复出现。这时我们就可以对应一个字典,比如图中的 ID 列的 1901321 对应 0。将这个字典存储好的情况下,这时候每个列只要存 0/1/2 之类的值,以此极大程度地压缩存储。在实际的程序中,有非常多类似这样的案例,OceanBase 会自适应为它们设计一套适合的 encoding 编码方法。

在经过第一次压缩之后,100G 的数据就有可能压缩成 30G。在这个基础之上,OceanBase 还会对 30G 的数据再进行一次通用压缩,给它再“瘦”一次身,这时候就是 LZ4 或者其他通用压缩算法。

经过第二次压缩后,这个数据可能就变成 15G 了。也就是说,在 MySQL 中100G 的数据可能到 OceanBase 上就只有 15G。在实践中,我们很多客户已经达到小于 15% 的比例,极大程度节省存储成本。

有人说,OceanBase 这么高的压缩比,会不会对实时的读写产生影响,实际上是不会的。因为 LSM-Tree 的数据压缩发生在每天合并的时候,合并往往在凌晨两点之类的时间,用户可以自由选择业务低峰期。对于白天高频使用的时候,不会受到压缩带来的性能损耗,而能享受到高压缩比带来的存储成本降低。

三、快速弹性扩缩容:轻松应对峰值压力

OceanBase 的多级弹性伸缩能力可以随业务的发展,动态、随时地调整集群的资源,费用也可以根据用户的需求进行灵活的动态调整,给运维提供了非常大的灵活性。OceanBase 的弹性能力分为三个层次:租户级、机器规格级、机器数量级。

◼︎ 第一级弹性伸缩:租户规格调整

OceanBase 作为分布式数据库,内部把多台机器统一规划为一个资源池,资源池中又可以进一步划分一个个隔离的资源组,每个资源组就形成了一个租户的概念。租户的存在,带来多级弹性伸缩的第一级。因为租户是 OceanBase 内部资源的划分,对租户规格的调整不涉及物理层面的资源调整,完全由 OceanBase 内核完成。这就使得 OceanBase 租户规格的调整,可以秒级生效,整个过程对应用完全无感知。

图片

运维人员在数据库操作过程中,可以在任意时间(比如白天正常业务进行时),调整租户的 CPU 核数和内存大小,整个租户的极限 TPS 就可以得到平滑提升。

图片

图片

◼︎ 第二级弹性伸缩:机器规格调整(垂直扩缩容)

面对相对较大的业务流量,简单调整租户规格可能还无法满足业务需要,这时候就需要扩大机器规格。比如,把集群从 30C 的规格扩容至 62C,来应对业务大流量。由于 MySQL 的扩容过程就是一个主备切换的过程,会对业务有闪断的影响。而 OceanBase 是通过 Paxos 协议进行节点间的数据同步,Paxos 协议核心点是自选举,一份数据的三个副本投票表决出谁来当选 leader,以及该日志是否提交。

这一点相比于 MySQL 主从复制,带来了两点优势:

  • OceanBase 的数据同步单位更小,带来更高的性能和灵活性。OceanBase 的 Paxos 组以分区为单位,相比于 MySQL 节点级日志同步,分区粒度更小,避免了 MySQL 为保证全局顺序带来的性能影响。并且 OceanBase 支持分布式事务的能力,还允许不同分区的 Leader 不在同一个节点上,比如上图中深蓝色的 Leader 节点就分布在三副本中,实现多点写入的能力,可以充分利用多机性能,并支持下面增加节点的扩展方式。

  • OceanBase 的同步日志更轻量,代价更小。OceanBase 的 Paxos 协议同步的日志为 OceanBase 内部的物理日志 clog。 而 MySQL 的流程是主生产逻辑日志binlog,binlog 同步给备机后转化成 relay log,再执行的过程。OceanBase 的 clog 更轻量,更高效,配合 Paxos 分区级的同步粒度,OceanBase 不会有 MySQL 令人头疼的主备时延问题。

体现在扩缩容操作中,更换机器规格时,OceanBase 也需要先挂载一台机器同步数据,但切换时 OceanBase 只需要进行一次 Paxos 的有主选举,也就是 leader 完成自己最后一个日志提交后,主动放弃 leader 身份,然后主动投票给另一个节点,完成平滑切换。相比于需要闪断的 MySQL 主备切换,OceanBase 升配的整个过程对应用基本透明无感知。

图片

◼︎ 第三级弹性伸缩:机器数量调整(水平扩缩容)

这是 MySQL 主备架构做不到的一点,因为 OceanBase 是原生的分布式数据库,支持分布式事务,所以可以做到无感知的横向扩展。更直观的说,就是 OceanBase 集群增加机器,业务流量就会自动迁移到新增的机器中。并且在这个过程中,应用是没有感知的,可以像使用一个单机 MySQL 那样继续使用这个有多台机器的集群,这一点在很多工程实践中,被证实了是分库分表方案的更优解。

图片

四、HTAP:一套系统完成 OLTP 与 OLAP 业务

MySQL 是一个标准的 OLTP 联机交易型数据库。所以 MySQL 的优化器能力天然比较弱,对于大表关联,结果特别大的查询支撑不足。大家可能也都碰到过,有可能 SQL 跑非常久,也跑不出结果;也没有办法做到灵活的资源隔离,往往大 SQL 会影响正常的 TP(联机交易型)业务。所以大家一般都不敢用 MySQL 去做分析型的业务。

那么业务有AP(分析型)的需求,该怎么办呢?传统的做法一般是通过异步传输,也就是 ETL 过程,打造一个专用的分析型数据库,去做 OLAP 的业务。这必然会导致多出两部分的成本:传输过程,分析实例。

OceanBase 是 HTAP 的数据库,可以把 OLTP 和 OLAP 的请求都放在集群里完成。那么为什么 MySQL 不能做到而 OceanBase 却可以呢?主要是OceanBase在四个方面强化了 AP 方面的能力:

  • OceanBase 的优化器是对标 Oracle 的企业级优化器。哪怕多复杂的多表关联 SQL(实际生产中有碰到过 10+表的 join),无论何种 SQL 写法,都可以优化成最优的执行计划,保障了 SQL 执行的代价最低;

  • 前文提到过,OceanBase 在底层微块层面是列存储,而列存储对按列进行的分析型业务有一定的加速;

  • OceanBase 支持并行执行,可以将一个较大的 SQL 执行计划切分为多个较小的任务,启动多个线程来并行处理这些小任务。目前对于查询、DML、DDL 都可以通过并行执行来加速查询;

  • OceanBase 有向量化执行引擎,相比于火山模型按行读取数据,向量化引擎可以按批次读取数据,对大量分析的 SQL 更友好。

图片

OceanBase 的 HTAP 理念是:一个系统、一份数据,All in one 解决所有问题,无需额外付费,无需增加专用的分析节点。在一套存储引擎、一套存储结构上,同时完成 AP 和 TP 的请求,以此来实现降本增效的诉求。

你可能会担心,在 TP 和 AP 都能做的情况下,怎样避免分析型的业务影响实时在线交易。针对这一问题,OceanBase 提供了多种资源隔离方式:

  • 使用多个租户进行物理隔离——搭建专用分析租户

  • 同一租户,使用不同可用区(副本)进行物理隔离——只读地址,实时分析

  • 同一租户,使用不同资源组进行隔离——同一机器,资源隔离,实时分析

图片

作为一个企业或运维人员,如何通过 OceanBase 的这些能力,站在应用者的角度去使用 OceanBase,为大家带来实实在在的“降本”呢?

整体而言,可以按照原有 MySQL 实例规格之和的 80%-95%,存储容量之和的 15%-20%,估算 OceanBase 集群的规格大小。下面我们通过两个例子,来具体看一下 OceanBase 降本方案的制定和降本效果的判断。

Eg.1 中小型公司

对于中小型公司,比如图中的例子,该公司有一个 16C 的 RDS,2 个 4C 的 RDS,以及 4 个 2C 的 RDS,这是一个非常常见的产品阵列。

  • 16C 的 RDS,最大的库,用在公司核心的对外业务,资源占有率也比较高;

  • 2 个 4C 的 RDS,用在一些二级业务,比如说库存、订单之类的系统,资源占有率可能相对较低;

  • 4 个 2C 的 RDS,这些比较小的零散实例,用在内部的业务。

总之,这些库的资源占用率会根据他们业务属性的不同,有所波动,所以在运维时,也会比较麻烦。如下图所示,16C + 2*4C + 4*2C = 32C;3TB + 2TB + 1TB = 6TB,如果将其迁移到 OceanBase 上,一套 30C 的 OceanBase 集群 ,1.5TB 的存储就可以完全支撑所有业务,并且将原来的零散资源变到一个比较健康的水位。

图片

在 MySQL 中,OceanBase 高可用版本对标 MySQL 的集群版,然后也要多可用部署,并且是独享规格。由于 OceanBase 是技术降本,所以这里将二者的总吞吐量进行了对比,在 sysbench read-write 1000 并发场景下,降本约 30%,具体数据见下图。

图片

Eg.2 大型公司

某大型公司,该公司有 32C 的 RDS 支撑核心业务,16C 的 RDS 支撑二级业务,5 个 4C 的 RDS 支撑内部小业务。总体资源利用率与上个案例相差不大,总计算资源 32C + 16C + 5*4C = 68C;10TB + 5TB + 5TB = 20TB,此时如果在 OceanBase 上,一套 62C 的 OceanBase 集群加上 4TB 的存储就可以承载这套集群。 

图片

关于怎么去规划成本,这里简单介绍一下二者的区别。在 sysbench read-write 1000 并发场景下,在 MySQL 中,假设计算资源 68C 的话,会有 136C 作为备机,存在很大的资源浪费。而在 OceanBase 中,我们有 62C 的计算资源,通过主备打散的方案把所有机器利用起来,总成本降低约 40%,具体数据可见下图。

图片

所以,我们认为应该将“降本”、“增效”两个词合起来看,OceanBase 的“降本”是通过技术手段进行降本,希望数据库的总体价值得到提升,不管是数据吞吐量、高可用能力、Online DDL 能力等,还是运维友好度,都可以不随着成本的降低而丢失。

希望随着 OB Cloud 的不断成熟,能为企业带来更多实实在在的价值,在降本的同时,效率不降反增,实现真正意义上的降本。借此,DBA、运维等同学也可以有更多时间为企业创造更大的价值。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/116588.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

js 正则表达式 验证 :页面中一个输入框,可输入1个或多个vid/pid,使用英文逗号隔开...

就是意思一个输入框里面&#xff0c;按VID/PID格式输入,VID和PID最大长度是4,最多50组 1、页面代码 <el-form ref"ruleForm" :model"tempSet" :rules"rules" label-position"right"> <!-- 最多 50组&#xff0c;每组9个字符…

【C语言】字符函数,字符串函数,内存函数

大家好&#xff01;今天我们来学习C语言中的字符函数&#xff0c;字符串函数和内存函数。 目录 1. 字符函数 1.1 字符分类函数 1.2 字符转换函数 1.2.1 tolower&#xff08;将大写字母转化为小写字母&#xff09; 1.2.2 toupper&#xff08;将小写字母转化为大写字母&…

ZigBee案例笔记 -- RFID卡片读写(模拟饭卡)

RFID模拟饭卡应用 RFID&#xff08;射频识别技术&#xff09;RFID通讯协议RFID发展历史RFID操作流程说明RFID卡片读写流程RFID寻卡RFID防碰撞RFID选卡RFID卡密验证RFID读卡RFID写卡读写数据流程 RFID饭卡模拟案例驱动代码串口协议饭卡操作案例结果优化建议 RFID&#xff08;射频…

Cordova Android 生成的 APK 中添加代码混淆

要在 Cordova Android 生成的 APK 中添加代码混淆&#xff0c;你可以按照以下步骤进行操作&#xff1a; 1. 在项目根目录下&#xff0c;找到 platforms/android/ 目录&#xff0c;进入该目录。 2. 打开 build.gradle 文件&#xff0c;并在 android { ... } 部分添加以下代码&…

关于两个不同数据库的两张表建立数据库链接,关联查询数据

一、数据库链接 数据库链接&#xff08;database link&#xff09;是用于跨不同数据库之间进行连接和数据传输的工具或方法。它允许在一个数据库中访问另一个数据库中的对象和数据。 二、具体操作 以Oracle数据库为例 --1.建立链接tjpt CREATE DATABASE LINK tjpt CONNECT…

go语言--锁

锁的基础&#xff0c;go的锁是构建在原子操作和信号锁之上的 原子锁 原子包实现协程的对同一个数据的操作&#xff0c;可以实现原子操作&#xff0c;只能用于简单变量的简单操作&#xff0c;可以把多个操作变成一个操作 sema锁 也叫信号量锁/信号锁 核心是一个uint32值&#…

基于单片机的串行通信发射机设计

一、项目介绍 串行通信是一种常见的数据传输方式&#xff0c;允许将数据以比特流的形式在发送端和接收端之间传输。当前实现基于STC89C52单片机的串行通信发射机&#xff0c;通过红外发射管和接收头实现自定义协议的数据无线传输。 二、系统设计 2.1 单片机选择 在本设计中&…

前端基础2——CSS样式

文章目录 一、使用方式1.1 内联方式1.2 内部方式1.3 外部导入方式&#xff08;推荐&#xff09; 二、选择器类型2.1 元素选择器2.2 ID选择器2.3 类选择器2.4 派生选择器 三、常用属性3.1 内边距和外边距3.2 文本3.3 边框3.4 背景3.5 定位3.6 浮动3.7 字体3.8 其他属性 四、案例…

MySQL 数据库常用命令大全(完整版)

文章目录 1. MySQL命令2. MySQL基础命令3. MySQL命令简介4. MySQL常用命令4.1 MySQL准备篇4.1.1 启动和停止MySQL服务4.1.2 修改MySQL账户密码4.1.3 MySQL的登陆和退出4.1.4 查看MySQL版本 4.2 DDL篇&#xff08;数据定义&#xff09;4.2.1 查询数据库4.2.2 创建数据库4.2.3 使…

DataTable扩展 列转行方法(2*2矩阵转换)

源数据 如图所示 // <summary>/// DataTable扩展 列转行方法&#xff08;2*2矩阵转换&#xff09;/// </summary>/// <param name"dtSource">数据源</param>/// <param name"columnFilter">逗号分隔 如SDateTime,PM25,PM10…

docker desktop安装es 并连接elasticsearch-head:5

首先要保证docker安装成功&#xff0c;打开cmd&#xff0c;输入docker -v&#xff0c;出现如下界面说明安装成功了 下面开始安装es 第一步&#xff1a;拉取es镜像 docker pull elasticsearch:7.6.2第二步&#xff1a;运行容器 docker run -d --namees7 --restartalways -p 9…

ShardingSphere——压测实战

摘要 Apache ShardingSphere 关注于全链路压测场景下&#xff0c;数据库层面的解决方案。 将压测数据自动路由至用户指定的数据库&#xff0c;是 Apache ShardingSphere 影子库模块的主要设计目标。 一、压测背景 在基于微服务的分布式应用架构下&#xff0c;业务需要多个服…

WebVR — 网络虚拟现实

推荐&#xff1a;使用 NSDT编辑器 快速搭建3D应用场景 虚拟现实设备 随着Oculus Rift和许多其他生产设备即将上市&#xff0c;未来看起来很光明——我们已经有足够的技术来使VR体验“足够好”&#xff0c;可以玩游戏。有许多设备可供选择&#xff1a;像Oculus Rift或HTC Vive这…

JasperReport定义变量后打印PDF变量为null以及整个pdf文件为空白

问题1: JasperReport打印出来的整个pdf文件为空白文件&#xff1b; 问题2&#xff1a;JasperReport定义变量后打印PDF变量为null&#xff1b; 问题1原因是因为缺少数据源JRDataSource JasperFillManager.fillReport(jasperReport, params,new JREmptyDataSource());如果你打印…

Go 使用 Gorm 将操作信息集成到链路跟踪 Jaeger,进行增删改查使用举例,并做可视化UI界面展示(附源码)

Go 使用 Gorm 将操作信息集成到链路跟踪 Jaeger,进行增删改查使用举例(附源码)。 为了增强程序的可观测性,方便问题定位,在发起数据库操作请求时我们也可以调用代码统一集成链路跟踪的能力,Jaeger 是当今比较流行的选择。使用 Gorm 来将操作信息集成到 Jaeger 中。 全面…

Autofac中多个类继承同一个接口,如何注入?与抽象工厂模式相结合

多个类继承同一个接口,如何注入&#xff1f;与抽象工厂模式相结合 需求: 原来是抽象工厂模式,多个类继承同一个接口。 现在需要使用Autofac进行选择性注入。 Autofac默认常识: Autofac中多个类继承同一个接口,默认是最后一个接口注入的类。 解决方案&#xff1a;(约定大于配…

使用远程桌面软件改善工作与生活的平衡

在当今高度互联的世界中&#xff0c;我们的工作和个人生活之间的界限变得越来越模糊。在本文中&#xff0c;我们将探讨像 Splashtop 这样的远程桌面工具如何成为实现和谐工作与生活平衡不可或缺的一部分。 在当今的背景下理解工作与生活的平衡 工作与生活的平衡不仅仅是一个时…

【C++进阶】模板进阶

&#x1f466;个人主页&#xff1a;Weraphael ✍&#x1f3fb;作者简介&#xff1a;目前学习C和算法 ✈️专栏&#xff1a;C航路 &#x1f40b; 希望大家多多支持&#xff0c;咱一起进步&#xff01;&#x1f601; 如果文章对你有帮助的话 欢迎 评论&#x1f4ac; 点赞&#x1…

Ansible学习笔记5

copy模块&#xff1a;&#xff08;重点&#xff09; copy模块用于对文件的远程拷贝&#xff08;如把本地的文件拷贝到远程主机上。&#xff09; 在master的主机上准备一个文件&#xff0c;拷贝文件到group1的所有主机上。 这个用的频率非常高&#xff0c;非常有用的一个模块…

pdf加密如何解除?这样解除加密很简单

pdf加密如何解除&#xff1f;有时&#xff0c;我们可能会收到一些加密的PDF文件&#xff0c;它们不允许我们对其进行编辑或打印。这时&#xff0c;我们需要使用PDF解密工具&#xff0c;以便能够轻松地解除PDF加密并对其进行编辑。那么接下来就给大家介绍一下pdf加密解除的方法。…