MySQL集群(PXC)

  • 时间:
  • 来源:互联网

一、目标和方式

1.目标:

  1)大型互联网应用的架构设计和业务处理

  2)掌握PXC集群MySQL方案的原理

  3)掌握PXC集群的强一致性

  4)掌握PXC集群的高可用方案

2.分析方式:由浅入深,循序渐进;案例有小到大,逐步扩展

 

二、硬件环境需求

1.win /Linux/ MacOS

2.Docker虚拟机

3.内存8GB以上

 

三、单节点数据库的弊端

1.大型互联网程序用户群里庞大,所以架构必须要特殊设计

2.单节点的数据库无法满足性能上的要求,就像校园网查成绩的时候,如果1万人同时查,你可能拿到就是一个白屏,无论你是收费的还是免费的数据库,单节点都满足不了这种并发需求

3.单节点的数据库没有冗余设计,无法满足高可用,一旦这个机器出现问题,没有其他节点的数据库顶替,那网站将无法正常访问

单节点数据库测试,5000个连接,5000个并发查询,平均就1个连接1个查询,安装好数据库,配置好环境变量,[mysqld]下面配置最大连接量为6000(max_connections=6000),执行下面的命令:

mysqlslap -hlocalhost -uroot -pabc123456 -P3306 --concurrency=5000 --iterations=1 --auto-generate-sql --auto-generate-sql-load-type=mixed --auto-generate-sql-add-autoincrement --engine=innodb --number-of-queries=5000

得到下面的结论:

这才5000个并发,需要的时间就达到了34秒,如果设置10000个并发,将如何呢?

数据库拒绝了很多请求,把没有拒绝的执行了,需要的时间是167秒,这就是单击单点在面对并发的时候数据库的承受能力。

 

四、PXC高可用集群方案

这样一个最基本的PXC集群,它保证了每个节点的的数据都是一致的,不会出现数据写入了数据库1而没有写入数据库2的情况,这种的集群在遇到单表数据量超过2000万的时候,mysql性能会受损,所以一个集群还不够,我们需要把数据分到另一个集群,这个称为“切片”,就是把大量的数据拆分到不同的集群中,每个集群的数据都是不一样的,看下面的截图:

这样一来,PXC集群1存前面1000万条数据,PXC集群2存后面1000万条数据,当一个sql语句请求的时候,通过MyCat这个阿里巴巴的开源中间件,可以把sql分到不同的集群里面去。这种的分片按照数量就是2个分片。

这个切分算法也比较多,比如按照日期、月份、年份、某一列的固定值,或者最简单的按照主键值切分,主键对2求模,余0的存分片1,余1的存分片2,这样MyCat就会把2000万条数据均匀地分配到2个集群上。

PXC虽然保证了数据的强一致性,但是这是以牺牲性能为代价的,所以适合保存重要的数据,比如订单。

 

五、Replication集群方案

这种集群,在第一个节点插入以后,就马上返回给客户端执行成功了,然后再做每个节点之间的同步,如果某一个同步操作失败了,那用户请求的时候拿到的数据就不同步了,但是它的优势是速度快,不会牺牲任何地性能,适合保存不那么重要的数据,比如日志。

 

六、PXC与Replication集群结合

 

七、系统架构方案

更加清晰和详细架构请看下面的截图

 

八、APP的架构设计

 客户端包括web浏览器端,移动手机端,用户通过客户端发送一个请求后,Nginx接收到请求后,会做负载均衡,定向到当前最适合(相对没那么繁忙)处理这个请求的服务器端,服务端接收到请求后,再访问数据库,一些热点数据需要做缓存,比如淘宝首页的商品。从上面的图中看,服务器端的某一个出现故障后,nginx会将请求定向到剩下的能正常运行的服务器上面,而数据库端也是采用的集群,这样就达到了高可用,就是任意一台机器出现故障,对整个网站的运行不会产生太大的影响,这里可能有人会问如果nginx这台服务器出现问题了怎么办?可以做虚拟ip(vip),配置主从入口,就是nginx1和nginx2的虚拟ip是一样的,其中有一个是主入口,在主入口没有出现问题的时候,从机是不会工作的,当主入口机出现问题了,从入口机就会顶替,如果主从都出现问题了,那网站将无法访问。

服务器端的spring与spring之间的调用又是如何的?现在都是分布式调用,比较经典的是dubbo+zookeeper。这里有同步调用和异步调用

同步调用:提出问题的一方直接调用处理问题的一方

异步调用:提出问题的一方将问题交个消息中间件,由消息中间件去将问题发放给处理问题的一方,在这里,提出问题的一方称为“生产者”,处理问题的一方称为“消费者”,他们彼此是不知道对方是谁,达到业务解耦的效果,这样做的好处是以后在部署项目、程序的升级、接口的变更的时候,它的影响面就很小。比如说生产者项目开发地有问题,然后用其他语言再做了一个项目,对消费者不会产生任何影响,只要生产生能正常往消息队列里面发送消息就好;再比如用户注册一个淘宝账号,我们连带着把支付宝账号也给你开通,然后其他的投资的项目也给用户一些优惠(给你2张淘票票的电影票,免费一个月的虾米音乐会员等等),对应淘宝这一端,它发起一个消息传达给消息队列,至于接收端是支付宝还是淘票票还是虾米音乐,淘宝这一端不知道也不需要关心,等以后阿里再有什么投资项目需要给新用户优惠的时候,只需要从消息队列里接收消息就可以,对生产者而言,没有任何影响。如果是同步调用(dubbo或者webservice调用),其中一端有修改,另一端必然也要改,这种强耦合是不好的。

以下是异步调用方案图:

wachoo
发布了28 篇原创文章 · 获赞 2 · 访问量 1万+
私信 关注

本文链接http://element-ui.cn/news/show-1659.html