gmHappy

`Percona XtraBackup`是一个开源的`MySQL`和`MariaDB`数据库备份工具，它能够创建高性能、一致性的备份，并且对生产环境的影响很小。`Percona XtraBackup`通过在不停止`MySQL`服务器的情况下，复制`InnoDB`存储引擎的数据文件和事务日志，来实现备份和还原操作。

分库分表是数据库扩展中最常用的处理方法，`ShardingSphere `作为使用最广泛的数据分片中间件，`ShardingSphere` 实现了对分布式事务`Seata`的支持，保证了数据一致性。在这篇文章中，我们使用`ShardingSphere`整合`Seata`在数据分片场景下进行（远程）分布式事务调用，并对集成过程中需注意的事项进行详解说明。

在这篇文章中，我们使用Seata整合一下多数据源的场景。多数据源切换的功能我们使用`dynamic-datasource-spring-boot-starter`来完成，并且这个组件还可以和`Seata`进行整合，实现数据源的代理。

在一个分布式系统中，一致性（`Consistency`）、可用性（`Availability`）、分区容错性（`Partition tolerance`），这三个要素最多只能同时实现两点，不可能三者兼顾。

一、前言通过以下系列章节：docker-compose 实现Seata Server高可用部署 | Spring Cloud 51Seata AT 模式理论学习、事务隔离及部分源码解析 | Spring Cloud 52Spring Boot集成Seata利用AT模式分布式事务示例 | Spring Cloud 53Seata XA 模式理论学习、使用及注意事项 | Spring Cloud54Seata TCC 模式理论学习、生产级使用示例搭建及注意事项 | Spring Cloud55Se

`Saga`模式是`Seata`提供的长事务解决方案，在`Saga`模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

TCC 模式是分布式事务使用最多的模式，但是幂等、悬挂和空回滚一直是 TCC 模式需要考虑的问题。Seata 框架在 1.5.1 版本完美解决了这些问题。

`tcc`事务模式一共涉及到了三个方法，`prepare`、`commit` 以及 `rollback`，这三个方法都完全是**用户自定义**的方法，都是需要我们自己来实现的。相较于 `AT` 事务模式 `TCC` 这种模式其实是**不依赖于底层数据库的事务支持**的。

- 支持`XA` 事务的数据库。- `Java` 应用，通过 `JDBC` 访问数据库。

我们对`Seata`及其`AT`事务模式有了基础的了解，今天我们通过搭建`Spring Boot`集成`Seata`示例，加深对`AT`事务模式的掌握，避免在后续实战业务中出现脏写及脏读。

一、前提基于支持本地 ACID 事务的关系型数据库。Java 应用，通过 JDBC 访问数据库。二、整体机制两阶段提交协议的演变：一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。二阶段：提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

ShardingSphere-Proxy 定位为透明化的数据库代理端，通过实现数据库二进制协议，对异构语言提供支持。 目前提供 MySQL 和 PostgreSQL 协议，透明化数据库操作，对 DBA 更加友好。向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用；兼容 MariaDB 等基于 MySQL 协议的数据库，以及 openGauss 等基于 PostgreSQL 协议的数据库；适用于任何兼容 MySQL/PostgreSQL 协议的的客户端

可能存在以下场景：原项目中使用的是dynamic-datasource进行数据源管理，由于项目经历一段时间的线上运行，数据库压力越来越大，计划使用shardingsphere-jdbc进行数据分片或读写分离。

利用ShardingSphere实现：- 数据加密- 数据脱敏

在 `5.3.0` 版本以前，`ShardingSphere-JDBC` 同时支持 `Java API`、`YAML`、`Spring Boot Starter` 和 `Spring Namespace` 等配置方式。- 当新增或更新 API 时，需要调整多项配置文件，工作量大- 社区需要维护多重配置文档和示例- `Spring Bean` 生命周期管理容易受到项目其他依赖的影响，比如 `PostProcessor` 无法正常执行- `Spring Boot Starter` 和 `Spring N

`AutoTable` 支持全部的自动分片算法，包括：- `MOD`：取模分片算法- `HASH_MOD`：哈希取模分片算法- `VOLUME_RANGE`：基于分片容量的范围分片算法- `BOUNDARY_RANGE`：基于分片边界的范围分片算法- `AUTO_INTERVAL`：自动时间段分片算法

为了帮助用户更好的使用分片功能，降低配置复杂度和提升使用体验，`Apache ShardingSphere 5.0.0` 版本推出了一种新的分片配置方式：`AutoTable`。顾名思义，`AutoTable` 类型的数据表，交由 `ShardingSphere` 自动管理分片，用户只需要指定分片数量和使用的数据源，无需再关心表的具体分布。

+ 基于时间范围的分片算法（`INTERVAL`）实现按月数据分片+ 创建自定义`ShardingSphere`分片算法及实现按月数据分片

通过一主多从的配置方式，可以将查询请求均匀的分散到多个数据副本，能够进一步的提升系统的处理能力。 使用多主多从的方式，不但能够提升系统的吞吐量，还能够提升系统的可用性，可以达到在任何一个数据库宕机，甚至磁盘物理损坏的情况下仍然不影响系统的正常运行。与将数据根据分片键打散至各个数据节点的水平分片不同，读写分离则是根据 SQL 语义的分析，将读操作和写操作分别路由至主库与从库。

书接上回，本章进行对以下部分进行集成演示：+ 通过`Spring Boot`集成`ShardingSphere-JDBC`来实现数据分片，展示其集成步骤和各注意事项+ 对分库、分表进行示例展示+ 展示日常开发使用到的数据分片算法

数据分片的拆分方式分为垂直分片和水平分片。而在实际的业务场景中可以分为：垂直分表、垂直分库、水平分表、水平分库。

数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。 数据分片的有效手段是对关系型数据库进行分库和分表。分库和分表均可以有效的避免由数据量超过可承受阈值而产生的查询瓶颈。

`SpringCache`框架还提供了`CacheManager`接口，可以实现降低对各种缓存框架的耦合。它不是具体的缓存实现，它只提供一整套的接口和代码规范、配置、注解等，用于整合各种缓存方案，比如`Caffeine`、`Guava Cache`、`Ehcache`、`Redis`等。

Caffeine是一款高性能、最优缓存库。Caffeine是受Google guava启发的本地缓存（青出于蓝而胜于蓝），在Cafeine的改进设计中借鉴了 Guava 缓存和 ConcurrentLinkedHashMap，Guava缓存可以参考上篇：本地缓存解决方案GuavaCache | Spring Cloud 37，就和Mybatis与Mybatis Plus一样。Caffeine也是Spring5.X后使用的缓存框架，作为Spring推荐的缓存框架我们有必要了解一下。

`Guava Cache`是一个全内存本地缓存。拥有以下优点：- 线程安全的缓存，与`ConcurrentMap`相似（前者更"好"），在高并发情况下，能够正常缓存更新以及返回- 提供了三种基本的缓存回收方式： 基于容量回收、定时回收和基于引用回收策略- 提供了两种定时回收：按照写入时间，最早写入的最先回收；按照访问时间，最早访问的最早回收- 支持缓存更新及缓存移除监听- 可以监控缓存加载/命中情况- 使用方便、简单

**分布式锁**，即分布式系统中的锁。在单体应用中我们通过锁解决的是控制共享资源访问的问题，而分布式锁，就是解决了分布式系统中控制共享资源访问的问题。与单体应用不同的是，分布式系统中竞争共享资源的最小粒度从线程升级成了进程。

现在开始我们正式学习`Spring Boot`集成`RocketMQ`消费端更多扩展属性配置，在本章节主要进行对以下部分讲解说明：- `consumer`设置消费失败最大重试次数- `consumer`设置消费起始位点

现在开始我们正式学习`Redis`的`keyspace`（**键空间通知**），在本章节主要进行对以下部分讲解说明：- `keyspace`（**键空间通知**）介绍- `Redis`事件通知开启方式及配置说明- `keyspace`各种事件通知的产生- `keyspace`监听的`redis-cli`客户端验证- `Spring Boot`集成`Redis`实现`keyspace`监听- `RedisMessageListenerContainer` 使用自定义线程池

Spring Boot集成Redis实现Key事件监听。

在某些业务场景下，需要多访问同一`Redis`数据源下的不同`DB`。>在`Redis`中默认提供了`16`个数据库（序号`0-15`），默认`Redis`使用的是`db 0`。此章节基于`spring-boot-starter-data-redis`模块，实现了`Redis`同数据源动态切换`DB`，具体功能如下：- 突破一个项目只能连接`Redis`一个`DB`的限制- 提供多种操作切换`Redis DB`的方式（`@Autowired`方式 和`RedisSelectSupport`方式

在前面我们通过以下章节对Redis使用有了基础的了解：Spring Boot实现Redis同数据源动态切换DB | Spring Cloud 31此章节基于spring-boot-starter-data-redis模块，实现了Redis多数据源动态切换，具体功能如下：突破一个项目只能一个连接Redis数据源的限制提供多种操作切换Redis数据源的方式（@Autowired方式 和RedisSelectSupport方式）提供完善的代码使用示例

现在开始我们正式学习`Spring Boot`中集成`RocketMQ`使用,，在本章节主要进行对以下部分讲解说明：- 普通消息的发送接收- 延时消息的发送接收- 事务消息的发送接收- 发送端和接收端开启`ACL`- `PULL`模式消费及`@ExtRocketMQConsumerConfiguration`使用

权限控制（`ACL`）主要为`RocketMQ`提供`Topic`资源级别的用户访问控制。用户在使用`RocketMQ`权限控制时，可以在`Client`客户端通过 `RPCHook`注入`AccessKey`和`SecretKey签名`；同时，将对应的权限控制属性（包括：`Topic访问权限`、`IP白名单`和`AccessKey`和`SecretKey签名`等）设置在`distribution/conf/plain_acl.yml`的配置文件中。

网上关于`Docker`搭建`RocketMQ`单机&集群的版本一般都是`4.X`。关于最新的`5.X`版本，官方给出的示例都是基于物理机&虚拟机实现，不便于我们我们日常开发使用，而且官方镜像 https://hub.docker.com/r/apache/rocketmq 中也没有关于容器化使用的介绍。本章的目的：展示基于`docker-compose` 搭建`RocketMQ 5.1.0`集群，及一些部署在部署过程中的注意事项，方便大家对新版本的尝鲜与使用。

`Spring Boot/Cloud`读取配置文件`yaml`中的数据，包括：`List`、`Map`、`Object`、`基本数据类型`，并对`@ConfigurationProperties`与`@Value`的使用场景和方式进行比较

@SentinelResource 用于定义资源，并提供可选的异常处理和 fallback 配置项。

很多时候，我们需要根据调用来源来判断该次请求是否允许放行，这时候可以使用 `Sentinel` 的来源访问控制（黑白名单控制）的功能。来源访问控制根据资源的请求来源（`origin`）限制资源是否通过：- 若配置白名单则只有请求来源位于白名单内时才可通过- 若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过

- `Sentinel` 与 `Feign` 集成- `Sentinel` 与 `RestTemplate` 集成- `Spring Boot/Cloud`集成 `Sentinel` 开启链路流控模式

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。 Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。