【秒杀购物商城业务服务】「分布式架构服务」盘点中间件服务的高可用模式及集群技术的方案分析

本文涉及的产品
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
注册配置 MSE Nacos/ZooKeeper,118元/月
性能测试 PTS,5000VUM额度
简介: 【秒杀购物商城业务服务】「分布式架构服务」盘点中间件服务的高可用模式及集群技术的方案分析

秒杀购物商城业务服务-分布式架构介绍


  • 基于MySQL数据库集群技术实现服务的高可用


  • 基于Tomcat的集群负载机制实现Tomcat服务器的高可用


  • 基于Nginx负载均衡机制实现负载均衡(介绍和配置)


  • 基于Redis缓存服务实现数据缓存控制相关介绍和技术点分析


  • 对未来的分布式技术架构扩展和延伸介绍(包含云原生部分)



基于MySQL数据库集群技术实现服务的高可用


高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用。对于一个系统而言,可能包含很多模块,比如前端应用,缓存,数据库,搜索,消息队列等,每个模块都需要做到高可用,才能保证整个系统的高可用。对于数据库服务而言,高可用可能更复杂,对用户的服务可用,不仅仅是能访问,还需要有正确性保证,因此数据库的高可用需要更加认证对待。


MySQL高可用架构分类


  • MySQL实现高可用之MMM
  • MySQL实现高可用之MHA
  • MySQL实现高可用之主从架构
  • MySQL实现高可用之Cluster模式



MMM的技术分析


MMM(Master-Master replication manager for MySQL)是一套支持双主故障切换和双主日常管理的脚本程序。



MMM的基础组件分析


  • mmm_mond:监控进程,负责所有的监控工作,决定和处理所有节点角色活动。因此,脚本需要在监管上运行。


  • mmm_agentd:运行在每个msql服务器上的代理进程,完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。


  • mmm_control:一个简单的脚本,提供管理mmm_mond进行的命令。



MMM实现基本实现原理


MMM提供了自动和手动两种方式移除一组服务器中复制延迟较高的服务器的虚拟ip,同时它还可以备份数据,实现两节点之间的数据同步等。


MySQL本身没有提供replication failover的解决方案,通过MMM方案能实现服务器的故障转移,从而实现mysql的高可用。



MHA简介


MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司的youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。


MHA的基础组件


MHA由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。

MHA Manager可以单独部署在独立的机器上管理多个master-slave集群,也可以部署在一台slave节点上。


MHA的实现原理


  • MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。


MySQL主从架构


此种架构,一般初创企业比较常用,也便于后面步步的扩展



此架构特点


  1. 成本低,布署快速、方便
  2. 读写分离
  3. 还能通过及时增加从库来减少读库压力
  4. 主库单点故障
  5. 数据一致性问题(同步延迟造成)



MySQL Cluster基本概念


MySQL Cluster简单地讲是一种MySQL集群的技术,是由一组计算机构成,每台计算机可以存放一个或者多个节点,其中包括MySQL服务器,DNB Cluster的数据节点,管理其他节点,以及专门的数据访问程序,这些节点组合在一起,就可以为应用提高可高性能、高可用性和可缩放性的Cluster数据管理;



基于Tomcat的集群负载机制实现Tomcat服务器的高可用



Tomcat集群原理

通过Nginx负载均衡进行请求转发



Tomcat集群能带来什么

  • 提高服务的性能, 并发能力, 以及高可用性
  • 提供项目架构的横向扩展能力


Tomcat集群产生什么问题

  • Session登录信息存储以及读取的问题
  • 服务器定时任务并发的问题



Tomcat 单服务体系架构


在这个架构图中,一层Nginx,首先Nginx主要职责给Tomcat一层反向代理。

image.png

此外,Nginx还可以FTPServer指定的目录再做一层目录转发,保证上传上去的图片实时可以通过http协议访问到。单服务架构先不用考虑集群碰到的各种问题



Tomcat集群"简单版"

image.png

比如,我们的登录的时候登录了A服务器,session信息存储到A服务器上了,假设我们使用的负载均衡策略是ip hash,那么登录信息还可以从A服务器上访问,但是这个有可能造成某些服务器压力过大,某些服务器又没有什么压力,这个时候压力过大的机器(包括网卡带宽)有可能成为瓶颈,并且请求不够分散。



首先要解决Session共享的问题


这时候我们使用轮询或者最小连接负载均衡策略,就导致了,第一次访问A服务器,第二次可能访问到B服务器,这个时候存储在A服务器上的session信息在B服务器上读取不到。



典型负载均衡策略分析


打个比方,我们有轮询,权重,地址散列,地址散列又分为原ip地址散列hash,目标ip地址散列hash,最少连接,加权最少连接,还有继续升级的很多种策略


  • 轮询:优点:实现简单,缺点:不考虑每台服务器处理能力
  • 权重:优点:考虑了服务器处理能力的不同
  • 地址散列:优点:能实现同一个用户访问同一个服务器
  • 最少连接:优点:使集群中各个服务器负载更加均匀
  • 加权最少连接:在最少连接的基础上,为每台服务器加上权值。算法为(活动连接数*256+非活动连接数)/权重,计算出来的值小的服务器优先被选择。



Session管理-Session Sticky粘滞会话:


对于同一个连接中的数据包,负载均衡会将其转发至后端固定的服务器进行处理。


解决了我们session共享的问题,但是它有什么缺点呢?


  • 一台服务器运行的服务挂掉,或者重启,上面的 session 都没了
  • 负载均衡器成了有状态的机器,为以后实现容灾造成了羁绊



Session管理-Session 复制


就是每一个Tomcat都存储我们的Session,不同的tomcat之间进行拷贝复制。


解决了我们session共享的问题,但是它有什么缺点呢?


  • 应用服务器间带宽问题,因为需要不断同步session数据
  • 大量用户在线时,服务器占用内存过多



Session管理-基于Cookie


主要用于我们将session会话如同token一般存储在我们的前端

解决了我们session共享的问题,但是它有什么缺点呢?


  • cookie 的长度限制
  • cookie存于浏览器,安全性是一个问题


Session管理-Session 服务器


就是通过一个专门管理session会话的管理器服务,进行集中化存储和管理session

解决了我们session共享的问题,这种方案需要思考哪些问题呢?保证 session 服务器的可用性,session服务器单点如何解决?


  • 我们在写应用时需要做调整存储session的业务逻辑
  • 打个比方,我们为了提高session server的可用性,可以继续给session server做集群



Tomcat单机部署多应用


  1. 解压2个tomcat, 分别命名为tomcatA和tomcatB
  2. 分别设置2个tomcat的URIEncoding, 将tomcat的conf/server.xml里的port修改为两个不同端口。


image.png

设置tomcat的环境变量


tomcatA的环境变量和以往一样, 不做改变


设置tomcat的环境变量


sudo vim /ect/profile

在profile文件里新增


export CATALINA_BASE=/Users/tomcat/apache-tomcat-9.0.21
export CATALINA_HOME=/Users/tomcat/apache-tomcat-9.0.21
export TOMCAT_HOME=/Users/tomcat/apache-tomcat-9.0.21
复制代码
export CATALINA_2_BASE=/Users/tomcat/tomcat2
export CATALINA_2_HOME=/Users/tomcat/tomcat2
export TOMCAT_2_HOME=/Users/tomcat/tomcat2
复制代码
强制保存退出


继续配置tomcatB下的catalina.sh里的内容,


cd tomcat目录,在# OS specific support. $var must be set to either true or false.下加入。

sudo vi catalina.sh
export CATALINA_BASE=$CATALINA_2_BASE
export CATALINA_HOME=$CATALINA_2_HOME
复制代码
执行刷新环境变量



source /etc/profile

使环境变量生效, 执行


echo $CATALINA_2_BASE

如果有输出, 即环境变量已经生效


/Users/tomcat/tomcat2

分别进入两个tomcat下的bin目录启动tomcat, 正常即可



配置nginx


修改host


sudo vim /etc/hosts

所谓tomcat集群,就是可以向外提供并行服务的多台机器,任何一台服务器宕机,其它服务器可以替代它向外提供服务,而不影响用户访问。


nginx是一个常用的反向代理服务,可自定义模块,实现请求转发及负载均衡(根具体采用策略有关)。为了tomcat集群的高可用性,还需要实现nginx的双机热备。


一,如果仅是对外提供一个页面访问,不用区分单一用户(不区分每个访问session,不涉及用户权限,用户资料等内容),仅仅配置nginx负载均衡策略即可。



nginx负载均衡策略主要分一下四种:


1)、轮询(默认)每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器宕机,能自动剔除。


2)、ip_hash 每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器。


3)、fair 按后端服务器的响应时间来分配请求,响应时间短的优先分配。


4)、url_hash 按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。



二,如果涉及到用户session,做一些鉴权缓存、存放临时信息时,就必须做tomcat的session共享。

目前可参考到的session共享方式主要分为两种。


1)利用tomcat自带的组播机制,实现session复制。


对tomcat及应用的若干配置文件进行配置即可实现,网上有很多资料可参考。但这种方式些弊端,看过一些资料,不建议用session复制的方式。在实际使用过程中,也发现有存在session莫名失踪的现象。


2)利用第三方机制存储session。


比较常见的是tomcat集成memcached服务器来存储session。实际项目中,我们采用过利用redis实现session存储,redis高效的存取性能为高效的访问提供了保障,但是目前redis的集群功能似乎没有发布,如何解决redis的单点故障需要研究。


小结:是否实现session共享与nginx的负载策略有很大关系。比如采用轮询策略,就必须实现session共享,因为客户端会访问到每台服务器;而如果采用ip_hash策略,就可以不用考虑session共享的问题了,但是ip_hash有些缺陷使它不能随便使用(如多台pc使用同一个外网ip)。


最近发现一个nginx的粘连模块(类似session粘连),可以看做nginx的第5种均衡策略。它利用客户端cookie,对其写入一个route参数,每次访问可以根据route的值,固定的访问一台服务器,解决的session共享的问题。




Nginx是什么?


Nginx(发音同 engine x)是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,并在一个BSD-like 协议下发行。由俄罗斯的程序设计师Igor Sysoev(伊戈尔·西索夫)所开发,供俄国大型的入口网站及搜索引擎Rambler(漫步者)(俄文:Рамблер)使用。其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好,中国大陆使用nginx网站用户有:新浪、网易、 腾讯等。



优点


  1. 可运行linux,并有 Windows移植版。
  2. 在高连接并发的情况下,Nginx是Apache服务器不错的替代品Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一。能够支持高达50,000个并发连接数的响应


负载均衡的功能


  • 转发
  • 故障移除
  • 恢复添加
  • 高可用 Ha


我们想要使用Nginx那么就必须满足上面的四个条件. 我们配置负载均衡的目的是在于当用户访问我们的服务器的时候, 首先会通过 Nginx服务器来决定转发到哪个Tomcat服务器上去给用户提供服务, 当然这个概率是我们通过权重来配置的. 经过Nginx指派之后, 我们就可以处理高并发的访问了, 这里就能达到负载均衡的目的.



Nginx如何实现负载均衡


Nginx的负载均衡是通过upstream来实现的,在upstream中指定若干个 server,格式如下:

image.png

myserver就是通过 upstream 定义的一组负载均衡模板,其中:

image.png

在配置完upstream后,还要让客户端过来的请求反向代理到myserver,格式如下:

image.png

完成了负载均衡的配置,但是在实际需求中除了上面的设置外,还会增加一些额外设置:

负载均衡策略设置请求上游服务器携带请求头信息upstream模块中其他参数设置



Nginx的负载均衡策略有5种方式:

image.png


除以上5种,还有一种:least-connected — 下一个请求被分配到拥有最少活动连接数的服务器。

编辑nginx配置文件(例中为/usr/local/ngnix/conf/nginx.conf),找到http结点,



配置案例
http {
    upstream myapp1 {
        server 192.168.1.103:8080;
        server 192.168.1.104:8080;
   }
   server {
        listen 80;
        server_name  localhost;
        location /webautotest/ {
            proxy_buffering off;
            proxy_pass http://myapp1;
        }
    }
}
复制代码
重新加载配置文件
[root@localhost nginx-1.10.0]# /usr/local/ngnix/sbin/nginx -s reload
复制代码



默认的负载均衡配置
http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://myapp1;
        }
    }
}
复制代码



最少连接负载均衡


  • 另一个负载均衡原则为least-connected。当一些请求花费较长时间来完成时,least-connected更“公平”的控制应用程序实例上的负载。
  • 配置了least-connected的负载均衡机制的情况下,nginx会尽量不让负载繁忙的应用服务器上负载过多的请求,相反的,会把新的请求发送到比较不繁忙的服务器。


配置示例:
upstream myapp1 {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
}
复制代码



会话持久性


注意,round-robin或least-connected负载均衡下,每个后续的客户端可能被分发至不同服务器,不保证相同客户端的请求总是被发送到相同的服务器。

如果有必要把客户端绑定至特定服务器,则可使用ip-hash负载均衡机制。


ip-hash机制


ip-hash机制下,客户端ip地址被用作hash key来判断客户端请求应该发送到哪个服务器,这种方法保证了来自相同客户端的请求总是发送到相同服务器(如果服务器可用的话)

upstream myapp1 {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}
复制代码



负载均衡权重


可通过配置服务器权重来影响负载均衡机制。上面的例子中,都未配置服务器权重,这意味着所有服务器都拥有相同的权重。 针对round-robin负载机制,权重意味着更多或更少的请求传送至服务器---假设有足够的请求,且按统一方式处理请求,且足够快完成请求处理。



配置示例:
upstream myapp1 {
        server srv1.example.com weight=3;
        server srv2.example.com;
        server srv3.example.com;
}
复制代码

上例配置中,每发送至服务器实例的5个新的请求中,有3个发送到srv1,1个发送到srv2,另1个发送到srv3。


注:当前版本似乎只实现了round-robin机制下的权重设置




健康检测


  • nginx反向代理实现包含服务器健康检查。如果来自特定服务器的响应失败,报错,nginx将标记该服务器为failed,一段时间内尽量避免选择此服务器作为随后请求的分发服务器。


  • max_fails机制设置fail_timeout期间,和服务器沟通失败的连续重试次数,默认为1.当设置为0时,不做服务器健康检测。fail_timeout定义了服务器被标记为failed的时长。fail_timeout时间间隔过后,nginx将开始使用活动客户端请求来探测服务器,如果探测成功则标记服务器为活动服务器。



Nginx负载均衡配置项介绍


下面我们将介绍一下proxy模块的参数:

image.png

各个参数介绍:

image.png

设置proxy_connect_timeout 为2秒,缩短超时时间,使其不至于太慢。




相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
2天前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
29 11
|
4天前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
26 11
|
6天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
40 11
|
8天前
|
自然语言处理 负载均衡 Kubernetes
分布式系统架构2:服务发现
服务发现是分布式系统中服务实例动态注册和发现机制,确保服务间通信。主要由注册中心和服务消费者组成,支持客户端和服务端两种发现模式。注册中心需具备高可用性,常用框架有Eureka、Zookeeper、Consul等。服务注册方式包括主动注册和被动注册,核心流程涵盖服务注册、心跳检测、服务发现、服务调用和注销。
42 12
|
16天前
|
存储 算法 安全
分布式系统架构1:共识算法Paxos
本文介绍了分布式系统中实现数据一致性的重要算法——Paxos及其改进版Multi Paxos。Paxos算法由Leslie Lamport提出,旨在解决分布式环境下的共识问题,通过提案节点、决策节点和记录节点的协作,确保数据在多台机器间的一致性和可用性。Multi Paxos通过引入主节点选举机制,优化了基本Paxos的效率,减少了网络通信次数,提高了系统的性能和可靠性。文中还简要讨论了数据复制的安全性和一致性保障措施。
33 1
|
24天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
49 8
|
20天前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
19天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
28天前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
42 3
|
1月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####