Very_a的博客

BASE 理论通过放宽对一致性的严格要求，来换取分布式系统的高可用性和良好性能，与 CAP 理论中的 AP 模型紧密相关。许多分布式系统如分布式缓存（Redis、Memcached ）、消息队列（RabbitMQ、Kafka ）常遵循该理论。BASE 理论是对 CAP 理论的扩展与补充 ，用于解决分布式系统中一致性、可用性和平衡性问题，适用于需高可用性和可扩展性，且能容忍一定程度数据不一致的分布式系统。

在中，和是其支持的两种不同的，用于适应不同的业务场景需求。Nacos 作为微服务架构中的核心组件，主要解决和因此，Nacos 通过来平衡不同场景下的一致性与可用性需求，其底层基于和实现。

解决高并发问题从宏观角度来说有3个方向：其中，水平扩展和服务保护侧重的是运维层面的处理。而提高单机并发能力侧重的则是业务层面的处理，也就是我们程序员在开发时可以做到的。

注解本身起到标记作用，同时还要带上锁参数：锁名称锁等待时间锁超时时间时间单位@Component@Aspect// 1.创建锁对象// 2.尝试获取锁// 3.判断是否成功if(!isLock) {// 3.1.失败，快速结束throw new BizIllegalException("请求太频繁");try {// 3.2.成功，执行业务// 4.释放锁@Overridereturn 0;

Redisson是一个基于Redis的工具包，功能非常强大。将JDK中很多常见的队列、锁、对象都基于Redis实现了对应的分布式版本。

超卖这样的线程安全问题，解决方案有哪些？悲观锁：添加同步锁，让线程串行执行优点：简单粗暴缺点：性能一般乐观锁：不加锁，在更新时判断是否有其它线程在修改优点：性能好缺点：存在成功率低的问题。

领券的本质就是新增一条记录到user_coupon表，去记录用户和领券的优惠券之间的关系，使用状态等信息。不过，用户id我们可以自己获取，因此前端只要传递优惠券id即可。只传一个参数，我们可以直接用路径占位符传参。更新发行数量（已领取数量），不仅仅起到统计作用，同时也可以帮助我们判断库存是否充足。更新coupon表中已经领取的数量，别忘了在coupon表中是有一些统计字段的。校验优惠券的发放时间，是不是正在发放中。校验优惠券是否存在，不存在无法领取。1.Controller层。校验优惠券的每人限领数量。

这里要查询的是发放中的，并且领取方式是手动领取的优惠券。但是这里有一些隐含的内容在原型中没有显示出来：大家思考一下，如果这个优惠券我点击过立即领取，并且领取成功以后，页面该如何显示？不过这都是一些状态信息，不需要前端传递，我们自己在业务中判断即可。有效天数：券的使用有效期有两种方式，一种是到期时间；有效期的结束时间：页面写的是有效期至xxx，也就是说不关心有效期的开始时间，只关心结束时间。是否已经领取：也就是用户是否有已经领取，尚未使用的券。1.Controller层。领取方式是手动领取的。

假如一个优惠券是通过兑换码方式领取。第一次发放时我们生产了兑换码，然后被暂停，然后再次发放，如果我们再次生成兑换码，这就重复了。在发放优惠券的时候，如果发现优惠券的领取方式是兑换码方式，则需要生成兑换码。而且，由于生成兑换码的数量较多，可能比较耗时，这里推荐基于线程池异步生成。之前的状态必须是待发放，不能是暂停。领取方式必须是兑换码方式。不过，需要注意的是，

发放（领用）开始时间：如果为空说明是立刻发放，开始时间就是当前时间。，我们才知道发放的是哪张券，当然这个可以通过路径占位符传参。使用期限开始时间：如果为空说明是固定天数有效期。使用期限结束时间：如果为空说明是固定天数有效期。有效期天数：如果为空说明是固定有效期。1.Controller层。发放（领用）结束时间。

优惠券规则：这里是对优惠规则的描述，而数据库中保存的是具体的优惠金额；这里我们不组装描述返回，仅仅返回优惠金额信息，由前端自己组织展示即可。一个典型的带过滤条件的分页查询，非常简单。使用范围：这里无需展示真正的限定范围，只要告诉前端有没有限定范围即可。其它字段没什么特殊的，此处不再赘述了。1.Controller层。

需要特别注意的是，如果优惠券限定了使用范围，则需要保存限定的课程分类。而这些信息不再coupon表，而是一张中间关系表：coupon_scope。一个基本的新增接口，按照Restful风格设计即可，关键是请求参数。之前表分析时已经详细介绍过这个页面及其中的字段，这里不再赘述。1.Controller层。

榜单持久化的基本流程是这样的：创建表持久化Redis数据到数据库清理Redis数据现在，创建表的动作已经完成，接下来就轮到Redis数据的持久化了。持久化的步骤如下：读取Redis数据判断数据是否存在不存在，直接结束存在，则继续保存数据到数据库不过，Redis的数据结构如图：其KEY中包含一个上赛季对应的日期，因此要读取Redis数据，我们必须先得到上赛季的日期。另外，我们采用了水平分表的策略，每一个赛季都是一个独立表。那么在写数据到数据库时，必须先知道表名称。

这样一来，具体哪个任务该执行，什么时候执行，交给哪个应用实例来执行，全部都有统一的任务调度服务来统一控制。不仅仅是SpringTask，其它单机使用的定时任务工具，都无法实现像这种任务执行者的调度、任务执行顺序的编排、任务监控等功能。我们除了要定时创建表，还要定时持久化Redis数据到数据库，我们希望这多个定时任务能够按照顺序依次执行，SpringTask无法控制任务顺序。现在，执行器已经成功注册，任务也已经注册到调度中心。：一个独立服务，负责管理执行器、管理任务、任务执行的调度、任务结果和日志收集。

由于我们要解决的是数据过多问题，因此分表的方式选择。具体来说，就是按照赛季拆分，每一个赛季是一个独立的表，如图：不过这里我们可以做一些简化：我们可以将id作为排名，排名字段就不需要了。不同赛季用不同表，那么赛季字段就不需要了。综上，最终表结构可以是这样：不过这就存在一个问题，每个赛季要有不同的表，这些表什么时候创建呢？显然，应该在每个赛季刚开始的时候（月初）来创建新的赛季榜单表。每个月的月初执行一个创建表的任务，我们可以利用定时任务来实现。

简单来说，就是按照某种规则，把表数据对应的ibd文件拆分成多个文件来存储。而且，一旦做了分表，无论是逻辑上，还是物理上，就从一张表变成了多张表！数据库的表最终肯定是保存在磁盘中，对于InoDB引擎，一张表的数据在磁盘上对应一个ibd文件。首先，在微服务项目中，我们会按照项目模块，每个微服务使用独立的数据库，因此每个库的表是不同的，这种分库模式成为。无论是分区，还是分表，我们刚才的分析都是建立在单个数据库的基础上。List分区：按照指定字段的枚举值分区，必须提前指定好所有的分区值，如果数据找不到分区会报错。

需求中说连续签到会有积分奖励，那么为了提升用户体验，在用户签到成功以后是不是应该返回连续签到天数和获取的积分奖励呢。这两个信息我们都可以自己获取，因此签到时，前端无需传递任何参数。由KEY的结构可知，要签到，就必须知道是。那么签到以后是否需要返回数据呢？1.Controller层。

我们知道二进制是计算机底层最基础的存储方式了，其中的每一位数字就是计算机信息量的最小单位了，称之为bit，一个月最多也就 31 天，因此一个月的签到记录最多也就使用 31 bit 就能保存了，还不到 4 个字节。像这种把每一个二进制位，与某些业务数据一一映射（本例中是与一个月的每一天映射），然后用二进制位上的数字0和1来标识业务状态的思路，称为。encoding：返回结果的编码方式，BitMap中是二进制保存，而返回结果会转为10进制，但需要一个转换规则，也就是这里的编码方式。

虽然看起来简单，不过蕴含的技术方案和手段还是比较多的。

1.Controller层。

1.Controller层。

无参，程序从登录凭证中获取当前用户。1.Controller层。最近一次学习的小节名称。最近一次学习的小节序号。

这是一个微服务内部接口，当用户学习课程时，可能需要播放课程视频。此时提供视频播放功能的媒资系统就需要校验。课表lessonId，如果是报名了则返回lessonId，否则返回空。所以这个接口很简单，就是查询用户课表，做一个非空和状态的判断即可。根据课程id，检查当前用户的课表中是否有该课程，课程状态是否有效。课程id，请求路径占位符，参数名：courseId。课程状态是否是有效的状态（未过期））的同事就请你提供这样一个接口。所以，开发媒资服务（用户课表中是否有该课程。Http请求，GET。

其中用户退款与用户报名课程类似，都是基于MQ通知的方式。courseIds：退款的课程id。orderId：退款的订单id。用户退款后触发课表自动删除。用户直接删除已失效的课程。userId：用户id。

可以看到coueseId为4的的课表已经删除了。请求方式：删除业务的请求方式都是DELETE。请求参数：自然是路径中传递的课程id。

单体架构时我们只需要完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息。而微服务拆分后，每个微服务都独立部署，不再共享数据。也就意味着每个微服务都需要做登录校验，这显然不可取。

现在，微服务网关就起到同样的作用。由于网关本身也是一个独立的微服务，因此也需要创建一个模块开发功能。外面的人要想进入园区，必须经过大爷的认可，如果你是不怀好意的人，肯定被直接拦截。代表负载均衡，从注册中心获取目标微服务的实例列表，并且负载均衡选择一个访问。数据在网络间传输，从一个网络传输到另一网络时就需要经过网关来做数据的。通过认证后，网关再根据请求判断应该访问哪个微服务，将请求转发过去。网关可以做安全控制，也就是登录身份校验，校验通过才放行。更通俗的来讲，网关就像是以前园区传达室的大爷。

解决思路就是引入了全局锁的概念。在释放DB锁之前，先拿到全局锁。避免同一时刻有另外一个事务来操作当前数据。如果每一个分支事务都成功，则事务已经结束（因为阶段一已经提交），因此删除阶段一的快照即可。如果有任意分支事务失败，则需要根据快照恢复到更新前数据。

就是指不是在单个服务或单个数据库架构下，产生的事务，例如：跨数据源的分布式事务跨服务的分布式事务综合情况我们之前解决分布式事务问题是直接使用Seata框架的AT模式，但是解决分布式事务问题的方案远不止这一种。

组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的。可见，AT模式使用起来更加简单，无业务侵入，性能更好。Seata支持多种存储模式，但考虑到持久化的需要，我们一般选择基于数据库存储。为了方便各个微服务集成seata，我们需要把seata配置共享到nacos，因此。A是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。

首先我们看看项目中的下单业务整体流程：由于订单、购物车、商品分别在三个不同的微服务，而每个微服务都有自己独立的数据库，因此下单过程中就会跨多个数据库完成业务。而每个微服务都会执行自己的本地事务：交易服务：下单事务购物车服务：清理购物车事务库存服务：扣减库存事务整个业务中，各个本地事务是有关联的。因此每个微服务的本地事务，也可以称为。多个有关联的分支事务一起就组成了。我们必须保证整个全局事务同时成功或失败。我们知道每一个分支事务就是传统的。

保证服务运行的健壮性，避免级联失败导致的雪崩问题，就属于微服务保护。这章我们就一起来学习一下微服务保护的常见方案以及对应的技术。

是 Java EE 中的一个注解，用于标记一个非私有的 void 方法，该方法将在依赖注入完成后由容器调用。这个注解通常用于执行一些初始化工作，例如设置对象的状态或执行一些必要的计算。注解属于 Java 的生命周期回调机制的一部分。

有很多的业务相关参数，将来可能会根据实际情况临时调整。例如购物车业务，购物车数量有一个上限，默认是10，对应代码如下：现在这里购物车是写死的固定值，我们应该将其配置在配置文件中，方便后期修改。但现在的问题是，即便写在配置文件中，修改了配置还是需要重新打包、重启服务才能生效。能不能不用重启，直接生效呢？这就要用到Nacos的配置热更新能力了，分为两步：在Nacos中添加配置在微服务读取配置。

微服务共享的配置可以统一交给Nacos保存和管理，在Nacos控制台修改配置后，Nacos会将配置变更推送给相关的微服务，并且无需重启即可生效，实现配置热更新。我们可以把微服务共享的配置抽取到Nacos中统一管理，这样就不需要每个微服务都重复配置了。网关的路由同样是配置，因此同样可以基于这个功能实现动态路由功能，无需重启网关即可修改路由配置。）初始化时处理的，发生在项目的引导阶段。不过，需要注意的是，读取Nacos配置是SpringCloud上下文（中，那么在项目引导阶段就可以读取nacos中的配置了。

微服务之间调用是基于OpenFeign来实现的，并不是我们自己发送的请求。下单的过程中，需要调用商品服务扣减库存，调用购物车服务清理用户购物车。这样以来，每次OpenFeign发起请求的时候都会调用该方法，传递用户信息。前端发起的请求都会经过网关再到微服务，由于我们之前编写的过滤器和拦截器功能，微服务可以轻松获取登录用户信息。但有些业务是比较复杂的，请求到达微服务后还需要调用其它多个微服务。由于微服务获取用户信息是通过拦截器在请求头中读取，因此要想实现微服务之间的用户信息传递，就。

考虑到微服务内部可能很多地方都需要用到登录用户信息，因此我们可以利用SpringMVC的拦截器来实现登录用户信息获取，并存入ThreadLocal，方便后续使用。之前我们无法获取登录用户，所以把购物车服务的登录用户写死了，现在需要恢复到原来的样子。不过，需要注意的是，这个配置类默认是不会生效的，因为它所在的包是。改造网关过滤器，在获取用户信息后保存到请求头，转发到下游微服务。，与其它微服务的扫描包不一致，无法被扫描到，因此无法生效。接下来，我们只需要编写拦截器，获取用户信息并保存到。中，并写好自动装配。

单体架构时我们只需要完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息。而微服务拆分后，每个微服务都独立部署，不再共享数据。也就意味着每个微服务都需要做登录校验，这显然不可取。

由于网关本身也是一个独立的微服务，因此也需要创建一个模块开发功能。SpringCloudGateway：基于Spring的WebFlux技术，完全支持响应式编程，吞吐能力更强。外面的人要想进入园区，必须经过大爷的认可，如果你是不怀好意的人，肯定被直接拦截。数据在网络间传输，从一个网络传输到另一网络时就需要经过网关来做数据的。通过认证后，网关再根据请求判断应该访问哪个微服务，将请求转发过去。网关可以做安全控制，也就是登录身份校验，校验通过才放行。更通俗的来讲，网关就像是以前园区传达室的大爷。

为了达成这一目的，该阶段项目架构往往会比较简单，很多情况下会直接采用单体架构，这样开发成本比较低，可以快速产出结果，一旦发现项目不符合市场，损失较小。虽然出现了服务间调用，但此时无论你如何在商品服务做内部修改，都不会影响到订单微服务，服务间的耦合度就降低了。但是，这么做的问题就在于后期做服务拆分时，可能会遇到很多代码耦合带来的问题，拆分比较困难（如果这一阶段采用复杂的微服务架构，投入大量的人力和时间成本用于架构设计，最终发现产品不符合市场需求，等于全部做了无用功。，这其实是拆分的目标。