分布式架构 - 分布式架构设计的特征与问题_分布式架构、缓存金融业务详解-CSDN博客

本文链接：https://blog.csdn.net/yangshangwei/article/details/143990498

文章目录

架构设计的演进过程
分布式架构的组成
分布式架构的特征
分布式架构的问题

在这里插入图片描述

架构设计的演进过程

架构设计的演进历程其实是业务需求不断变化的映射。随着业务量的逐渐增大，传统的单体架构已经无法满足高并发、高可用以及高扩展性的需求。
在这里插入图片描述

接下来我们来一起回顾架构演进的几个主要阶段，剖析每一步如何提升系统性能、可用性及可扩展性，并解决相应的挑战。

1. 应用与数据一体模式

架构演进的第一步是应用与数据一体模式。在初期，业务简单、用户量少，单台服务器即可承载应用和数据库。虽然这种模式在早期满足了需求，但缺乏高并发支持和良好的可用性，一旦服务器故障，所有业务应用都会中断。

在这里插入图片描述

2. 应用与数据分离模式

随着用户请求增多，服务器性能成为瓶颈。为解决此问题，将应用服务器和数据库服务器分离，应用服务器专注业务逻辑处理，而数据库服务器专注于数据存储和索引。这样实现了应用和数据的硬件分离，性能大幅提升。

在这里插入图片描述

3. 缓存与性能的提升

在高频访问的场景下，数据库逐渐成为瓶颈。引入缓存技术有效缓解了这个问题。缓存技术包含客户端缓存、应用服务器本地缓存以及缓存服务器的缓存。缓存数据存储于内存中，相较于磁盘IO性能更优，大大提高了数据的访问速度，降低了数据库负载。

在这里插入图片描述

4. 服务器集群处理并发

伴随业务发展，单台服务器无法应对高并发需求，因此架构开始向服务器集群演进。通过负载均衡器，将请求均匀分发到多台服务器，形成“集群效应”。这类似于银行柜台的多窗口服务，通过增加服务器数量处理更多用户请求，提升系统并发处理能力。

在这里插入图片描述

5. 数据库读写分离

在数据库层面，引入读写分离进一步提升了性能。主库负责写操作，数据实时同步到从库，从库则承担大部分读操作。这种方式极大优化了数据库的读写效率，适合读多写少的业务场景。同时还需考虑数据同步的可靠性与故障恢复的处理机制。

在这里插入图片描述

6. 反向代理和CDN

为应对网络安全和用户体验问题，加入了反向代理和CDN。反向代理隐藏了应用服务器，提升安全性。而CDN（内容分发网络）将静态资源分发到距离用户最近的节点上，提升响应速度。通过这两项技术的结合，用户访问体验显著提升，系统的安全性也得到了保障。

在这里插入图片描述

7. 分布式数据库与分表分库

当数据量增长到单库无法承载时，分布式数据库与分表分库成为最佳选择。通过将数据拆分到多张表或多个库中，不同业务可以访问不同的数据库，减轻了数据库负载压力。此过程引入数据库中间件解决数据同步和一致性问题，提升系统的数据处理能力。

在这里插入图片描述

8. 业务拆分

业务复杂度提升后，对业务的拆分成为架构演进的重要手段。将业务应用划分为独立服务，例如商品服务、订单服务等，按业务需求水平扩展各服务。此时，应用间的调用、通信变得复杂，因此引入了消息队列、服务注册和发现等中间件。

在这里插入图片描述

9. 分布式与微服务

在这里插入图片描述

微服务架构进一步细化了系统，将业务分解成独立模块，实现模块间的高内聚低耦合。每个模块可独立开发、部署、扩展，使得技术栈更为灵活，适应快速变化的业务需求。这种架构使各模块问题互不干扰，提升了系统的弹性和容错能力。

在这里插入图片描述

10. 容器化和编排

随着架构的复杂性增加，服务的部署、扩展和维护变得愈发复杂。此时，容器化技术（如Docker）和编排工具（如Kubernetes）应运而生。容器化将应用及其依赖打包成轻量级、独立的容器，保证“开发环境即生产环境”，从而提高了应用的可移植性和一致性。Kubernetes等编排工具则能够高效管理大量容器，实现容器的自动部署、扩缩、监控和故障自愈。

容器化和编排技术的引入，大大提高了资源利用率，使系统扩展更加灵活，有助于支持微服务架构下的服务弹性伸缩和独立更新，降低了应用的部署和运维成本。

11. 云原生架构

在容器化和编排基础上，架构进一步发展到云原生架构，其核心原则包括容器化、动态编排、微服务化和持续交付。云原生架构专为云环境设计，能够充分利用云计算的弹性和分布式特性。通过依托云平台的基础设施和服务，云原生架构可以实现快速迭代、自动化扩展和自愈能力。核心技术栈通常包括Kubernetes、Service Mesh、CI/CD流水线、云存储、云数据库等。

云原生架构能够帮助企业更敏捷地响应市场需求的变化，适应快速变化的业务环境。它也成为企业大规模分布式系统的标准模式，加速了业务创新的同时，确保了系统的稳定性和可扩展性。

12. Serverless 架构

Serverless架构（无服务器架构）更进一步，开发者无需管理底层的服务器或基础设施，专注于业务逻辑的实现。Serverless的关键概念是“按需执行”，只有在有请求触发时才会启动函数处理，实现了“按使用付费”的模式，极大节约了成本。典型的Serverless服务包括AWS Lambda、Google Cloud Functions、Azure Functions等。

在Serverless架构中，资源的调度、扩展、管理完全由云服务商负责，应用的扩展性和资源利用率达到最优。这种架构适合于短周期、事件驱动的场景，适合业务峰值和谷值明显、对延迟要求不高的系统，比如数据处理、实时日志分析和Webhooks服务等。

小结

从传统的单体架构到云原生和Serverless架构，架构设计的演进反映了互联网行业从简单到复杂、从集中到分布的过程。无论是通过容器化和编排技术解放运维，还是通过云原生和Serverless实现资源最大化利用，这些架构都在帮助企业更好地应对现代业务的动态变化需求。未来，随着技术的进一步发展，架构可能会在AI与自动化驱动下朝更高效、更智能化的方向演进。

通过合理选择适合自身业务的架构，企业能够在应对复杂技术挑战的同时，保持对新兴市场需求的敏捷响应力。这一系列的架构演进，不仅仅是对技术的优化，更是对业务创新和用户体验的持续提升。

在这里插入图片描述

分布式架构的组成

软件架构的演进历史，说明了软件架构是沿着高性能、高可用、可扩展、可伸缩、够安全的方向发展的，其中最重要的是高性能和高可用。在分布式时代，服务的分布式部署还带来了一系列其他问题，诸如服务的拆分、调用、协同以及分布式计算和存储。

分布式架构的精妙之处在于：它的多组件合作方式使得整个系统能够高效地处理成千上万的用户请求，同时保障系统的稳定性和可扩展性，如图所示
在这里插入图片描述

接下来我们通过一个简单的分布式示例来解分布式架构的特征和问题，然后针对发现的问题进行拆解，找到解决方案

首先介绍一下例子的业务流程：浏览商品，下单、付款以及扣减库存，最后通知用户的整个过程。

系统架构会根据以上业务提供对应服务：在用户通过商品服务浏览商品，通过订单服务下单，通过支付服务付款以后，会通知库存服务扣减相应的库存，订单完成以后，通知服务会向用户发送订单完成的消息.

接下来会以架构分层为主线，介绍技术实现以及在分布式架构中会遇到的问题

架构概述与分层

在这里插入图片描述

为了完成上面的订单业务流程，将分布式系统分为了四层

客户端

这是用户与系统之间的接口，用户在这里可以浏览商品信息，并且对商品下单。为了提升用户体验，会利用 HTTP 缓存手段将部分静态资源缓存下来，同时也可以将这部分静态资源缓存到 CDN 中，因为 CDN 服务器通常会让用户从比较近的网络节点获取静态数据

负载均衡器

以下称接入层 , 分布式应用会对业务进行拆分，并将拆分后的业务分别部署到不同系统中去，又或者使用服务器集群分担请求压力。

假设我们的案例使用的是服务器集群，这里分别为华南和华中地区的用户设置两个应用服务器集群，那么负载均衡器可以通过用户 IP 将用户的请求路由到不同的服务器集群。另外，在负载均衡这一层，还可以进行流量控制和身份验证等操作

应用服务器

以下称应用层 . 这一层用于部署主要的应用服务，例如商品服务、订单服务、支付服务、库存服务和通知服务。这些服务既可以部署到同一台服务器上，也可以部署到不同服务器上。

当负载均衡器将请求路由到应用服务器或者内网以后，会去找对应的服务，例如商品服务。当请求从外网进入内网后，需要通过 API 网关进行再次路由，特别是微服务架构中服务拆分得比较细，就更需要 API 网关了。

API 网关还可以起到内网的负载均衡、协议转换、链式处理、异步请求等作用。由于应用服务（一个或者多个）部署在多个服务器上，这些服务器要想互相调用，就要考虑各服务间的通信、协调等问题，因此加入了服务注册中心、消息队列消息中心等组件。

同时由于商品服务会经常被用户调用，因此加入了缓存机制。

数据服务器

以下称存储层 . 由于商品信息比较多，所以对其进行分片操作，分别存放到商品表 1 和商品表 2 这两张表中来保证数据库的可用性。这里加入了主、备数据库的设计，这两个数据库服务器会进行同步，当主数据库服务器挂掉的时候，备数据库服务器就会接管它的一切。

客户端与 CDN

为了优化电商网站中商品信息的访问效率，尤其是对于那些访问频繁但变更不频繁的内容，如商品描述和图片，可以通过HTTP缓存机制减轻服务器的负担。

在用户第一次发出请求的时候，客户端缓存会判断是否存在缓存，如果不存在，则向应用服务器发出请求，此时应用服务器会提供数据给客户端，客户端接收数据之后将其放入缓存中。当用户第二次发出同样的请求时，客户端缓存依旧会判断是否存在缓存。由于上次请求时已经缓存了这部分数据，因此由客户端缓存提供数据，客户端接收数据以后返回给用户。

在这里插入图片描述

备注：图中实线部分表示没有缓存的流程，虚线部分表示存在缓存的流程。

HTTP 缓存主要是对静态数据进行缓存，把从服务器拿到的数据缓存到客户端/浏览器中。如果在客户端和服务器之间再加上一层 CDN，就可以让 CDN 为应用服务器提供缓存，有了 CDN 缓存，就不用再请求应用服务器了。因此可以将商品的基本描述和图片等信息放到 CDN 中保存，还可以将一些前端通用控制类的 JavaScript 脚本也放在里面。需要注意的是，在更新商品信息（例如商品图片）时，需要同时更新 CDN 中的文件和 JavaScript 文件.

HTTP 缓存机制

HTTP 缓存机制允许客户端（例如浏览器）对请求的资源进行本地缓存，以减少对服务器的重复请求。HTTP 缓存主要通过以下两个策略来实现：

强制缓存：如果某些资源（如图片、商品描述等）不经常更新，服务器可以在返回这些资源时设置缓存头，让浏览器在未来的某段时间内直接从本地缓存中获取资源而不再请求服务器。
- Cache-Control：通过在响应头中设置Cache-Control: max-age=3600等指令，可以指定资源的缓存时间，在此期间客户端可以直接从缓存中获取资源而不发起新的请求。
- Expires：Expires用于指定资源的过期时间，达到过期时间之前浏览器将直接使用缓存，过期后需要重新请求资源。
协商缓存：当资源可能发生更新（例如商品价格或库存量）时，可以利用协商缓存来减少不必要的数据传输。协商缓存不会完全依赖本地缓存，而是会在请求时向服务器询问资源是否已发生变化。
- ETag：服务器生成资源的唯一标识符，返回时在响应头中包含ETag。当浏览器再次请求该资源时，会将该标识符附加在If-None-Match头中发送给服务器。服务器比对后，如果资源未变动，则返回304状态码，让浏览器继续使用本地缓存；如果资源已变动，则返回新的资源和ETag。
- Last-Modified：表示资源的最后修改时间，配合If-Modified-Since头一起使用。浏览器请求资源时会携带此时间，服务器判断后返回相应的状态码和资源。

适用的缓存策略选择

图片、描述等静态资源：这些资源变动较少，可以使用强制缓存策略，通过Cache-Control来设定适当的缓存时长（如1小时或1天），减少对服务器的请求。
价格、库存等动态资源：由于价格和库存可能频繁变化，建议使用协商缓存。这样客户端仍然可以从缓存中读取数据，但在每次请求时会与服务器进行简单的缓存验证，确保用户看到的是最新的数据。

缓存的具体实现步骤

配置HTTP头部：在应用服务器中，根据商品数据的不同类别为静态和动态资源设置合适的缓存头。
优化缓存更新策略：对于商品信息更新，可以采用缓存失效策略，例如商品发生更新时清除客户端缓存或更新ETag，以确保用户能获取到最新的信息。
定期缓存刷新：通过设置缓存的生命周期，并在生命周期结束时刷新缓存，避免缓存信息过期后用户体验受到影响。

缓存策略的优点

提高加载速度：用户访问页面时无需重复请求静态内容，从而提高页面响应速度。
减少服务器负载：避免重复查询数据库和加载资源，减轻服务器的计算和带宽压力。
降低用户流量消耗：缓存机制减少了网络请求的次数，节约了客户端的流量资源。

注意事项

在使用缓存机制时需要注意平衡缓存命中率和数据一致性，避免缓存过期导致的数据更新不及时问题。对高更新频率的数据，可以设置较短的缓存时间或使用协商缓存策略，以确保数据的新鲜度。

接入层

反向代理服务器的作用

直接将应用服务器暴露在互联网上存在安全隐患，可能导致服务器受到恶意攻击或因流量暴增而出现性能瓶颈。为了解决这个问题，反向代理服务器被引入到架构中。反向代理服务器的主要功能包括：

隐藏应用服务器：通过让客户端的请求首先进入反向代理服务器，然后由反向代理服务器将请求转发给内部的应用服务器，实现应用服务器的 IP 隐藏。
流量调度：反向代理可以根据用户的地理位置将请求分配到距离用户较近的服务器，从而提升访问速度。例如，华中和华南地区的用户可以分别访问部署在不同区域的反向代理服务器，减少跨区域的数据传输延迟。
负载均衡的入口：反向代理服务器作为对外的访问入口，还能与负载均衡器协同工作，将请求均匀地分发到多个应用服务器上，确保系统在高并发情况下的稳定性。

负载均衡器的作用

当用户的请求通过反向代理服务器后，将进入内部的负载均衡器，负责将请求分发到适当的应用服务器上。负载均衡器不仅提高了系统的可靠性和可扩展性，还具备限流和高可用性功能，尤其在集群部署中至关重要。负载均衡器的主要作用包括：

分发请求：负载均衡器根据设定的算法（如轮询、加权轮询、最小连接数等），将请求分配到负载相对较轻的服务器节点上，实现均匀负载。
提升系统性能：通过将流量分散到多台应用服务器上，避免单一服务器因请求过多而发生性能瓶颈，从而提升系统的整体处理能力。
限流保护：当请求量超出系统负载时，负载均衡器可以限制流量，将多余的请求阻挡在系统之外，防止后端服务被过多请求压垮。

用户请求流程

客户端请求：用户在浏览器中输入商品页面的 URL，浏览器向 DNS 服务器发送域名解析请求。
DNS 解析：DNS 服务器根据域名查询并返回与之对应的反向代理服务器的 IP 地址。
反向代理服务器接收请求：客户端向反向代理服务器发出商品信息请求。反向代理服务器会根据用户的地理位置（例如华中或华南地区）选择最优的代理服务器节点，并接收并转发请求。
负载均衡器分发请求：反向代理服务器接收到请求后，将其转发给负载均衡器。负载均衡器根据设定的负载均衡算法选择最佳的应用服务器集群节点，并将请求分配到该节点。
集群应用服务器处理请求：应用服务器接收到请求后，从数据库或缓存中读取商品信息，进行相应的处理并返回数据给客户端。

负载均衡算法及限流功能

负载均衡器在请求分发的过程中，可以选择不同的算法以实现不同的优化效果：

轮询算法：每个服务器节点依次轮询接收请求，适用于性能相似的服务器。
加权轮询：为每个服务器分配不同的权重，根据权重将请求分配到不同的服务器，适用于性能差异较大的服务器环境。
最小连接数：将请求分配给当前连接数最少的服务器，适用于长连接的请求。

此外，限流功能通过设置请求的最大并发数和频率，防止突发流量对系统造成冲击，从而提高系统的稳定性。

总结

反向代理与负载均衡是现代分布式架构的重要组件，前者实现了请求入口的安全性和区域优化，而后者则负责均衡负载与流量控制。两者的结合可以显著提升系统的响应速度、安全性和扩展能力，为用户提供更加流畅和可靠的访问体验。

应用层

随着微服务架构的广泛应用，业务功能被拆分成细粒度的服务模块。每个服务模块各司其职，如商品服务、订单服务、支付服务、库存服务和通知服务等。各模块间的协同和服务调用既需保持高效，又必须兼顾系统的稳定性、可用性和安全性。

下面，我们从 API 网关、服务协同与通信、分布式互斥、分布式事务四个方面来详细分析应用层的实现。

1. API 网关

在微服务架构中，API 网关是用户请求与后端服务之间的重要入口。它承担着流量控制、路由、协议转换和安全鉴权等多项职责，类似于一个流量调度和管理的“水阀”。用户的请求需经过 API 网关，网关将请求分发到正确的服务。

在这里插入图片描述

请求路由：API 网关根据用户的请求，将其分发到正确的后端服务。例如，用户的商品浏览请求会通过 API 网关找到对应的商品服务模块。对外，网关提供统一的访问入口，屏蔽了服务细节；对内，则根据请求类型将请求路由至合适的服务节点。
负载均衡：在分布式系统中，热门服务（如商品服务）通常会进行水平扩展，即将同一个服务复制为多个实例来提升处理能力。API 网关可以在多个商品服务实例之间均衡分发请求，减轻单个实例的负载压力。
安全鉴权：当用户进行敏感操作（如下单）时，API 网关会负责对用户身份进行鉴权，确保只有合法的用户才能访问或操作相关服务。这一鉴权流程往往通过 OAuth 或 JWT（JSON Web Token）等机制实现。
协议转换：微服务体系中的服务可能采用不同的技术栈和通信协议。API 网关能够在服务之间进行协议转换，以确保服务之间的兼容性。例如，如果订单服务调用库存服务和支付服务时采用的协议不同，API 网关可以在这两者间实现协议转换。
限流和熔断：API 网关在大量用户访问时可以进行流量控制，防止请求过载。例如，在秒杀活动或促销活动期间，API 网关通过限流机制，限制流量大小，保护后端服务不被过量请求压垮。当部分服务不可用时，还可启用熔断机制，迅速切断对这些服务的调用，提升系统整体的容错性。
日志记录：API 网关记录用户请求的相关日志数据，便于运维监控、性能分析及异常排查。这些日志为系统运维提供了丰富的信息来源，能有效提升系统的可观测性和维护性。

在这里插入图片描述

在这个过程中，API 网关的角色类似于一个水流控制阀门：控制流量的大小、流向，保证系统的正常运转。

2. 服务协同与通信

常用的服务通信方式：

HTTP/REST：一种简单、广泛使用的同步通信方式，适用于服务之间的简单请求响应。
RPC（Remote Procedure Call）：例如 gRPC 等，适用于需要高性能、低延迟的场景。通过序列化的二进制传输格式和强类型的接口定义，提升了通信效率。
消息队列（MQ）：适用于异步通信的场景，能降低服务之间的耦合性。服务通过消息队列发布和订阅消息，实现服务间的数据传输和业务事件通知。常见的消息队列包括 RabbitMQ、Kafka 等。

通过选择合适的通信方式，微服务之间的相互依赖变得更可控，尤其在数据同步、事件驱动等场景中，消息队列还能提升系统的整体响应速度和容错性。

3. 分布式互斥

在分布式环境中，多个服务节点可能会尝试同时修改相同的数据，这就引发了分布式锁的需求。以下是几种常见的分布式互斥实现方法：

基于 Redis 的分布式锁：通过 Redis 的原子性操作实现分布式锁。服务节点在 Redis 中设置一个键（key）作为锁的标志，利用 Redis 的 SETNX 操作保证锁的原子性和唯一性。
基于 Zookeeper 的分布式锁：Zookeeper 提供了强一致性的节点状态同步，可以利用其有序节点实现分布式锁，尤其适用于多方竞争的场景。
基于数据库的分布式锁：通过数据库的乐观锁或悲观锁机制来实现。例如，通过表记录的 version 字段来保证更新操作的唯一性，但这种方式往往会造成数据库压力，不适合高并发场景。

分布式锁确保了分布式环境下资源的独占性，有助于避免“脏数据”或“数据丢失”问题。

4. 分布式事务

在微服务中，不同服务之间的事务性操作需要保证一致性。由于分布式系统的复杂性，常用的分布式事务模式包括以下几种：

两阶段提交（2PC）：协调者服务在所有服务节点上预留资源，确认所有服务都准备就绪后再提交事务。这种方式保证了分布式一致性，但会导致较高的网络延迟，且在规模扩大时性能欠佳。
三阶段提交（3PC）：在两阶段提交的基础上增加了一个准备阶段，确保事务在节点间的预留状态更明确。三阶段提交适合对事务要求高的一些金融业务，但实现复杂度较高。
柔性事务（TCC）：TCC 模式将事务拆分为三个步骤：Try（预留资源）、Confirm（确认资源）和 Cancel（取消操作）。它能较好地控制事务性操作的各步骤，更适合高并发环境下的业务场景。
事件驱动的最终一致性：利用消息队列或事件总线，以“最终一致性”为目标实现事务性控制。通过补偿机制或重试机制，保证不同服务在事务完成后最终达到一致性。

这些分布式事务方案在保证数据一致性的同时，平衡了系统的可用性和性能。

小结

应用层包含了各种细粒度的服务模块，为确保系统的性能和安全，引入了 API 网关、服务协同与通信、分布式互斥和分布式事务等设计。API 网关负责流量管理、协议转换和安全鉴权，负载均衡器与分布式锁机制保护系统的稳定性，而分布式事务控制了跨服务操作的数据一致性。

在此架构下，各个服务既能相互协作，又保持了高度的独立性，有效支持电商系统在高并发场景下的业务需求。这些设计不仅提升了系统的可扩展性，也为未来的功能迭代和业务拓展打下了坚实基础。

存储层

在分布式系统中，存储层是关键的数据支撑部分。它不仅需要应对高并发请求，还需保证数据的高可用性和一致性。针对电商系统的特点，分布式存储设计通常采用数据分片、读写分离和主从同步等策略。

下面我们详细分析每种策略的实现方式和作用。

1. 分布式存储与数据分片

分布式存储的一个基本需求是解决海量数据的存储和访问性能问题。将大表按一定规则分片存储在不同的数据库和服务器上，是一种常见的优化手段。

在这里插入图片描述

数据副本：

在这里插入图片描述

例如，对于电商系统中数据量巨大的商品表，可以通过数据分片技术将其分配到多个数据库中，以减轻单一数据库的负担，并提升数据查询性能。以下是常用的数据分片方式：

基于范围的分片：将数据按某个字段的范围进行划分，例如商品 ID 为 1~500 的记录存储在商品表 1，而 ID 为 501~1000 的记录存储在商品表 2。查询时根据商品 ID 的范围选择对应的表，可以减小单表数据量，提升查询效率。
基于哈希的分片：通过哈希函数对某个字段（如商品 ID）进行哈希运算，将数据分散到多个表或数据库中。这种方式可以实现较为均匀的数据分布，有效降低单库、单表的访问压力。
基于其他业务维度的分片：可以根据业务需求按区域、品类等维度分片。例如，可以将商品表按品类划分到不同的数据库，以便不同品类的商品信息查询请求可以分散到多个数据库，从而平衡访问负载。

在此架构中，中间件如 MyCat 可以充当数据库代理。MyCat 会解析接收到的 SQL 请求，并根据数据分片规则将查询或写入操作路由到对应的数据库。例如，若商品 ID 为 100，MyCat 知道它在 ID 为 1~500 的分片范围内，因此会将查询请求路由到存储该范围数据的数据库中。通过 MyCat 实现的数据分片和路由机制，开发者无需关心数据的存储位置，简化了代码逻辑。

在这里插入图片描述

2. 读写分离与主从同步

在电商系统中，商品数据的读操作远多于写操作。为了进一步提升查询性能和系统的可用性，可以采用读写分离和主从同步模式：

读写分离：将数据库的写入操作和读取操作分配到不同的数据库实例。主节点（writeHost）负责写操作，从节点（readHost）负责读操作。这样做的好处是，读请求被分流到只读实例，从而减轻主节点的压力，提升系统的整体查询性能。
主从同步：当主节点完成写入操作后，会将数据同步到从节点，保证从节点的数据与主节点一致。通过主从复制，从节点能及时接收到主节点的更新数据，从而保证查询到的数据是最新的。MyCat 数据库中间件支持读写分离模式，并利用 ZooKeeper 进行主从节点的健康检查和自动故障转移。以下是主从同步的具体过程：
1. 主节点负责写操作：MyCat 解析 SQL 请求后，将写操作路由至主节点 writeHost。
2. 从节点负责读操作：MyCat 将所有读请求发送至从节点 readHost。
3. 主从复制：写入操作完成后，主节点会将更新的数据同步至从节点，以确保读写数据的一致性。
4. 故障转移与选举：ZooKeeper 定期对主节点和从节点进行心跳检测。当主节点 writeHost 停机时，若经过多次检测仍未恢复，MyCat 会触发选举机制，从剩余的从节点中选出新的主节点。在原主节点恢复后，它将成为新的从节点，重新加入主从复制队列。

在这里插入图片描述

总结

在分布式存储设计中，数据分片、读写分离和主从同步是电商系统处理高并发访问和保证数据可用性的有效方法：

数据分片：通过 MyCat 等中间件，将大表数据分散到不同数据库，提高了查询效率，降低了单表的访问压力。
读写分离：将读请求分流到只读节点，从而降低主节点的负载，提升系统的读性能。
主从同步：通过主从复制机制，保证读写数据的一致性，并支持故障转移，提高了系统的可用性和容错性。

这种存储设计确保了电商系统在高并发场景下的稳定性和性能，使系统能够快速响应用户请求，同时保证数据的完整性和一致性。

分布式架构的特征

分布式架构相较于集中式架构具有独特的特征，主要体现在分布性、自治性、并行性和全局性上。

1. 分布性

分布性是分布式架构的核心特征。它包括了服务拆分、数据拆分和资源拆分。在分布式架构中，将单一的大型应用系统拆分成多个服务或模块，使得系统中的每一个服务都专注于处理某一特定业务。例如：

在电商系统中，用户浏览和下单的过程中会涉及到商品服务、订单服务、库存服务、支付服务等模块，各个模块各司其职。
数据方面，可以根据业务需求对大表进行分片存储，将商品表按 ID 分片，分布到不同数据库中，从而减少单一数据库的访问负载。
资源部署也会分布在不同的硬件服务器、容器或网络中。例如，将不同的应用服务器和数据库服务器部署在不同的网络节点上，以便分散负载，提升系统的可靠性。

2. 自治性

分布性带来的一个后果是自治性，即每个服务都具有独立完成自身任务的能力，不依赖于其他服务的资源或实现。具体体现为：

每个服务在业务逻辑上是独立的，可以自主完成自己所负责的任务。比如，订单服务专注于处理用户下单流程，并管理自身所需的资源和硬件环境。
服务之间通过服务注册中心和消息队列等方式进行交互，避免紧耦合。这种松散的关联使服务能独立开发、部署和升级，不影响其他服务的正常运行。
技术层面上，每个服务可以选择最佳适配的技术栈，而不需考虑与其他服务保持一致，从而提升开发灵活性和服务的自治能力。

3. 并行性

并行性（或并发性）是通过服务的独立性实现的，主要目的是提升系统的扩展能力和处理性能。其核心思想是将一个大的处理任务拆解成多个小任务，由多个服务实例同时处理：

在高并发场景下，商品服务这样的热点服务可以进行水平扩展，将一个服务扩展成多个实例，每个实例并行处理用户请求，从而分担单一服务的压力。
每个并行服务实例功能相同、资源相似，各自独立完成分配到的任务。这种并行处理方式使得系统可以有效地利用硬件资源，提升处理速度和系统吞吐量。
并行性带来的伸缩性还意味着在负载降低时，可以根据需求动态缩减服务实例，优化资源使用，降低运营成本。

4. 全局性

尽管分布式架构的资源和服务是分散的，但为了完成业务目标，需要考虑系统的全局性，即服务之间的协作与协调：

服务发现与通信：多个服务之间需要有效通信。服务注册中心使各服务可以动态感知其他服务的存在，从而实现跨服务调用。
分布式一致性：在处理涉及多个服务的操作时，如扣减库存和支付的操作，需要考虑一致性问题。分布式事务机制可以保证在分布式系统中，即便多个服务分散部署，也能保证业务逻辑的一致性。
故障恢复和容错：当主数据库服务器等关键节点发生故障时，系统需要具备自动故障切换机制，将请求切换到备用的从服务器，以保证服务的连续性。
全局负载管理：在高并发访问场景中，系统可以借助全局负载均衡策略将请求分配给多个服务实例，从而优化系统的整体性能。