架构师训练营第六章总结

发布于: 16 分钟前

Mysql高可用

主从复制

  • 互联网最开始就是一主一从服务器,读写分离用户请求,写操作进入主服务器,读操作进入从服务器;

  • 客户端向服务器发起操作命令,服务器接收到请求一边写入到本地数据库文件里面,一边往Binlog日志里面写记录;

  • Binlog只会记录更新操作,不会记录查询操作;

  • 客户端会启动一个线程会去Binlog获取数据,并同步到从服务的Relay Log文件中;

  • Relay Log 写入的顺序和Binlog写入的顺序保持一致;

  • 从服务器上面另外有一个线程去观察log新增的命名,并获取数据记录到本地数据库文件;

  • Binlog只同步DML(update、delete、insert语句),不同步DDL(drop、alert、create语句);

  • 如果新增DDL语句需要手动在主从服务器上执行,如果不在从服务器上执行,会导致数据不一致的情况;

一主多从

  • 通过复制的方式把主服务器的写操作同步至从服务器;

  • 从服务器只提供读操作,不提供写操作,也就是从服务不能同步至主服务器;

  • 一般场景只有读操作,报表系统或者分析师系统有复杂的逻辑就可以连接从服务操作数据;

  • 一主多从可以分摊负载,用更多的从服务器,接收更多的请求,增强系统的并发能力;

  • 专机专用,不同的从服务器提供的不同的业务场景,而不会所有的场景都是一个入口,每一个系统都有自己的从服务器;

  • 便于冷备热备,由于服务器宕机,或者是主服务器的数据文件损害,从服务器还会保存数据,不会导致数据丢失;

主主复制

  • 两台服务器都是主服务器,数据可以从A服务器数据同步至B服务器,也可以将B服务器数据同步至A服务器;

  • 主主复制不仅有Binlog还有Relay Log,做数据双向同步;任何一台数据新增数据的时候,都会同步到另外一台服务器;

  • 从一台服务器的Binlog同步至Relay Log进行数据写入,这种场景不会在记录到写数据库的Binlog;

  • 客户端只写主服务器A,不写主服务B;不是解决双写的问题,而是解决主服务器宕机,可以快速切换的另外一台主服务器;

  • 如果出现双写会导致数据冲突,包装事务的原子性和隔离性;

主主失效恢复

  • 当主服务器失效的时候,另外一台主服务器依然可以提供数据服务;

  • 每一个主服务器会有自己的从服务器,主服务器A不仅需要向主服务器B同步数据,也需要跟主服务器A的从服务器同步数据;

  • 正常访问是会请求主服务器A,当主服务器A失效之后,写操作会被发送到主服务器B;

  • 如果主服务器A正常使用,则主服器B是备机;如果A宕机则主服务器B是主服务器,A恢复之后,A就是备机;

  • 复制只是增加了数据的读并发能力,没有增加写并发能力和存储能力;

  • 更新表结构会导致巨大的同步延迟;

分布式数据库

数据分片

硬编码数据分片

  • 这个是目前最简单的一种解决办法,在应用程序中解决分片的问题;

  • 数据分散在服务器1和服务器2,可以根据用户id取模,如果是奇数则发送至服务器2,如果是偶数则发送服务器1;

  • 这种场景需要服务支持多数据源操作,根据id判断需要连接哪一个数据源,进行操作;

映射表外部存储

  • 在外部单独存储一个数据映射表,比如用户id和服务器编号的映射关系;

  • 外部请求时,会根据id在映射表查找映射关系,并获取数据库服务器,然后进行操作;

  • 外部数据映射相比于硬编码更加灵活,可以维护不同的主键,比如用户id、账号、商品ID等;

  • 但是外部数据会新增一次多余的数据查找,这时就需要考虑缓存;大数据做映射表也增加的系统的复杂度;

分布式数据库中间件

mycat

  • mycat是面向应用程序的中间件,由数据库中间件对数据进行路由;

  • 需要在mycat配置对应的路由规则,比如省份为wuhan的请求db1;

  • 数据分片和路由的功能由中间件mycat提供;

ShardingSphere

  • 是一套开源的分布式数据库中间件解决方案组成的生态圈;

  • 提供标准化的数据分片、分布式事务和数据库治理功能;

  • 适用于任何基于JDBC的ORM框架,如:JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。

  • 支持任何第三方的数据库连接池,如:DBCP, C3P0, BoneCP, Druid, HikariCP等。

  • 支持任意实现JDBC规范的数据库。目前支持MySQL,Oracle,SQLServer,PostgreSQL以及任何遵循SQL92标准的数据库。

  • 需要应用程序集成sharding插件,并需要自己实现分片规则;

分布式一致性算法Paxos

Paxos角色

  • 提供三种角色Proposer 提案者、Acceptors接受者、Learner学习者;

  • 在分布式场景下需要作出一个决策时,需要给Proposer提交一个提案;

  • Acceptos判断是否接受这个提案,如果超过半数接受提案,需要把确定的结果发送给Learner;

  • 有的Acceptors会拒提案,有可能是已经收到其他服务器发送的请求,所以有新的提案进来时会拒绝;

Paxos阶段

  • 第一阶段:Parpare阶段。Proposer向Acceptors发出Prepare请求,Acceptors针对收到的Prepare请求进行Promise承诺;

  • 第二阶段:Accepet阶段。Proposer收到多数Acceptors承诺的Promise后,向Acceptors发出Propose请求,Acceptors针对所收到的Propose请求进行Accept处理;

  • 第三阶段:Learn阶段。Proposer在收到多数Acceptors的Accept之后,标志着本次Accept成功,决议形成,将形成的决议发送给所有的Leanrers;

  • Proposer生成全局唯一且递增的ProposalID,向所有Acceptors发送Prepare请求,请求无需携带提案内容,只携带ProposalID即可;

  • Acceptors接收到Prepare和Propose请求后,不在接收ProposalID小于等于当前ID的请求;

Zab协议

  • Zab协议是简化版本的Paxos,成了一个自定义的协议;

  • 一个提案提交到集群时先交给Learer,有leaner决策;

  • Learner向Follower发出提案Propose,如果Follower接受提案,则会发出一个ACK应答;

  • 如果接收到半数ACK应答,这个提案就是被接受的,然后向所有的Follower发送接受的内容,然后所有程序达成一致;

  • 所有的Server都是一个Follower,只有个Server是Leader;

  • 写数据时,客户端任意连接一个Server,由Server向Leader发送提案做决策;

  • 读数据时不存提案的问题,无论连接哪一个Server都可以直接返回数据,Server状态是一致;

ZooKeeper API 存储结构

  • / 为根目录,所有记录基于根目录操作;

  • 下级目录可通过api创建,一般会根据应用划分不同的目录;

  • 目录下可以创建文件,记录数据;

ZooKeeper API

String create(path,data,acl,flags)//创建路径
void delete(path,expectedVersion)//删除路径
Stat setData(Path,data,expectedVersion)//设置数据
(data,Stat) getData(path,watch)//获取数据,并监听数据的变化
Stat exists(path,watch)//判断数据是否存在
String [] getChildren(path,watch)//获取子节点
void sync(path)//异步节点
List multi(ops)//多数据操作

常见的场景:配置中心、注册中心、分布式锁等都可以基于ZooKeeper实现

ZooKeeper选master

  1. servers下面有多态服务,有一台leader标志,那一台服务器把ip注册在leader位置,就是master

  2. 调用接口getData("/servers/leader",true);

  3. 判断getData返回的值,如果不存在,则说明没有leader;

  4. 没有leader前提下,调用接口create("/server/leader,hostname,EPHEMERAL)创建一个临时leader,并把自己的主机名写入,创建的时候是一个长链接,当断开之后又会删除leader节点,其它节点又可以抢占;

  5. 如果并发场景都在创建不一定成功,如果都不成功,则重复上述步骤;

  6. 退出选举逻辑;

ZooKeeper集群管理

  • 负载均衡器监控nodes节点;

  • 根据接口getChildren获取所有的子节点;

  • 新增服务器是负载均衡器会接收到ZooKeeper的通过,新增ip地址,然后重新调用接口,获取新的机器信息;

  • 如果某一台服务器丢失不可以了,监听也会产生一个事件,然后调用删除接口删除对应的节点信息;负载均衡器就会收到通知不会生效了;

  • 服务器启动的时候都会根据ephemeral创建服务节点;

Zookeeper性能

  • 不同颜色分别代表不同服务器,横坐标代表读操作的占比100就是全是读操作,0就是全是写操作;纵坐标代表吞吐能力;

  • 当全部是写操作的时候吞吐能力比较差,全部是读操作的时候吞吐量是比较高的;

  • 读数据的时候不管连接那一台服务器都可以获取到数据,但是写数据需要通过提案才能写入成功;

  • 都是写的情况下,3台服务器比13台服务的吞吐能力高;因为3台只要有两台接受提案就可以操作成功;而13台需要7台接收提案才能写入成功;

  • 服务器越多写操作达成一致性的时间越长,吞吐能力越差;

  • 服务器越多读操作性能越好,吞吐能力越高;

发布于: 16 分钟前 阅读数: 3
用户头像

叮叮董董

关注

还未添加个人签名 2020.04.08 加入

还未添加个人简介

评论

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