深入浅出分布式技术原理
陈现麟
伴鱼技术中台负责人,前小米工程师
21241 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 39 讲
深入浅出分布式技术原理
15
15
1.0x
00:00/00:00
登录|注册

06|配置中心:如何确保配置的强一致性呢?

发布/订阅或轮询模式
通知服务实例
监听配置修改
实例启动时获取配置
Eureka
ZooKeeper
etcd
Redis
MySQL
API友好程度
低数据容量
中等性能
高可用性
及时同步最新配置到每个实例
实例从配置中心获取配置信息
实例不存储配置信息
服务配置信息的搜索、查询和修改
版本管理的存储系统
允许写的问题
允许读的问题
执行阶段
投票阶段
协调者和Proxy节点的交互
变更同步
首次同步
存储系统比较
存储系统要求
配置信息的同步
统一的配置存储
配置问题导致故障
配置管理效率降低
服务数量增加
配置修改操作冗余低效
实例间配置不一致
缺乏整体配置管理平台
Prepare状态的Proxy节点读写问题
强一致性配置发布的方法
实现配置中心的关键点
理想配置中心的功能
配置中心的必要性
类似两阶段提交的解决思路
需要配置同时生效的场景
配置信息的同步
选择合适的存储系统
高效修改配置
保持同一服务实例间配置一致性
统一管理所有服务配置信息
分布式系统的挑战
单体服务架构的配置管理问题
思考题
总结
如何确保配置的强一致性
如何实现配置中心
配置中心需要具备的功能
为什么需要配置中心
配置中心

该思维导图由 AI 生成,仅供参考

你好,我是陈现麟。
通过学习“负载均衡”的内容,你知道了怎么评价一个负载均衡策略,以及针对不同的业务场景,应该怎么选择合适的负载均衡策略。现在,你已经能够顺利地解决分布式系统中,服务实例的选择问题,恭喜你又前进了一大步。
但是,随着极客时间分布式架构的逐渐演进,之前的单体服务慢慢被拆分为越来越多的服务,虽然拆分后的架构对公司研发的成本、效率和稳定性方面有着非常大的改进,可是你在系统运维的时候,特别是管理系统配置的时候,却发现效率越来越低了,并且还经常会出现因为配置问题导致的故障。
可能你很快就能想到这个问题产生的原因,因为在目前的分布式架构迭代过程中,极客时间的后端系统由之前单体架构的一个服务,被拆分成了多个服务,并且服务的数量还在继续增加。我们管理 1 个服务的配置是很轻松的,但是用管理 1 个服务配置的方法,来管理 10 个、20 个甚至更多的服务配置,效率一定是非常低的,并且也避免不了出错。
虽然能想到原因,但是真正处理时,却不知道怎么做,你是不是也有这样的疑问呢?不要担心,在这节课中,我将和你一起来讨论在分布式系统中,我们应该怎么管理服务配置信息?
我们从分布式场景下,手动管理配置的问题出发,思考为什么需要配置中心,然后进一步讨论配置中心需要具备的功能,接着从存储系统的选择,配置信息的同步这两个方面,来结合业务场景实际讨论,解决如何实现配置中心的问题,最后再探讨一下,需要配置同时生效的场景下,如何确保配置信息的强一致性。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了分布式系统中配置中心的重要性以及如何确保配置的强一致性。首先,文章指出了手动管理配置在分布式系统中的问题,引出了配置中心的必要性。随后,文章详细分析了配置中心需要具备的功能,包括统一管理配置信息、保持实例之间配置的一致性以及高效地修改配置。针对存储系统的选择,文章比较了常见的存储系统,强调了对于配置中心的业务场景来说,选择一个AP模型的存储系统是最优的方案。此外,文章还探讨了如何做配置信息的同步以及如何确保配置的强一致性。最后,通过一个例子介绍了类似两阶段提交的方式,来实现强一致性的配置发布。整体而言,本文通过深入的技术讨论,为读者提供了关于配置中心的全面理解,帮助读者解决分布式系统配置管理问题。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《深入浅出分布式技术原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(10)

  • 最新
  • 精选
  • 努力努力再努力
    思考题: 其实就是 一个 数据一致性问题 ,关于共识算法 共识算法: 1. Paxos (批量的Multi Paxos) 2. Raft 算法。这种比较熟 3.ZAB 算法 1. 如果允许 Prepare 状态的 Proxy 节点读,会出现什么问题? 出去的数据 是旧的数据 1.1 自己思路:这里是为了强一致性,如果不是强一致,其实感觉 有一个copy的数据 ,然后这边写完 再替换copy 其实是可以的 2. 如果允许 Prepare 状态的 Proxy 节点写,又会出现什么问题? 并行走的有多个写操作,可能出现有时序问题 2.1 自己思路: 如果是其他系统,可以使用mq 顺序消息 里面加一个时间戳的字段或者版本号 进行区分 我最近自己在玩计数服务,里面关于数据一致性 就用的是 2pc

    作者回复: 赞~ 2PC 能保证数据的一致性,但是 2PC 是可用性非常差,被称为“反可用性”协议,所以 Raft 和 Paxos 之类的线性一致性并且高可用的算法价值非常大。

    2022-02-09
    2
    6
  • bearlu
    如果我们选择 etcd 和 ZooKeeper,那么出现网络分区的时候,在网络分区的少数派节点一侧,配置中心将不能提供服务,这一侧的服务实例也就不能通过配置中心获取配置,这时如果有实例的重启等操作,就一定会发生故障。 老师。我这边有个问题。etcd分区后。只是不能写,但是读是应该可以,为什么不能提供服务呢?

    作者回复: 在上面的情况,如果直接读网络分区的少数派节点一侧的数据,当数据在网络分区多数派一侧已经更新的情况下,就会读到旧版本的数据,即 stale read,这个就不是线性一致性的读了。 正常来说,如果要线性一致性地读 etcd 上的数据,需要 ReadIndex 或者 LeaseRead 之类的机制来保证。

    2022-02-10
    2
    3
  • 青鸟飞鱼
    选择像Eureka这样子的AP系统,是最终一致性,不确定一致性的时间长短;像etcd出现网络分区时,少数节点的一边提供读服务,读的可能不是最新的数据。但是效果我觉得跟像Eureka差不多,因为不确定这个最终一致性的时间长度。

    作者回复: etcd 对外的保障是线性一致性的,所以在故障的时候,少数节点是不准读的。不过很多情况下,很多公司也经常用 Etcd 来做服务发现,是因为公司只有一个集群,P一般很难出现,并且有了etcd,不想再引入其他的组件了,这个也是可以的。好的架构都是知道系统的边界,然后根据自己的情况去权衡

    2022-02-21
    1
  • 不吃辣👾
    老师 数据迁移的工作中为什么会有两个proxy呢?这两个proxy解决了什么问题?

    作者回复: 由于存储层数据是分片的,请求来了后,需要知道去哪一个存储查询数据,proxy 就是做路由的。 两个 proxy 是表达多个的意思,为了高可用。

    2022-04-01
  • peter
    请教老师一个问题: 在本章强一致性例子中,proxy不是配置中心,只是存储系统的proxy。图中没有画出配置中心。Proxy从配置中心获取配置信息。对吗?

    作者回复: 是的

    2022-02-10
  • Rayjun
    在 k8s 中,configMap 是否可以替代配置中心
    2022-07-11
    2
  • 鱼肥
    这一节有点抽象,是不是应该提一下阿波罗?
    2023-06-27归属地:北京
    1
  • 默默且听风
    我们是用redis集群缓存,如果服务器扛不住的话,再自己往外弹。
    2023-01-13归属地:北京
  • janey
    思考题,eureka没用过,按照数据库的迁移尝试分析一下: 如果prepare时允许读,如果按迁移开始前的路由到proxy1,可能proxy1下对应存储的数据已经被迁走而读取不到数据失败;如果按迁移后的路由到proxy2,可能对应存储的数据尚未迁移到存储2而读取不到数据失败; 如果prepare时允许写,如果按迁移开始前的路由到proxy1,可能proxy1的对应存储已经迁走到存储2,写入失败或成功,但将来存储2丢失了这个写入,commit完成后,在存储2找实际写在存储1的数据失败;如果按迁移后路由到proxy2,可能相关的数据结构还不存在,导致写入失败,或者迁移后将写入给覆盖掉。
    2022-07-24
  • 思绪走了灬光✨
    Eureka能做配置中心吗?不是只有注册中心的能力吗?
    2022-04-08
收起评论
显示
设置
留言
10
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部