文档章节

分布式一致性,技术选型之路

哈库纳
 哈库纳
发布于 2016/09/12 18:11
字数 1551
阅读 254
收藏 0

问题描述: Hasor-RSF 需要一个注册中心。而这个注册中心我想把它设计可以支持集群部署的,这就来带了分布式下服务注册状态一致性的问题。

好了下面开始正文,写的比较潦草。

----------------

ZooKeeper 作为数据中心问题。后来发现单纯使用 ZK 有这么几个问题:

  1. ZK 配置繁琐,整个 Center 所有配置加起来 90% 都是在配置 ZK。 这让以后维护管理 Center 配置会变的复杂,不符合 最简化 的设计初衷。

  2. 开发者在使用 RSF 作为 RPC 框架时并不会引入 ZK 。使用 ZK 的目的是为了同步 Center 的服务数据,因为 ZK 的设计是让开发者以 Client 形式使用它。 这就造成了如果采用 ZK 作为分布式协调者。一个基于 RSF 的 RPC 场景需要(APP、Center、zkServer)三个角色。这样会复杂化部署环境。

  3. 因为 问题 2 的存在,RSF-Center 采用 内置 ZK Server 的方案,结果发现。 内置 ZK ,相当于 ZK 版本固定死。这对 center lib 化是一个沉痛打击。这又印证了 zk 建议 Client 形式使用它,这一特性。

  4. Hasor 对于外部依赖的看法一直是(只用,不扩展,拒绝改写),实际情况中发现,在这个原则下 ZK 经常会有一些小问题。这使得使用 ZK 不得不做很多额外的保障工作。小问题例如:启动选举过程中异常、链接断开之后 Watcher 需要重新注册。

  5. 于是计划放弃 ZK另寻它路。

数据库作为数据中心载体的问题:

  1. 需要部署数据库,会产生(APP、Center、DB)三个角色,会复杂化部署环境。
  2. 需要解决双写覆盖问题。
  3. 当服务的规模达到,万级别时,双向的订阅关系就会超过数据库承载上限。进而需要引进分表分库,架构演进上会变得复杂。
  4. 于是放弃 DB 方案。

使用外部分布式缓存

  1. 和前两个方案一样,会产生(APP、Center、xxx)三个角色,这样会复杂化部署环境。
  2. 同样会遇到 DB 上出现的双写覆盖问题。
  3. 于是放弃 分布式缓存方案。

经典 “Paxos算法”,寻找分布式系统数据存储的最终方案尝试。

  1. 不得不说Paxos算法,确实是预想中的一样,比较晦涩难懂。也充分印证了是一个 难者不会会者不难的东西。它的经典在于:1 二阶段递交、2 半数投票通过即可确认数据被写入。

  2. 算法本身并没有给出工程样例,这在实现上让人比较难以下手。如果仅实现写入功能,对于 Center 来说 数据的一致性问题并没有彻底解决,因为还有读的问题。

  3. 为了保证数据一致性,还要额外引入数据同步机制。同样需要通过 Paxos 选出半数一致的最大 number 然后去增量同步数据。

  4. 数据增量问题,同样也有困惑不好解决。即便增量同步完成了,也无法保证如果节点处于少数派,增量同步并不能保证数据是最新的问题。

  5. 此外还有活锁问题。

  6. 最终放弃 经典Paxos 的原因是,虽然算法可以保证集群对数据的写入的连贯性,但是任意节点读数据无法保证最新。

Raft,这货是在2013年提出的,比起老大哥Paxos晚了将近 25年,先进性自然而言会比 Paxos 好一些。

  1. 值得推荐的链接:http://thesecretlivesofdata.com/raft/
  2. Raft 的经典在于强化了 Leader 的地位,Leader 负责写。这个算法解决了数据一致性问题。
  3. 工程实践上也十分方便。到目前为止,已经有很多 raft 的库可以选择。
  4. 单点问题:所有写操作都要通过 Leader 进行,那么 Leader 的稳定性尤为重要。因为 Leader 的写变成了单点。
  5. 鲁棒性:当 Leader 选举过程中整个集群无法提供写服务。这个是个大问题,对于大量写的场景 Raft 一旦从新选举 Leader 会 block 整个集群的服务。
  6. 基于单点问题,Raft 被放弃。

经典 “Paxos算法”,的演进 “Multi-Paxos”

  1. 这货在 经典Paxos 之上 增加了一个 Leader 的概念。Leader 负责递交提案。比起 Raft 好处是 Multi-Paxos 允许某一个时间出现多个主,因此不用担心 重新选举Leader 会导致集群block 的问题。

  2. 多个主争抢递交提案,理论上会存在冲突。但是 Paxos 的经典在于,任意一个值的确定都要经过半数同意。因此,即便是在多两个主。整个集群的写入依然会保证一致性。

  3. 这个算法虽然出现了 Leader 角色,但是并没有像 Raft 那样特别强调 Leader 的地位。

  4. 另外 Multi-Paxos 和 Paxos 一样,允许日志的连续性出现空洞。 这一点 Center 是可以接受的必经,我只要最终一致性,不要连续一致性。

  5. 写到这里似乎 Multi-Paxos 就是理想中的伊甸园了。但是,这货实现起来好想没有那么简单。

  6. 另外活锁、读、增量数据同步。这些问题也是需要在仔细考虑的。

JGroups 意外的收获。

  1. 复杂,JGroups 是为了解决 组播,等网络传输问题的。并不是被设计用来解决 分布式一致性问题。 引入 JGroups 显得过重。
  2. 协议栈虽然是亮点,但是 Center 的核心问题是 “分布式一致性”。
  3. 如果放弃 ZK 那么 ,RSF-Center 计划,一切数据传输都基于 RSF 传输协议。JGroups 传输层上的扩展又回让人重新陷入,内置 ZK Server 的老路。
  4. 放弃 JGroups

最后最后: 看样子需要自己结合 Paxos 和 Raft,重新设计一个新的算法了,似乎工程量巨大。

欢迎大家一起探讨,有没有更好的办法

© 著作权归作者所有

哈库纳

哈库纳

粉丝 961
博文 84
码字总数 151810
作品 4
杭州
后端工程师
私信 提问
加载中

评论(7)

开源中国最大五毛
开源中国最大五毛

引用来自“大舒”的评论

感觉你这为了一个东西,引入了另一个东西就不应该了。

我提供另一个框架的思路以及它采用的consul:

该框架使用consul作为服务注册中心,提供服务时,需要到consul注册一个服务。

consul自身支持机房、注册等高级功能,跟zookeeper(目录状的数据库)相比,从设计上看来,更适合注册服务。虽然zookeeper。

但是该框架对于其他服务发现机制进行了适配,包括:
mdns(bonjour),etcd,zookeeper。

那么好了,每次服务启动的时候,
provider都会到相应的registry(consul或zk等)注册一个服务,
consumer调用的时候按照情况,可能会将registry的服务全部缓存下来,也可能即用即取。


那么对于这个框架来说,问题就变成了:

我只要对这些自带算法的registry进行适配就好了。

引用来自“哈库纳”的评论

这是一个不错的思路, 引入 consul 或者 zk 亦或者 实现自己的 raft 从架构上来说都是 同样的效果。 使用别人做好的组件可以大大减少研发成本。 hasor-land 这个项目多半有一点 学习研究的性质。

引用来自“大舒”的评论

和你理解的还不太一样,不是引入,而是直接用。

目前我接触到的许多rpc框架,就是一个简单的zk/etcd代理,这样实现注册中心起来,就会比较简单,而且还有算法级别的保证,基本没问题。正常情况下,想要自研一个RPC框架,这是正常的思路。

但是我上面提到的这个框架还不一样:

他就真的只有一个zk/etcd/consul作为注册中心,没有任何代理。

consumer、provider直接和zk等进行交互,使用TTL作为服务存活的检测。

😓

这种用法,真的是骚。

引用来自“哈库纳”的评论

rpc 里面精华的地方,不是服务发现和consumer、provider。 我觉得服务路由、夸机房、流控,各种策略控制才是经典
是的。

哈库纳
哈库纳

引用来自“大舒”的评论

感觉你这为了一个东西,引入了另一个东西就不应该了。

我提供另一个框架的思路以及它采用的consul:

该框架使用consul作为服务注册中心,提供服务时,需要到consul注册一个服务。

consul自身支持机房、注册等高级功能,跟zookeeper(目录状的数据库)相比,从设计上看来,更适合注册服务。虽然zookeeper。

但是该框架对于其他服务发现机制进行了适配,包括:
mdns(bonjour),etcd,zookeeper。

那么好了,每次服务启动的时候,
provider都会到相应的registry(consul或zk等)注册一个服务,
consumer调用的时候按照情况,可能会将registry的服务全部缓存下来,也可能即用即取。


那么对于这个框架来说,问题就变成了:

我只要对这些自带算法的registry进行适配就好了。

引用来自“哈库纳”的评论

这是一个不错的思路, 引入 consul 或者 zk 亦或者 实现自己的 raft 从架构上来说都是 同样的效果。 使用别人做好的组件可以大大减少研发成本。 hasor-land 这个项目多半有一点 学习研究的性质。

引用来自“大舒”的评论

和你理解的还不太一样,不是引入,而是直接用。

目前我接触到的许多rpc框架,就是一个简单的zk/etcd代理,这样实现注册中心起来,就会比较简单,而且还有算法级别的保证,基本没问题。正常情况下,想要自研一个RPC框架,这是正常的思路。

但是我上面提到的这个框架还不一样:

他就真的只有一个zk/etcd/consul作为注册中心,没有任何代理。

consumer、provider直接和zk等进行交互,使用TTL作为服务存活的检测。

😓

这种用法,真的是骚。
rpc 里面精华的地方,不是服务发现和consumer、provider。 我觉得服务路由、夸机房、流控,各种策略控制才是经典
开源中国最大五毛
开源中国最大五毛

引用来自“大舒”的评论

感觉你这为了一个东西,引入了另一个东西就不应该了。

我提供另一个框架的思路以及它采用的consul:

该框架使用consul作为服务注册中心,提供服务时,需要到consul注册一个服务。

consul自身支持机房、注册等高级功能,跟zookeeper(目录状的数据库)相比,从设计上看来,更适合注册服务。虽然zookeeper。

但是该框架对于其他服务发现机制进行了适配,包括:
mdns(bonjour),etcd,zookeeper。

那么好了,每次服务启动的时候,
provider都会到相应的registry(consul或zk等)注册一个服务,
consumer调用的时候按照情况,可能会将registry的服务全部缓存下来,也可能即用即取。


那么对于这个框架来说,问题就变成了:

我只要对这些自带算法的registry进行适配就好了。

引用来自“哈库纳”的评论

这是一个不错的思路, 引入 consul 或者 zk 亦或者 实现自己的 raft 从架构上来说都是 同样的效果。 使用别人做好的组件可以大大减少研发成本。 hasor-land 这个项目多半有一点 学习研究的性质。
和你理解的还不太一样,不是引入,而是直接用。

目前我接触到的许多rpc框架,就是一个简单的zk/etcd代理,这样实现注册中心起来,就会比较简单,而且还有算法级别的保证,基本没问题。正常情况下,想要自研一个RPC框架,这是正常的思路。

但是我上面提到的这个框架还不一样:

他就真的只有一个zk/etcd/consul作为注册中心,没有任何代理。

consumer、provider直接和zk等进行交互,使用TTL作为服务存活的检测。

😓

这种用法,真的是骚。
哈库纳
哈库纳

引用来自“大舒”的评论

最后,对于这个框架来说,注册中心就变得可有可无了。

注册中心的注册功能,已经被zookeeper/etcd等取代,注册中心(如果还有的话),就只剩下了管理的功能。
没错,但是考虑到 rsf 服务注册机制的特殊性, rsf 的注册中心最后会变成一个类似 zk 代理的东西。通过代理负责桥接, rsf 的服务发现和注册。
哈库纳
哈库纳

引用来自“大舒”的评论

感觉你这为了一个东西,引入了另一个东西就不应该了。

我提供另一个框架的思路以及它采用的consul:

该框架使用consul作为服务注册中心,提供服务时,需要到consul注册一个服务。

consul自身支持机房、注册等高级功能,跟zookeeper(目录状的数据库)相比,从设计上看来,更适合注册服务。虽然zookeeper。

但是该框架对于其他服务发现机制进行了适配,包括:
mdns(bonjour),etcd,zookeeper。

那么好了,每次服务启动的时候,
provider都会到相应的registry(consul或zk等)注册一个服务,
consumer调用的时候按照情况,可能会将registry的服务全部缓存下来,也可能即用即取。


那么对于这个框架来说,问题就变成了:

我只要对这些自带算法的registry进行适配就好了。
这是一个不错的思路, 引入 consul 或者 zk 亦或者 实现自己的 raft 从架构上来说都是 同样的效果。 使用别人做好的组件可以大大减少研发成本。 hasor-land 这个项目多半有一点 学习研究的性质。
开源中国最大五毛
开源中国最大五毛
最后,对于这个框架来说,注册中心就变得可有可无了。

注册中心的注册功能,已经被zookeeper/etcd等取代,注册中心(如果还有的话),就只剩下了管理的功能。
开源中国最大五毛
开源中国最大五毛
感觉你这为了一个东西,引入了另一个东西就不应该了。

我提供另一个框架的思路以及它采用的consul:

该框架使用consul作为服务注册中心,提供服务时,需要到consul注册一个服务。

consul自身支持机房、注册等高级功能,跟zookeeper(目录状的数据库)相比,从设计上看来,更适合注册服务。虽然zookeeper。

但是该框架对于其他服务发现机制进行了适配,包括:
mdns(bonjour),etcd,zookeeper。

那么好了,每次服务启动的时候,
provider都会到相应的registry(consul或zk等)注册一个服务,
consumer调用的时候按照情况,可能会将registry的服务全部缓存下来,也可能即用即取。


那么对于这个框架来说,问题就变成了:

我只要对这些自带算法的registry进行适配就好了。
金融行业运维,弯道超车进行时(附PPT下载)

Tips:点击登陆云盘:http://pan.baidu.com/s/1ccWTaQ即可下载6月18日DBAplus社群上海站沙龙PPT。 对所有金融行业的IT运维从业者而言,未来是“危”与“机”共存的时代。当暴风雨和奇点同时逼...

DBAplus社群
2017/06/20
0
0
金融行业运维,弯道超车进行时(附PPT下载)

Tips:点击登陆云盘:http://pan.baidu.com/s/1ccWTaQ即可下载6月18日DBAplus社群上海站沙龙PPT。 对所有金融行业的IT运维从业者而言,未来是“危”与“机”共存的时代。当暴风雨和奇点同时逼...

DBAplus社群
2017/06/20
0
0
分布式系统架构常识:CAP理论。

什么是CAP理论? 2000年7月,加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。2年后麻省理工学院的Seth Gilbert和NancyLynch从理论上证明了CAP,之后CAP理论正式成为分布式...

架构之路
2017/12/20
0
0
架构选型必读:集中式与分布式全方位优劣对比

由于历史原因,集中式架构多用于传统银行、电信等行业。主机资源集中在大型主机或小型机上。集中式架构下,包括操作系统、中间件、数据库等“基础软件” 均为闭源商用系统。集中式架构的典型...

蚂蚁技术团队
2018/06/14
0
0
Oracle MySQL Or NoSQL?(转载)

转载: 作者:Sky.Jian (简朝阳) 链接:http://isky000.com/database/oracle-mysql-or-nosql-2 一些英文缩写的含义: Nosql: not only sql OLTP: 联机事务处理 OLAP:联机分析处理 去IOE:摆...

付磊-起扬
2015/09/12
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Webpack打包优化:使用外链与拆包模式

一、发现问题 这是一个基于 vue-cli 的管理后台项目,由于依赖较多,打包结果如下 二、查找原因 为什么 vendor 体积这么大? 引用的库太多时,vendor的体积会很大,借助 Webpack 的分析工具,...

AI考拉
21分钟前
0
0
MSSQL-最佳实践-Always Encrypted

author: 风移 摘要 在SQL Server安全系列专题月报分享中,往期我们已经陆续分享了:如何使用对称密钥实现SQL Server列加密技术、使用非对称密钥实现SQL Server列加密、使用混合密钥实现SQL S...

阿里云云栖社区
23分钟前
1
0
ES 集群上,业务单点如何优化升级?

摘要: 原创出处 https://www.bysocket.com 「公众号:泥瓦匠BYSocket 」欢迎关注和转载,保留摘要,谢谢! ES 基础 ES 集群 ES 集群上业务优化 一、ES 基础 ES 的安装下载,网上一大片,我这...

泥瓦匠BYSocket
39分钟前
4
0
input accept属性限制文件上传格式

上传文件的类型;具体做法如下所示: 注意:accept属性可以限制上传格式,其有兼容性如下 《1》上传.csv格式的 <input text="file" accept=".csv" /> 《2》上传.xls格式 <input text="file"......

Jack088
46分钟前
1
0
使用scp命令在多个Linux系统间进行文件复制

一,什么是scp scp是linux系统下基于ssh登陆进行安全的远程文件拷贝命令。scp命令可以在linux服务器之间复制文件和目录.scp使用ssh安全协议传输数据,具有和ssh一样的验证机制,从而安全的远...

老孟的Linux私房菜
58分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部