一、微服务部署
设计方案
1、先采用微服务架构设计,将工程拆分成多个模块(通过接口彼此调用,降低代码的耦合度)
2、后采用分布式工作方式将拆分开的各个模块分别部署到多台服务器上(通过缩短单个任务的执行时间来提升效率)
3、再采用集群物理方式将各个模块部署到多台服务器上(通过提高单位时间内执行的任务数量来提升效率)
服务器分配示例
微服务 | 分布式 | 集群 |
---|---|---|
登录服务 | A0服务器 | A1服务器 A2服务器 A3服务器 … |
订单服务 | B0服务器 | B1服务器 B2服务器 B3服务器 … |
用户服务 | C0服务器 | C1服务器 C2服务器 C3服务器 … |
后台服务 | D0服务器 | D1服务器 D2服务器 D3服务器 … |
… | … | … |
准备一台响应服务器,然后由多台服务器集群完成同一个任务,使用负载均衡机制分派请求。
实现 Nginx 集群部署的方案有很多,以下是一种常见的方案:
- 负载均衡:在 Nginx 中使用负载均衡模块,将请求分摊到多台服务器上。
- 前端代理:在 Nginx 中使用前端代理,将请求转发到后端的服务器集群中。
- 分布式存储:使用分布式存储方案,例如 GlusterFS,实现文件系统的高可用性。
- 数据库集群:使用数据库集群,例如 MySQL Cluster,实现数据库的高可用性。
- 容错:使用容错技术,例如 Keepalived 和 VRRP,实现 Nginx 集群的高可用性。
二、Mysql服务部署
背景
MySQL是一种流行的关系型数据库管理系统,被广泛应用于各种Web应用和企业级应用中。随着数据量和访问量的不断增加,单点MySQL数据库已经无法满足高可用、高性能和高扩展性的需求,因此MySQL集群和分布式成为了常见的解决方案。
分布式
MySQL分布式是一种将数据分布在多个MySQL服务器上的解决方案。它通过使用分片和数据分区等技术,实现数据的横向扩展和负载均衡。
MySQL分布式通常包括以下组件
- MySQL服务器:提供数据库服务的主要组件。
- 数据分片:将数据拆分成多个片段,分别存储在不同的MySQL服务器上,以实现数据的横向扩展。
- 负载均衡器:将客户端请求分配到不同的MySQL服务器上,以实现负载均衡和高可用。
优缺点
优点:可以提供高可用,相比于MySQL集群,MySQL分布式的部署和维护相对简单,成本也相对较低。
缺点:
- 数据一致性问题:MySQL分布式中的数据分片可能会出现数据不一致的问题。
- 分片策略问题:如何进行数据分片和数据分区是一个比较复杂的问题,需要根据具体的应用场景进行选择。
- 难以扩展:一旦分片策略确定,就难以进行扩展或修改。
集群
MySQL集群是一种将多个MySQL服务器组合成一个虚拟数据库的解决方案。它通过使用复制和分片等技术,实现数据的高可用。
MySQL集群通常包括以下组件
- MySQL服务器:提供数据库服务的主要组件。
- 数据复制:将数据从一个MySQL服务器复制到另一个MySQL服务器,以实现数据的备份和读写分离等功能。
- 数据分片:将数据拆分成多个片段,分别存储在不同的MySQL服务器上,以实现数据的横向扩展。
- 负载均衡器:将客户端请求分配到不同的MySQL服务器上,以实现负载均衡和高可用。
优缺点
优点:
- 高可用性:故障检测及迁移,多节点备份。
- 可伸缩性:新增数据库节点便利,方便扩容。
- 负载均衡:切换某服务访问某节点,分摊单个节点的数据库压力。
缺点:
- 部署和维护比较复杂,需要专业的技术人员。
- 数据一致性问题:MySQL集群中的数据复制可能会出现延迟和不一致等问题。
- 成本较高:需要购买多个MySQL服务器和负载均衡器等硬件设备。
1、读写分离集群模式
优点:适用于读多写少的应用,可以分摊数据库的压力,可以配合MHA中间件方案实现高可用。
特点:每个节点的数据量都是一样的,因为是通过数据冗余实现主从分离的。
如果数据量很大的话,单机压力会变得很大,所以这里我们可以使用分库分表集群模式。
2、分表分库集群模式
优缺点:适用于十几亿数据总量的大型应用,不具备高可用性,某一台分片服务器挂掉后,会查询不到数据。
特点:每个分片的数据都不一样。
分片的算法有:范围法和hash法。
1)范围法
非常容易理解,就是按照范围进行分片。
优点:结构简单,拓展容易
缺点:数据分布不均衡,数据的局部负载压力大。
2) hash法
hash最大的优点就是:数据分配均衡,缺点就是:节点扩展复杂数据迁移的难度大。
所以一般采用hash算法,都会建议:提前部署足够多的节点。
3、主流的Mysql集群架构
采用读写分离和分片法的组合应用,如下:
集群架构原理
MySQL Cluster由一组计算机组成,每台计算机上均运行多种进程,包括MySQL服务器,管理服务器,MySQL Cluster数据节点,以及(可能)专门的数据访问应用程序。
MySQL群集分为三种节点:管理节点,数据节点和SQL节点。
- 管理节点
MySQL全局的管理者,起到联系并管理整体架构的作用,整个集群只有一个管理节点,控制其他节点启停,查看节点状态等。主要用于管理各个节点,也能够监视全部节点的工作状态。 - 数据节点
用于存储数据,集群中有多个数据节点,每个数据节点都会存储所有数据。这样当一个数据节点宕机后,还会有其他的数据节点存储数据,系统仍然可以继续使用。 - SQL节点
负责与WEB应用程序交互,承接来自上层的SQL命令,主要是对外提供SQL功能,类似一台普通的MySQL Server。在任意一个SQL节点上的命令都会在系统中生效,从而可以起到互相备份和负载分担的作用,可以防止单点故障。
集群和分布式应用场景
MySQL集群和分布式的应用场景主要包括以下几个方面:
- 高可用:当单点MySQL服务器出现故障时,MySQL集群和分布式可以自动切换到备用服务器,保证系统的高可用性。
- 高性能:当访问量较大时,MySQL集群和分布式可以通过负载均衡和数据分片等技术,提高系统的性能和响应速度。
- 高扩展性:当数据量和访问量不断增加时,MySQL集群和分布式可以通过添加更多的MySQL服务器,实现系统的横向扩展。
总之,MySQL集群和分布式是解决MySQL数据库高可用、高性能和高扩展性的常见解决方案。在选择哪种方案时,需要根据具体的应用场景和需求进行选择。
三、Redis服务部署
单机Redis产生的问题
- 单点故障(当redis挂掉,就会导致整个系统不可用)
- 单节点容量有限(太多内存数据,一台服务器处理不过来)
- 单节点访问压力,IO压力太大(太多请求,一台服务器搞不定)
1、主从复制
主从同步,读写分离,主备切换。
优点:
- 主机会自动将数据同步到从机,实现读写分离,提高了可用性,解决了单机故障。
- 主从复制期间master和slave都是非阻塞方式,仍然可用。
缺点:
- 在线扩容较难,在集群容量达到上限时在线扩容会变得很复杂。
- 不具备自动容错和恢复功能,主机从机的宕机都会导致前端部分读写请求失败,需要等待机器重启或者手动切换前端的IP才能恢复。
- master主机宕机,宕机前有部分数据未能及时同步到从机,切换IP后还会引入数据不一致的问题,降低了系统的可用性。
- slave从机宕机后,多个slave恢复后,大量的SYNC同步会造成master IO压力倍增(可以手动规避启动时间)
2、哨兵模式
自动化的系统监控和故障恢复功能。
Sentinel 哨兵模式是为了弥补主从复制集群中主机宕机后,主备切换的复杂性而演变出来的。哨兵顾名思义,就是用来监控的,主要作用就是监控主从集群,自动切换主备,完成集群故障转移。
优点:哨兵模式是基于主从模式的,所有主从的优点,哨兵模式都具有。主从可以自动切换,系统更健壮,可用性更高。
缺点:比较难扩容,服务占用空间比较多。
哨兵模式虽然已经可以实现高可用,读写分离,但还是存在几个方面的不足:
1.哨兵模式下每台 Redis 服务器都存储相同的数据,很浪费内存空间;数据量太大,主从同步时严重影响了 master 性能。
2.哨兵模式是中心化的集群实现方案,每个从机和主机的耦合度很高,master 宕机到 slave 选举 master 恢复期间服务不可用。
3.哨兵模式始终只有一个 Redis 主机来接收和处理写请求,写操作还是受单机瓶颈影响,没有实现真正的分布式架构。
3、Redis-Cluster集群
cluster 模式是redis官方提供的集群模式,使用了Sharding 技术,不仅实现了高可用、读写分离、也实现了真正的分布式存储。
Redis Cluster 集群具有如下几个特点:
- 集群完全去中心化,采用多主多从;所有的 redis 节点彼此互联(PING-PONG 机制),内部使用二进制协议优化传输速度和带宽。
- 客户端与 Redis 节点直连,不需要中间代理层。客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
- 每一个分区都是由一个 Redis 主机和多个从机组成,分片和分片之间是相互平行的。
- 每一个 master 节点负责维护一部分槽,以及槽所映射的键值数据;集群中每个节点都有全量的槽信息,通过槽每个 node 都知道具体数据存储到哪个 node 上。
Redis cluster 主要是针对海量数据 + 高并发 + 高可用的场景,海量数据,如果你的数据量很大,那么建议就用 Redis cluster,数据量不是很大时,使用 sentinel 就够了。Redis cluster 的性能和高可用性均优于哨兵模式。
原文链接:https://www.cnblogs.com/zhaojinhui/p/17415493.html