架构师训练营第六周总结

用户头像
养乐多
关注
发布于: 2020 年 07 月 15 日
架构师训练营第六周总结
  1. 数据分片

  • 分片方式:

  • 硬编码实现数据分片

  • 映射表外部存储

  • 数据分片的挑战:

  • 需要大量的额外代码,处理逻辑因此变得更加复杂

  • 无法执行多分片的联合查询

  • 无法使用数据库的事物

  • 随着数据的增长,如何增加更多的服务器

  • 分布式数据库中间件:Mycat

  • 主要采用Amoeda/Cobar,应用服务器通过Cobar服务器集群访问数据库,通过Amoeba进行配置

  • 数据服务请求流程:前端通讯模块-->SQL解析-->SQL路由-->SQL执行代理-->后端通讯模块-->数据查询-->后端通讯模块-->结果合并-->前端通讯模块

  • 路由配置项主要包括:分片字段、表达式、对应数据库实例

  • 集群的伸缩及扩展:

  • 分片之前,评估可能的最大数据量和实例数,每个服务器创建多个实例,按照总实例数取模,添加服务器时,把整个实例移植到添加的服务器中,修改路由规则

  • 注意事项:

  • 有限考虑按业务分库,数据太大时,再考虑对特定表进行分片

  • NOSQL

  • CAP原理:

  • 概念:在分布式系统必须满足分区耐受性的前提下,可用性和一致性无法同时满足,当网络分区失效,也就是网络不可用的时候,如果选择了一致性,系统可能返回一个错误码或者超时,即系统不可用。如果选择了可用性,那么系统总是可以返回一个数据,但不能保证这个数据是最新的,与一致性表述不符

  • C(一致性,Consistency):每次读取的数据都应该是最近写入的数据或返回一个错误,而不应是过期数据

  • A(可用性,Availability):每次请求都应该得到一个响应,而不是返回一个错误或者失去响应

  • P(分区耐受性,Partition tolerance):即使因为网络原因,部分服务节点之间消息丢失或者延迟,系统依然应该是可以操作的(待理解)

  • 数据冲突处理方式:

  • 最终一致性,按照时间戳覆盖

  • 投票解决冲突(Cassandra)

  • HBase架构:应用服务器-->Zookeeper-->HMaster-->HRegionServer-->HRegion-->HFile

  • Doris:

  • 系统架构层面,保证高可用的主要手段是――冗余:服务器热备,数据多份存储。使整个集群在部分机器故障的情况下可以进行灵活的失效转移(Failover),保证系统整体依然可用,数据持久可靠。

  • 路由算法:与redis类似,固定虚拟节点个数,物理节点与多个虚拟节点对应,各服务器之间是不需要通信的,无状态

  • 针对三类故障给出了处理方式

  • 瞬时故障

  • 临时故障

  • 永久故障

  • 分多个存储服务器序列,每个序列互为备份,并发写入,保证可用性,每个序列包括多个服务器,分布式存储

  • Zookeeper:

  • 节点数据操作流程:

  • 在Client向Follwer发出一个写的请求

  • Follwer把请求发送给Leader

  • Leader接收到以后开始发起投票并通知Follwer进行投票

  • Follwer把投票结果发送给Leader

  • Leader将结果汇总后如果需要写入,则开始写入同时把写入操作通知给Leader,然后commit;

  • Follwer把请求结果返回给Client

  • Leader选举:

  • 半数通过

  • 3台机器 挂一台 2>3/2

  • 台机器 挂2台 2!>4/2

  • A提案说,我要选自己,B你同意吗?C你同意吗?B说,我同意选A;C说,我同意选A。(注意,这里超过半数了,其实在现实世界选举已经成功了。但是计算机世界是很严格,另外要理解算法,要继续模拟下去。)

  • 接着B提案说,我要选自己,A你同意吗;A说,我已经超半数同意当选,你的提案无效;C说,A已经超半数同意当选,B提案无效。

  • 接着C提案说,我要选自己,A你同意吗;A说,我已经超半数同意当选,你的提案无效;B说,A已经超半数同意当选,C的提案无效。

  • 选举已经产生了Leader,后面的都是follower,只能服从Leader的命令。而且这里还有个小细节,就是其实谁先启动谁当头。



  • 代码



用户头像

养乐多

关注

还未添加个人签名 2019.11.12 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第六周总结