Shared Everything和share-nothing区别

本文介绍了三种主要的数据库架构设计:SharedEverything、SharedDisk 和 SharedNothing。详细解释了它们的特点及应用场景,包括SQL Server、Oracle RAC 和 DB2 DPF 等代表性系统的工作原理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

数据库构架设计中主要有Shared Everthting、Shared Nothing、和Shared Disk:

Shared Everthting:一般是针对单个主机,完全透明共享CPU/MEMORY/IO,并行处理能力是最差的,典型的代表SQLServer

 

Shared Disk:各个处理单元使用自己的私有 CPU和Memory,共享磁盘系统。典型的代表Oracle Rac, 它是数据共享,可通过增加节点来提高并行处理的能力,扩展能力较好。其类似于SMP(对称多处理)模式,但是当存储器接口达到饱和的时候,增加节点并不能获得更高的性能 。

 

Shared Nothing:各个处理单元都有自己私有的CPU/内存/硬盘等,不存在共享资源,类似于MPP(大规模并行处理)模式,各处理单元之间通过协议通信,并行处理和扩展能力更好。典型代表DB2 DPF和Hadoop ,各节点相互独立,各自处理自己的数据,处理后的结果可能向上层汇总或在节点间流转。

我们常说的 Sharding 其实就是Share Nothing架构,它是把某个表从物理存储上被水平分割,并分配给多台服务器(或多个实例),每台服务器可以独立工作,具备共同的schema,比如MySQL ProxyGoogle的各种架构,只需增加服务器数就可以增加处理能力和容量。

<think>我们正在讨论 Spring Cloud Alibaba Nacos 配置中心中的两个配置加载机制:`shared-configs` `extension-configs`。根据引用内容,我们可以总结如下: 1. **优先级规则相同但类型独立**: - 两者都是数组结构,按索引顺序覆盖(索引越大优先级越高)。 - 但它们是相互独立的配置类型,优先级比较只发生在同类型内部(引用[1][2])。 2. **设计目的差异(历史背景)**: - `shared-configs` 的初衷是管理**多服务共享的公共配置**(如 DEFAULT_GROUP 中的配置),强调复用性(引用[3])。 - `extension-configs` 的引入是为了处理**服务专属的扩展配置**,作为对服务自身配置(`spring.application.name` 对应配置)的补充(引用[4])。 3. **实际功能重叠**: - 从技术实现看,两者都能加载任意 dataId group 的配置(引用[4])。 - 本质区别仅在于**优先级位置不同**(见下方优先级总规则)。 4. **整体优先级规则**: ```plaintext 服务专属配置 (最高) ↓ extension-configs[高索引] → extension-configs[低索引] ↓ shared-configs[高索引] → shared-configs[低索引] ↓ 本地配置文件 (最低) ``` 即 `extension-configs` 整体优先级高于 `shared-configs`(引用[1][4])。 5. **失效问题提示**: - Spring Boot 2.4+ 版本推荐使用 `spring.config.import` 替代旧配置方式,可能导致旧属性失效(引用[5])。 --- ### 核心区别总结表 | **特性** | `shared-configs` | `extension-configs` | |------------------|--------------------------------------|-----------------------------------| | **设计目的** | 跨服务共享配置 (如公共参数) | 服务专属扩展配置 | | **典型应用** | 数据库连接、日志级别等全局配置 | 服务特定功能的附加配置 | | **组(group)** | 通常使用 DEFAULT_GROUP (引用[3]) | 可自由指定 | | **优先级位置** | 低于 `extension-configs` (引用[1][4]) | 高于 `shared-configs` | | **动态刷新** | 支持 `refresh=true` | 同样支持 | --- ### 配置示例对比 #### 场景:服务需要加载共享配置 + 自身扩展配置 ```yaml # application.yml spring: cloud: nacos: config: # 服务专属配置 (最高优先级) name: service-name group: DEV_GROUP # 扩展配置 (优先级第二) extension-configs: - data-id: special-feature.yaml group: DEV_GROUP refresh: true - data-id: backup.yaml # 优先级高于上一项 group: RESERVE_GROUP refresh: false # 共享配置 (优先级第三) shared-configs: - data-id: common-db.yaml # 低优先级 group: DEFAULT_GROUP refresh: true - data-id: security.yaml # 高优先级,覆盖 common-db.yaml 同名项 group: DEFAULT_GROUP ``` > **关键结论**: > 当 `security.yaml` `special-feature.yaml` 存在同名配置时,`special-feature.yaml`(属于 `extension-configs`)的值会覆盖 `security.yaml`(属于 `shared-configs`)。 --- ### 使用建议 1. **共享配置**: 将**跨服务通用**的配置(如中间件连接信息)放入 `shared-configs`,使用 `DEFAULT_GROUP` 便于统一管理。 2. **扩展配置**: 为服务**特定功能**(如灰度规则、限流策略)使用 `extension-configs`,避免污染共享配置。 3. **版本兼容**: Spring Boot 2.4+ 项目建议迁移到 `spring.config.import=nacos:xxx.yaml` 方式(引用[5]),例如: ```yaml spring: config: import: - nacos:common-db.yaml?group=DEFAULT_GROUP&refresh=true - nacos:special-feature.yaml?group=DEV_GROUP ``` --- ### 相关问题 1. 如何在 Spring Boot 3.x 中正确迁移 Nacos 的 `shared-configs` 配置? 2. `extension-configs` 能否实现配置共享?与 `shared-configs` 共享有何性能差异? 3. Nacos 配置中心中 DEFAULT_GROUP 自定义 Group 的设计优劣? 4. 动态刷新机制在集群环境下如何保证配置一致性?</think>### `shared-configs` 与 `extension-configs` 核心区别详解 在 Spring Cloud Alibaba Nacos 中,两者都是用于**加载外部配置**的机制,但设计目的优先级不同: --- #### 1. **设计初衷不同** | **配置类型** | 核心目的 | 典型场景 | |---------------------|-----------------------------------|-----------------------------------| | **`shared-configs`** | 管理**多服务共享**的公共配置 | 数据库连接、日志级别、安全证书等全局配置[^3] | | **`extension-configs`** | 管理**当前服务专属**的扩展配置 | 服务特定功能开关、业务参数等个性化配置[^4] | --- #### 2. **优先级规则不同** ```mermaid graph LR A[服务专属配置] --> B[extension-configs] B --> C[shared-configs] C --> D[本地配置文件] ``` - **整体优先级**: `服务专属配置 > extension-configs > shared-configs > 本地配置`[^1][^4] - **同类型内部优先级**: 两者都按**数组索引从低到高覆盖**(索引越大优先级越高): ```plaintext extension-configs[3] > extension-configs[0] shared-configs[3] > shared-configs[0] ``` > **示例冲突解决**: > 若 `shared-configs[2]` `extension-configs[0]` 存在同名配置项, > 最终值以 `extension-configs[0]` 为准(因整体优先级更高)。 --- #### 3. **配置组(Group)差异** | **配置类型** | 推荐 Group 使用 | 说明 | |---------------------|-------------------------------|--------------------------| | **`shared-configs`** | 默认使用 `DEFAULT_GROUP` | 强调跨服务公共性[^3] | | **`extension-configs`** | 可自由指定任意 Group | 更灵活的服务专属配置 | --- #### 4. **技术实现对比** | **特性** | `shared-configs` | `extension-configs` | |-------------------|--------------------------------|-----------------------------| | 配置定位 | 公共基础设施级配置 | 服务业务扩展级配置 | | 动态刷新 | 支持 `refresh=true` | 同样支持 | | 多文件加载 | 支持数组形式多配置 | 同样支持 | | 版本兼容性 | Spring Boot 2.4+ 需迁移新方案[^5] | 同左 | > **迁移注意**: > Spring Boot 2.4+ 推荐使用 `spring.config.import` 替代旧配置方式[^5]: > ```yaml > spring: > config: > import: > - nacos:common-db.yaml?group=DEFAULT_GROUP # 替代 shared-configs > - nacos:service-feature.yaml?group=APP_GROUP # 替代 extension-configs > ``` --- ### 总结对比表 | **维度** | `shared-configs` | `extension-configs` | |-------------------|---------------------------------|----------------------------------| | **核心目标** | 跨服务配置共享 | 服务专属配置扩展 | | **优先级位置** | 低于 `extension-configs` | 高于 `shared-configs` | | **典型 Group** | `DEFAULT_GROUP` | 任意自定义 Group | | **配置性质** | 全局基础设施配置 | 服务业务级配置 | > **本质区别**: > 两者在技术实现上高度相似[^4],但 `shared-configs` 更强调**跨服务复用性**,而 `extension-configs` 侧重**服务内扩展性**。 --- ### 相关问题 1. 在 Spring Boot 3.x 中如何正确迁移 `shared-configs` 配置? 2. 如何设计 Nacos 配置 Group 策略以实现环境隔离? 3. 当 `extension-configs` `shared-configs` 存在循环依赖时如何解决? 4. Nacos 配置的动态刷新机制在集群环境下如何保证一致性?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值