2024年4月

大家好,我是蓝胖子,在之前
# MYSQL 是如何保证binlog 和redo log同时提交的?
这篇文章里,我们可以从mysql的设计中学会如何让两个服务的调用逻辑达到最终一致性,这也是分布式事务实现方式之一。今天来看看我们能够从httpsd设计中得到哪些启发可以用于业务系统开发中。

https原理分析

首先,我们来看下https 涉及到的握手流程,在http的三次握手基础上,https还要进行tls的握手协议。在经过tls握手后,后续客户端和服务端发送的消息也就都是加密的了。我们着重要看的就是tls握手过程。tls协议目前主要现存两个版本,我们都来看看。

tls1.2

首先,来看下tls1.2 协议下的握手流程。

在了解程序逻辑究竟为何如此设计之前,要搞懂我们这样做的目的。https之所以要用tls,无非就是为了两个目的,

  • 第一个目的:
    让客户端能够认证服务端的身份信息,防止访问不安全的钓鱼网站。
  • 第二个目的:
    对服务器和客户端之间的消息进行加密,不再明文传输。

对于第一个目的,可以通过数字证书解决,CA 向服务器颁发一个证书,在一次tls握手中,服务器会向客户端发放自己的证书,客户端在得到证书后向CA验证证书的合法性,如果合法,说明服务端是经过认证的,可以信任。

验证的原理则是通过公私钥加密算法和摘要算法
,CA有自己的私钥,同时CA会将自己的公钥公布出去,然后CA对服务器的证书内容进行摘要计算,再对摘要进行私钥加密,
私钥加密的内容只有公钥才能解密
,私钥加密的内容称为签名信息,这段签名信息同样也会包含在证书中。

客户端在得到服务端证书的时候,通过对签名信息进行解密,得到证书的摘要信息,这个时候再对证书的内容进行摘要计算,看计算结果是否和解密得到的摘要信息一致,如果证书内容没被篡改的话,相同摘要算法得到的摘要信息应该是一致。

对于第二个目的,则是可以通过加密算法,为了性能,会话加密将会采用对称加密算法,这里的关键是得到一个会话密钥,但是为了安全性,会话密钥又不能直接采用明文进行传输。

所以tls是这样做的,客户端首先会生成一个随机数A,并已明文传递给服务端,服务端也会生成一个随机数B,并且把它传递给客户端,同时还会把数字证书传给客户端。数字证书中包含了服务端的公钥信息,客户端在收到证书取出其中公钥后,会再次生成一个随机数,随机数被称作
pre master key
,这个随机数会通过证书中的公钥进行加密,传递给服务端,服务端会用自己的私钥对其进行解密,因为公钥加密的信息只能私钥才能解密,所以在服务端私钥不会泄露的情况下,黑客即使截获了报文,依然不能知道
pre master key
的值。

接着,便是服务端和客户端用相同的计算密钥的算法,以客户端和服务端的随机数A,B和pre master key生成相同的会话密钥,用于后续的通信进行对称加密。整个过程如下图所示,
可以看到密钥的产生过程经历两次RTT
,才会开始进行后续的请求发送。

请求一来一回称为一次RTT

image.png

关于tls1.2的完整握手过程,我也总结一个流程图,方便大家参考,

image.png

tls1.3

在了解了tls1.2的握手过程后,我们来看看tls1.3在握手过程中有哪些优化。tls1.3 废弃了一些密钥交换算法如RSA,默认用椭圆曲线ECDHE密钥交换算法,将密钥的产生时间从两次RTT缩短至了一次RTT。

废弃RSA密钥交换算法的另一个原因在于,使用RSA密钥交换算法,如果黑客持续截获https报文,如果数字证书中的公钥对应的服务端私钥泄露,那么黑客便可以将之前的历史报文进行解密,RSA密钥交换算法不具有
前向安全
性。前向安全指的是
长期使用的主密钥泄漏不会导致过去的会话密钥泄漏

如下图所示,客户端和服务端都各自生成自己的一对用于ECDHE计算的随机公私钥和各自的随机数, 然后将各自的公钥和随机数传给对方,之后便可以各自通过这些信息计算出相同的会话密钥。

ECDHE 密钥交换具有前向安全性,因为参与会话密钥计算的私钥每次都是随机生成的,这样即使黑客获得了当前的私钥,也不能对历史https报文进行解密。

image.png

可以看到,ECDHE密钥交换算法只交换了各自的公钥便可以计算出会话密钥,即使黑客截获了消息内容,但是只有公钥,没有私钥也不能计算出会话密钥。我将tls1.3的握手过程总结到了下面的流程图中,大家可以参考下,

image.png

im消息加密解决方案

以上是https消息加密的实现原理,如果我们也想在消息传输中进行加密和认证处理,比如在im系统中对im消息加密,那么完全可以参考https的实现原理。

我们需要为im系统做
消息加密

消息防篡改
的设计。

对于消息加密,参考https的交互,可以采用对称加密对后续会话内容进行对称加密,比如AES算法,加密的密钥可以采用ECDHE密钥交换算法,具有前向安全性。

对于消息防篡改,可以采用消息摘要算法,常见的摘要算法有md5,sha256,通过对加密后的报文进行摘要计算,在获取到报文的第一时间就通过对比计算出的消息摘要和报文中的消息摘要 来判断报文是否经过篡改。

更进一步,还可以设计一组只有im客户端和服务端知道的密钥,让客户端在进行摘要计算时,加上密钥,也就是通过类似hmac的消息认证算法,进行摘要计算,这样在对端接收到报文后,正常情况下,通过相同的消息认证算法和密钥会得到相同的摘要结果,如果计算的摘要结果和报文中的摘要结果不一致,那么说明报文不是从信任的客户端发来的,直接拒绝,这样便达到了
消息认证
的目的。


本文全面探索了容器编排技术的核心概念、工具和高级应用,包括Docker Compose、Kubernetes等主要平台及其高级功能如网络和存储管理、监控、安全等。此外,文章还探讨了这些技术在实际应用中的案例,提供了对未来趋势的洞见。

关注【TechLeadCloud】,分享互联网架构、云服务技术的全维度知识。作者拥有10+年互联网服务架构、AI产品研发经验、团队管理经验,同济本复旦硕,复旦机器人智能实验室成员,阿里云认证的资深架构师,项目管理专业人士,上亿营收AI产品研发负责人

file

一、容器编排介绍

容器编排是现代云原生应用管理的核心,它涉及在大规模的环境中自动化部署、管理、扩展和网络配置容器。随着微服务架构的兴起和应用的复杂性增加,容器编排成为了实现高效、可靠和动态服务管理的关键技术。

容器编排的概念和重要性

容器编排的概念源自于需要在大量的物理或虚拟机上有效管理成百上千个容器的需求。容器本身虽然轻量级且快速,但在复杂的生产环境中,手动管理这些容器的部署和生命周期是不切实际的。容器编排通过自动化这些过程,提供了如下几个关键优势:

  1. 高效的资源利用
    :通过智能调度,编排工具能够确保容器在最合适的主机上运行,优化资源的使用。
  2. 快速扩展和恢复
    :应对突然的流量峰值或服务故障,容器编排能够快速扩展或重新部署服务。
  3. 自动化和一致性
    :编排工具保证了部署的一致性,减少了人为错误,使得部署过程更加自动化和可重复。
  4. 服务发现和负载均衡
    :容器之间的网络配置和通信通过编排工具自动管理,提高了整体的应用性能。

容器编排的发展趋势

近年来,随着技术的快速发展,容器编排已经从最初的单一服务自动化,发展为支持复杂应用的全面解决方案。例如,Kubernetes 不仅支持基础的部署和扩展,还提供了服务网格(如Istio),以支持微服务之间复杂的通信和安全需求。此外,GitOps的兴起,将Git仓库作为应用部署的真理来源,使得容器编排更加透明和易于管理。

容器编排的实际应用案例

在实际应用中,容器编排已经成为许多成功项目的基石。例如,Netflix的容器化平台 Spinnaker,利用容器编排技术支持了他们庞大的微服务架构,实现了快速的服务部署和高效的资源管理。在金融领域,Goldman Sachs 通过Kubernetes管理他们的交易系统,不仅提高了系统的稳定性,还加快了新功能的上线速度。

二、容器编排工具概览

在容器编排领域,有几个关键的工具和平台已经成为行业的标准。这些工具不仅提供了基础的容器管理功能,还引入了高级特性,如自动扩展、服务发现和自我修复能力。我们将探讨其中最重要的几个工具:Docker Compose、Kubernetes 和 Docker Swarm,了解它们的基本概念、特性和适用场景。

Docker Compose

Docker Compose 是一个用于定义和运行多容器Docker应用程序的工具。通过Compose,用户可以使用YAML文件来配置应用服务。然后,只需一个简单的命令,就可以创建并启动所有服务。Docker Compose 特别适合于开发环境和小型项目,因为它简化了多容器应用的构建和管理过程。

特点

  • 易于使用
    :通过一个YAML文件管理整个应用的服务。
  • 开发友好
    :适合在开发环境中快速部署和测试。
  • 轻量级
    :不需要额外的基础设施或复杂的配置。

应用案例

例如,一个开发团队可以使用Docker Compose来搭建他们的本地开发环境,包括应用服务器、数据库和缓存服务。这使得整个团队能够在一个一致的环境中工作,减少了“在我的机器上运行正常”的问题。

Kubernetes

file
Kubernetes(K8s)是目前最流行的开源容器编排系统,用于自动部署、扩展和管理容器化应用程序。由Google开发,并由Cloud Native Computing Foundation(CNCF)维护。

特点

  • 高度可扩展
    :可以管理大规模的容器部署。
  • 强大的生态系统
    :支持广泛的工作负载类型、服务发现和负载均衡。
  • 自动化运维
    :包括自动扩展、自我修复和滚动更新。

应用案例

在全球范围内,许多大型企业(如Spotify、华为和IBM)都使用Kubernetes来支持他们的生产环境。Kubernetes不仅提高了这些公司的运维效率,还为他们提供了无与伦比的系统稳定性和可扩展性。

Docker Swarm

Docker Swarm 是 Docker 的原生集群管理工具。它使用Docker API,因此已经熟悉Docker的用户会发现Swarm易于上手和使用。

特点

  • Docker原生
    :紧密集成在Docker生态系统中。
  • 简单易用
    :对于小型到中型项目而言,Swarm提供了足够的功能。
  • 轻量级
    :不需要额外的安装,只需要Docker。

应用案例

对于那些已经在使用Docker并且需要更简单的解决方案来扩展他们的应用到多个主机的团队,Docker Swarm提供了一个理想的选择。例如,一个中小型企业可以使用Swarm来管理他们的几个服务,而无需投入更多资源来学习和部署Kubernetes。

三、Docker Compose全解

Docker Compose 是一个用于定义和运行多容器Docker应用程序的工具。它允许用户使用YAML文件来声明式地定义服务、网络和卷,从而在Docker环境中轻松构建、测试和部署应用程序。

Docker Compose 的基本概念

1. 服务(Service)

  • 定义
    :服务是Docker Compose中的核心概念,它代表一个应用的组成部分(例如,数据库、前端、后端)。
  • 特性
    :每个服务都可以定义其容器镜像、端口映射、卷挂载和依赖关系。

2. 网络(Network)

  • 定义
    :Compose允许定义网络来实现容器间的通信。
  • 特性
    :支持不同的网络类型,如桥接或覆盖网络,确保容器之间的隔离和安全通信。

3. 卷(Volume)

  • 定义
    :卷用于数据持久化和共享。
  • 特性
    :可以被多个容器共享,用于存储数据库文件、配置文件等。

Docker Compose 文件结构

YAML文件是Docker Compose的核心,其中定义了所有相关的服务、网络和卷配置。

示例

version: "3.9"  # 使用的Compose文件版本
services:
  web:
    image: "my-web-app:latest"  # 定义使用的镜像
    ports:
      - "5000:5000"  # 端口映射
    networks:
      - webnet  # 网络配置
  redis:
    image: "redis:alpine"
    networks:
      - webnet

networks:
  webnet:

高级功能

1. 服务扩展(Scale)

  • 描述
    :自动增加或减少服务的实例数量。
  • 用途
    :在高流量时期动态扩展服务实例,以应对负载。

2. 健康检查(Healthcheck)

  • 描述
    :监控服务的运行状态。
  • 用途
    :确保服务正常运行,对故障实例进行自动重启。

3. 环境变量(Environment Variables)

  • 描述
    :设置和管理服务运行时的环境变量。
  • 用途
    :配置数据库连接、API密钥等敏感信息。

Docker Compose 在实际应用中的应用

在微服务架构中,Docker Compose被广泛用于本地开发和测试环境。它允许开发人员在本地复现生产环境,确保应用的每个组件都能在一个隔离且一致的环境中运行。

应用示例

假设一个团队正在开发一个包含前端、后端和数据库的Web应用。使用Docker Compose,他们可以定义三个服务:一个用于前端的Node.js应用,一个用于后端的Python API,以及一个PostgreSQL数据库。每个服务都可以在其专用容器中运行,并且通过定义的网络相互通信。这样,整个团队可以在相同的配置下工作,减少环境差异带来的问题。

总结

Docker Compose提供了一个简单而强大的工具,用于管理和编排多容器应用。它的易用性和灵活性使其成为开发和小规模部署环境的理想选择。通过深入了解Compose的各种功能和最佳实践,开发团队可以显著提升其开发效率和应用质量。

四、Kubernetes全解

Kubernetes,通常称为K8s,是当前最流行的开源容器编排平台。它为自动化部署、扩展和管理容器化应用程序提供了一个健壮的框架。

Kubernetes的核心概念

1. Pod

  • 定义
    :Pod是Kubernetes中最小的可部署单元,通常包含一个或多个容器。
  • 特点
    :Pod中的容器共享存储、网络和运行配置。

2. Service

  • 定义
    :Service是定义如何访问一组具有相同功能的Pod的抽象方式。
  • 特点
    :确保网络访问的稳定性和负载均衡。

3. Deployment

  • 定义
    :Deployment为Pod和ReplicaSet(Pod的集合)提供声明式的更新能力。
  • 特点
    :支持滚动更新和版本回滚。

Kubernetes的架构组件

1. 控制平面(Control Plane)

  • 功能
    :管理集群状态,如调度、响应Pod生命周期事件等。
  • 组件
    :包括API服务器、调度器、控制器管理器等。

2. 节点(Node)

  • 功能
    :运行应用程序容器。
  • 组件
    :包括Kubelet、Kube-proxy和容器运行时。

3. 存储(Storage)

  • 功能
    :提供持久存储解决方案。
  • 组件
    :支持多种存储选项,如本地存储、公有云存储等。

Kubernetes的高级特性

1. 自动扩缩容(Auto-Scaling)

  • 描述
    :根据负载自动增加或减少Pod数量。
  • 应用
    :保证应用在不同负载下的性能和成本效率。

2. 服务发现和负载均衡

  • 描述
    :自动配置网络,使得服务能够互相发现和负载均衡。
  • 应用
    :简化了微服务架构中服务间通信的复杂性。

3. 自动化部署和回滚

  • 描述
    :通过声明式配置自动管理应用部署和回滚。
  • 应用
    :提高部署的可靠性和频率,降低部署失败的风险。

Kubernetes在实际应用中的应用

Kubernetes已经成为微服务架构的事实标准。它能够支持从小型初创企业到大型企业的不同规模应用。

应用示例

假设一个在线零售平台,需要管理其多个微服务(如订单处理、支付处理、用户认证等)。使用Kubernetes,这些服务可以被部署为独立的Pod或Deployment,并通过Service进行互联。随着用户数量的增长,Kubernetes可以自动扩展服务,确保应用的可靠性和性能。

Kubernetes的未来趋势

Kubernetes不断发展,正在融合更多的云原生技术,如服务网格、Serverless架构等。未来,Kubernetes可能会进一步简化应用部署和管理的复杂性,使得它不仅仅是容器编排工具,而是整个云原生应用生态系统的核心。

五、高级容器编排技术

在现代的容器化生态系统中,随着应用和部署的复杂性增加,高级容器编排技术成为了不可或缺的组成部分。这些技术不仅提升了容器管理的效率和灵活性,还确保了系统的可靠性和安全性。

网络管理

容器网络管理是确保容器间正确、安全通信的重要部分。在复杂的容器化环境中,网络管理包括但不限于以下方面:

1. 网络模型

  • 概念
    :容器网络模型定义了容器如何在网络中交互。
  • 技术
    :如CNI(Container Network Interface)、Flannel、Calico。

2. 服务网格

  • 概念
    :服务网格管理微服务间的通信,提供负载均衡、服务发现等功能。
  • 技术
    :如Istio、Linkerd。
  • 应用
    :服务网格使得微服务间的复杂通信变得透明和可控。

存储管理

在容器编排中,存储管理保证了数据的持久性和一致性。高级存储管理技术包括:

1. 持久化存储

  • 概念
    :为容器提供持久化的存储解决方案。
  • 技术
    :如Persistent Volumes (PV) 和 Persistent Volume Claims (PVC) 在Kubernetes中的应用。

2. 存储编排

  • 概念
    :自动管理存储资源的分配和生命周期。
  • 技术
    :如Rook、Portworx。

容器监控和日志管理

为了确保容器化环境的健康和性能,监控和日志管理是必不可少的。

1. 监控

  • 概念
    :实时监控容器和集群的性能指标。
  • 工具
    :如Prometheus、Grafana。

2. 日志管理

  • 概念
    :集中收集、存储和分析容器日志。
  • 工具
    :如ELK Stack(Elasticsearch, Logstash, Kibana)、Fluentd。

容器安全性

容器安全性是容器编排中一个重要且日益受到关注的领域,包括:

1. 容器安全扫描

  • 概念
    :检测容器镜像中的安全漏洞。
  • 工具
    :如Clair、Trivy。

2. 运行时安全

  • 概念
    :保护运行中容器免受攻击。
  • 工具
    :如Falco、Sysdig。

自动化和策略驱动管理

容器编排的自动化和策略驱动管理提供了更高层次的控制和效率。

1. 自动化部署

  • 技术
    :如GitOps,使用Git仓库作为唯一的真理来源,实现自动化的应用部署。

2. 策略驱动管理

  • 技术
    :如OPA (Open Policy Agent),为云原生环境提供统一的策略执行。

关注【TechLeadCloud】,分享互联网架构、云服务技术的全维度知识。作者拥有10+年互联网服务架构、AI产品研发经验、团队管理经验,同济本复旦硕,复旦机器人智能实验室成员,阿里云认证的资深架构师,项目管理专业人士,上亿营收AI产品研发负责人

如有帮助,请多关注
TeahLead KrisChang,10+年的互联网和人工智能从业经验,10年+技术和业务团队管理经验,同济软件工程本科,复旦工程管理硕士,阿里云认证云服务资深架构师,上亿营收AI产品业务负责人。

1.工具类(Utility Class)

在Java中,工具类通常包含一系列静态方法,用于执行常见的任务,这些任务可能不直接关联到特定的业务逻辑,而是用于处理一些基础的数据转换、字符串操作、文件操作等。工具类通常被设计为无状态的,即不包含任何实例变量,并且所有的方法都是静态的。

例如,下面是一个简单的Java工具类,用于处理字符串:

public class StringUtils {
    
    public static boolean isEmpty(String str) {
        return str == null || str.isEmpty();
    }
    
    public static String trim(String str) {
        return str == null ? null : str.trim();
    }
    
    // ... 其他字符串处理方法
}

在这个例子中,
StringUtils
类提供了两个静态方法:
isEmpty
用于检查字符串是否为空,
trim
用于去除字符串两端的空格。开发者可以直接通过类名调用这些方法,而无需创建类的实例。

2.API(应用程序编程接口)

在Java中,API通常是
一组类、接口和方法
的集合,它们定义了程序之间如何交互和通信的规则。API可以是Java标准库的一部分,也可以是第三方库或框架提供的。API允许开发者使用预定义的方法和类来构建应用程序,而无需了解这些方法和类的内部实现。

例如,Java的集合框架(Collections Framework)就是一个API,它提供了一系列接口和类来实现和操作集合(如列表、集合、映射等)。开发者可以使用这些API来创建和操作集合,而无需自己从头开始实现这些功能。

import java.util.ArrayList;
import java.util.List;

public class ApiExample {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>();
        names.add("Alice");
        names.add("Bob");
        System.out.println(names); // 输出: [Alice, Bob]
    }
}

在这个例子中,
ArrayList
是Java集合框架的一部分,它实现了
List
接口。通过使用
ArrayList
类,我们可以很方便地创建和操作一个列表,而无需关心列表内部是如何实现的。

3.区别总结

  • 工具类
    :通常包含静态方法,用于执行通用任务,不直接关联到特定的业务逻辑。
  • API
    :定义了一组类、接口和方法,用于实现特定的功能或业务逻辑,允许开发者使用预定义的方法和类来构建应用程序。

虽然工具类和API在Java中都是代码组织和复用的手段,但它们的侧重点和使用场景是不同的。工具类更侧重于提供通用的、可复用的功能,而API则更侧重于定义和实现特定领域或框架的功能和规则。

大家好,我是小富~

前言

本文是《ShardingSphere5.x分库分表原理与实战》系列的第六篇,书接上文实现三种自定义分片算法。通过自定义算法,可以根据特定业务需求定制分片策略,以满足不同场景下的性能、扩展性或数据处理需求。同时,可以优化分片算法以提升系统性能,规避数据倾斜等问题。

在这里,自定义分片算法的类型(Type)统一为
CLASS_BASED
,包含两个属性:
strategy
表示分片策略类型,目前支持三种:
STANDARD

COMPLEX

HINT

algorithmClassName
表示自定义分片算法的实现类路径。此外,还可以向算法类内传入自定义属性。

自定义 STANDARD 算法

要实现自定义
STANDARD
标准算法,需要实现
StandardShardingAlgorithm<T>
接口( T 代表接收的分片健值类型),并重写接口中的四个方法。其中,有两个
doSharding()
方法为处理分片的核心逻辑;
getProps()
方法用于获取分片算法的配置信息;
init()
方法则用于初始化分片算法的配置信息,支持动态修改。

5.X
以后的版本,实现自定义标准算法的精准分片和范围分片,不在需要实现多个接口。只用实现 StandardShardingAlgorithm 标准算法接口,重写两个 doSharding() 方法。 doSharding(availableTargetNames,rangeShardingValue) 处理含有 >、<、between and 等操作符的 SQL,doSharding(availableTargetNames,preciseShardingValue) 处理含有 = 、in 等操作符的 SQL。

精准分片

精准分片用于SQL中包含 in、= 等操作符的场景,支持单一分片健。

重写方法 doSharding(Collection availableTargetNames, PreciseShardingValue preciseShardingValue),该方法返回单一的分片数据源或分片表数据。有两个参数:一个是可用目标分库、分表的集合,另一个是精准分片属性对象。

PreciseShardingValue
对象属性数据格式如下:

{
  "columnName": "order_id", // 分片健
  "dataNodeInfo": {  
    "paddingChar": "0",
    "prefix": "db",   // 数据节点信息前缀,例如:分库时为db,分表时为分片表t_order_
    "suffixMinLength": 1
  },
  "logicTableName": "t_order", // 逻辑表
  "value": 1 // 分片健值
}

范围分片

范围分片用于 SQL中包含 >、< 等范围操作符的场景,支持单一分片健。

重写方法 doSharding(Collection availableTargetNames, RangeShardingValue rangeShardingValue),该方法可以返回多个分片数据源或分片表数据。有两个参数:一个是可用目标分库、分表的集合,另一个是精准分片属性对象。

RangeShardingValue
对象属性数据格式如下:

{
  "columnName": "order_id", // 分片健
  "dataNodeInfo": {
    "paddingChar": "0",
    "prefix": "db",  // 数据节点前缀,分库时为数据源,分表时为分片表t_order_
    "suffixMinLength": 1
  },
  "logicTableName": "t_order", // 逻辑表
  "valueRange": [0,∞]  // 分片健值的范围数据
}

精准分片算法的 doSharding() 执行流程:从
PreciseShardingValue.getValue()
中获取分片键值,然后经过计算得出相应编号,最终在
availableTargetNames
可用目标分库、分片表集合中选择以一个符合的返回。

范围分片算法的 doSharding() 执行流程:从
RangeShardingValue.getValueRange()
方法获取分片键的数值范围,然后经过计算得出相应编号,最终在
availableTargetNames
可用目标分库、分片表集合中选择多个符合的返回。

下面是具体实现分片的逻辑:

/**
 * 自定义标准分片算法
 *
 * @author 公众号:程序员小富
 * @date 2024/03/22 11:02
 */
@Slf4j
public class OrderStandardCustomAlgorithm implements StandardShardingAlgorithm<Long> {

    /**
     * 精准分片进入 sql中有 = 和 in 等操作符会执行
     *
     * @param availableTargetNames 所有分片表的集合
     * @param shardingValue        分片健的值,SQL中解析出来的分片值
     */
    @Override
    public String doSharding(Collection<String> availableTargetNames,
                             PreciseShardingValue<Long> shardingValue) {
        /**
         * 分库策略使用时:availableTargetNames 参数数据为分片库的集合 ["db0","db1"]
         * 分表策略使用时:availableTargetNames 参数数据为分片库的集合 ["t_order_0","t_order_1","t_order_2"]
         */
        log.info("进入精准分片 precise availableTargetNames:{}", JSON.toJSONString(availableTargetNames));

        /**
         * 分库策略使用时: shardingValue 参数数据:{"columnName":"order_id","dataNodeInfo":{"paddingChar":"0","prefix":"db","suffixMinLength":1},"logicTableName":"t_order","value":1}
         * 分表策略使用时: shardingValue 参数数据:{"columnName":"order_id","dataNodeInfo":{"paddingChar":"0","prefix":"t_order_","suffixMinLength":1},"logicTableName":"t_order","value":1}
         */
        log.info("进入精准分片 preciseShardingValue:{}", JSON.toJSONString(shardingValue));
        int tableSize = availableTargetNames.size();
        // 真实表的前缀
        String tablePrefix = shardingValue.getDataNodeInfo().getPrefix();
        // 分片健的值
        long orderId = shardingValue.getValue();
        // 对分片健取模后确定位置
        long mod = orderId % tableSize;
        return tablePrefix + mod;
    }

    /**
     * 范围分片进入 sql中有 between 和  < > 等操作符会执行
     *
     * @param availableTargetNames 所有分片表的集合
     * @param shardingValue        分片健的值,SQL中解析出来的分片值
     * @return
     */
    @Override
    public Collection<String> doSharding(Collection<String> availableTargetNames,
                                         RangeShardingValue<Long> shardingValue) {
        /**
         * 分库策略使用时:availableTargetNames 参数数据为分片库的集合 ["db0","db1"]
         * 分表策略使用时:availableTargetNames 参数数据为分片库的集合 ["t_order_0","t_order_1","t_order_2"]
         */
        log.info("进入范围分片:range availableTargetNames:{}", JSON.toJSONString(availableTargetNames));


        /**
         * 分库策略使用时 shardingValue 参数数据:{"columnName":"order_id","dataNodeInfo":{"paddingChar":"0","prefix":"db","suffixMinLength":1},"logicTableName":"t_order","valueRange":{"empty":false}}
         * 分表策略使用时 shardingValue 参数数据:{"columnName":"order_id","dataNodeInfo":{"paddingChar":"0","prefix":"t_order_","suffixMinLength":1},"logicTableName":"t_order","valueRange":{"empty":false}}
         */
        log.info("进入范围分片:rangeShardingValue:{}", JSON.toJSONString(shardingValue));
        // 分片健值的下边界
        Range<Long> valueRange = shardingValue.getValueRange();
        Long lower = valueRange.lowerEndpoint();
        // 分片健值的上边界
        Long upper = valueRange.upperEndpoint();
        // 真实表的前缀
        String tablePrefix = shardingValue.getDataNodeInfo().getPrefix();
        if (lower != null && upper != null) {
            // 分片健的值
            long orderId = upper - lower;
            // 对分片健取模后确定位置
            long mod = orderId % availableTargetNames.size();
            return Arrays.asList(tablePrefix + mod);
        }
        //
        return Collections.singletonList("t_order_0");
    }

    @Override
    public Properties getProps() {
        return null;
    }

    /**
     * 初始化配置
     *
     * @param properties
     */
    @Override
    public void init(Properties properties) {
        Object prop = properties.get("prop");
        log.info("配置信息:{}", JSON.toJSONString(prop));
    }
}

配置算法

在实现了自定义分片算法的两个
doSharding()
核心逻辑之后,接着配置并使用定义的算法。配置属性包括
strategy
分片策略类型设置成
standard

algorithmClassName
自定义标准算法的实现类全路径。需要注意的是:
策略和算法类型必须保持一致,否则会导致错误

spring:
  shardingsphere:
    rules:
      sharding:
        # 分片算法定义
        sharding-algorithms:
          t_order_database_mod:
            type: MOD
            props:
              sharding-count: 2 # 指定分片数量
          # 12、自定义 STANDARD 标准算法
          t_order_standard_custom_algorithm:
            type: CLASS_BASED
            props:
              # 分片策略
              strategy: standard
              # 分片算法类
              algorithmClassName: com.shardingsphere_101.algorithm.OrderStandardCustomAlgorithm
              # 自定义属性
              prop:
                aaaaaa: 123456
                bbbbbb: 654321
        tables:
          # 逻辑表名称
          t_order:
            # 数据节点:数据库.分片表
            actual-data-nodes: db$->{0..1}.t_order_${0..2}
            # 分库策略
            database-strategy:
              standard:
                sharding-column: order_id
                sharding-algorithm-name: t_order_database_mod
            # 分表策略
            table-strategy:
              standard:
                sharding-column: order_id
                sharding-algorithm-name: t_order_standard_custom_algorithm

测试算法

在插入测试数据时,默认会自动进入精确分片的 doSharding() 方法内,看到该方法会获取分片键的数值,根据我们的计算规则确定返回一个目标分片表用于路由。

接着执行一个范围查询的 SQL,此时将进入范围分片的 doSharding() 方法。通过观察
shardingValue.getValueRange()
方法中分片键的数值范围,可以发现这些数值范围是从SQL查询中解析得到的。

select * from t_order where order_id > 1 and order_id < 10

自定义 COMPLEX 算法

复合分片算法支持包含 >,>=, <=,<,=,IN 和 BETWEEN AND 等操作符的SQL,支持多分片健。

自定义
COMPLEX
复合分片算法,需要我们实现
ComplexKeysShardingAlgorithm<T>
接口(其中 T 代表接收的分片键值类型),并重写该接口内部的 3 个方法。其中,主要关注用于处理核心分片逻辑的 doSharding()方法,可以返回多个分片数据源或分片表数据;其他两个配置方法与上述类似,这里不再赘述。

重写复合分片方法 doSharding(Collection availableTargetNames, ComplexKeysShardingValue shardingValues) 实现定制的多分片健逻辑,该方法有两个参数:一个是可用目标分库、分表的集合;另一个是多分片健属性对象。

logicTableName
为逻辑表名,
columnNameAndShardingValuesMap
用于存储多个分片键和对应的键值,
columnNameAndRangeValuesMap
用于存储多个分片键和对应的键值范围。

ComplexKeysShardingValue
数据结构如下:

public final class ComplexKeysShardingValue<T extends Comparable<?>> implements ShardingValue {
    // 逻辑表
    private final String logicTableName;
    // 多分片健及其数值
    private final Map<String, Collection<T>> columnNameAndShardingValuesMap;
    // 多分片健及其范围数值
    private final Map<String, Range<T>> columnNameAndRangeValuesMap;
}

核心流程:通过循环 Map 得到多个分片健值进行计算,从 availableTargetNames 可用目标分库、分片表集合中选择多个符合条件的返回。

/**
 * 自定义复合分片算法
 *
 * @author 公众号:程序员小富
 * @date 2024/03/22 11:02
 */
@Slf4j
public class OrderComplexCustomAlgorithm implements ComplexKeysShardingAlgorithm<Long> {

    /**
     * 复合分片算法进入,支持>,>=, <=,<,=,IN 和 BETWEEN AND 等操作符
     *
     * @param availableTargetNames 所有分片表的集合
     * @param complexKeysShardingValue        多个分片健的值,并SQL中解析出来的分片值
     */
    @Override
    public Collection<String> doSharding(Collection<String> availableTargetNames,
                                         ComplexKeysShardingValue<Long> complexKeysShardingValue) {

        /**
         * 分库策略使用时:availableTargetNames 参数数据为分片库的集合 ["db0","db1"]
         * 分表策略使用时:availableTargetNames 参数数据为分片库的集合 ["t_order_0","t_order_1","t_order_2"]
         */
        log.info("进入复合分片:complex availableTargetNames:{}", JSON.toJSONString(availableTargetNames));

        // 多分片健和其对应的分片健范围值
        Map<String, Range<Long>> columnNameAndRangeValuesMap = complexKeysShardingValue.getColumnNameAndRangeValuesMap();
        log.info("进入复合分片:columnNameAndRangeValuesMap:{}", JSON.toJSONString(columnNameAndRangeValuesMap));

        columnNameAndRangeValuesMap.forEach((columnName, range) -> {
            // 分片健
            log.info("进入复合分片:columnName:{}", columnName);
            // 分片健范围值
            log.info("进入复合分片:range:{}", JSON.toJSONString(range));
        });

        // 多分片健和其对应的分片健值
        Map<String, Collection<Long>> columnNameAndShardingValuesMap = complexKeysShardingValue.getColumnNameAndShardingValuesMap();
        log.info("进入复合分片:columnNameAndShardingValuesMap:{}", JSON.toJSONString(columnNameAndShardingValuesMap));
        columnNameAndShardingValuesMap.forEach((columnName, shardingValues) -> {
            // 分片健
            log.info("进入复合分片:columnName:{}", columnName);
            // 分片健值
            log.info("进入复合分片:shardingValues:{}", JSON.toJSONString(shardingValues));
        });

        return null;
    }
}

配置算法

处理完复合分片算法的
doSharding()
核心逻辑,接着配置使用定义的算法,配置属性包括
strategy
分片策略类型设置成
complex

algorithmClassName
自定义算法的实现类全路径。

需要注意:配置分片键时,一定要使用
sharding-columns
表示复数形式,很容易出错。

spring:
  shardingsphere:
    rules:
      sharding:
        sharding-algorithms:
          t_order_database_mod:
            type: MOD
            props:
              sharding-count: 2 # 指定分片数量
          # 13、自定义 complex 标准算法
          t_order_complex_custom_algorithm:
            type: CLASS_BASED
            props:
              # 分片策略
              strategy: complex
              # 分片算法类
              algorithmClassName: com.shardingsphere_101.algorithm.OrderComplexCustomAlgorithm
              # 自定义属性
              aaaaaa: aaaaaa
        tables:
          # 逻辑表名称
          t_order:
            # 数据节点:数据库.分片表
            actual-data-nodes: db$->{0..1}.t_order_${0..2}
            # 分库策略
            database-strategy:
              standard:
                sharding-column: order_id
                sharding-algorithm-name: t_order_database_mod
            # 分表策略
            table-strategy:
              complex:
                sharding-columns: order_id , user_id
                sharding-algorithm-name: t_order_complex_custom_algorithm

测试算法

插入测试数据,debug 进入 doSharding() 方法,看到
columnNameAndShardingValuesMap
内获取到了 user_id
、order_id 两个分片键及健值。

当执行范围查询的SQL,
columnNameAndRangeValuesMap
属性内获取到了 user_id、order_id 两个分片键及健值范围,通过range.upperEndpoint()、lowerEndpoint()得到上下界值。

select * from t_order where order_id > 1 and user_id > 1;

自定义 HINT 算法

要实现自定义
HINT
强制路由分片算法,需要实现
HintShardingAlgorithm<T>
接口( T 代表接收的分片键值类型)。在实现过程中,需要重写接口中的3个方法。其中,核心的分片逻辑在 doSharding() 方法中处理,可以支持返回多个分片数据源或分片表数据。另外,其他两个prop配置方法的使用方式与上述相同,这里不赘述。

重写 HINT 核心分片方法 doSharding(Collection availableTargetNames, HintShardingValue shardingValue),以实现我们的定制逻辑。该方法接受两个参数:一个是可用目标分库、分表的集合,另一个是 Hint 分片属性对象。

方法内执行流程:我们首先获取
HintManager API
设置的分库或分表的分片值,经过计算后得到合适的分片数据源或分片表集合,然后直接路由到目标位置,无需再关注SQL本身的条件信息。

/**
 * 自定义强制路由分片算法
 *
 * @author 公众号:程序员小富
 * @date 2024/03/22 11:02
 */
@Slf4j
public class OrderHintCustomAlgorithm implements HintShardingAlgorithm<Long> {

    @Override
    public Collection<String> doSharding(Collection<String> availableTargetNames, HintShardingValue<Long> hintShardingValue) {

        /**
         * 获取到设置的分表或者分库的分片值
         * 指定分表时的分片值  hintManager.addTableShardingValue("t_order",2L);
         * 指定分库时的分片值  hintManager.addDatabaseShardingValue("t_order", 100L);
         */
        Collection<Long> values = hintShardingValue.getValues();
        Collection<String> result = new ArrayList<>();
        // 从所有分片表中得到合适的分片表
        for (String each : availableTargetNames) {
            for (Long value : values) {
                Long mod = value % availableTargetNames.size();
                if (each.endsWith(String.valueOf(mod))) {
                    result.add(each);
                }
            }
        }
        return result;
    }
}

配置算法

配置自定义Hint算法,配置属性包括
strategy
分片策略类型设置成
hint

algorithmClassName
自定义Hint算法的实现类全路径。使用该算法时无需指定分片健!

spring:
  shardingsphere:
    # 具体规则配置
    rules:
      sharding:
        # 分片算法定义
        sharding-algorithms:
          t_order_database_mod:
            type: MOD
            props:
              sharding-count: 2 # 指定分片数量
          # 14、自定义 hint 标准算法
          t_order_hint_custom_algorithm:
            type: CLASS_BASED
            props:
              # 分片策略
              strategy: hint
              # 分片算法类
              algorithmClassName: com.shardingsphere_101.algorithm.OrderHintCustomAlgorithm
              # 自定义属性
              bbbbbb: bbbbbb
        tables:
          # 逻辑表名称
          t_order:
            # 数据节点:数据库.分片表
            actual-data-nodes: db$->{0..1}.t_order_${0..2}
            # 分库策略
            database-strategy:
              hint:
                sharding-algorithm-name: t_order_database_mod
            # 分表策略
            table-strategy:
              hint:
                sharding-algorithm-name: t_order_hint_custom_algorithm

测试算法

在执行SQL操作之前,使用
HintManager API

addDatabaseShardingValue

addTableShardingValue
方法来指定分库或分表的分片值,这样算法内通过
HintShardingValue
可以获取到分片值。注意:
如果在执行 SQL 时没有使用 HintManager 指定分片值,那么执行SQL将会执行全库表路由

@DisplayName("Hint 自动义分片算法-范围查询")
@Test
public void queryHintTableTest() {

    HintManager hintManager = HintManager.getInstance();
    // 指定分表时的分片值
    hintManager.addTableShardingValue("t_order",2L);
    // 指定分库时的分片值
    hintManager.addDatabaseShardingValue("t_order", 100L);

    QueryWrapper<OrderPo> queryWrapper = new QueryWrapper<OrderPo>()
            .eq("user_id", 20).eq("order_id", 10);
    List<OrderPo> orderPos = orderMapper.selectList(queryWrapper);
    log.info("查询结果:{}", JSON.toJSONString(orderPos));
}

到这关于 shardingsphere-jdbc 的 3种自定义分片算法实现就全部结束了。

总结

本文介绍了 STANDARD、COMPLEX 和 HINT 三种自定义分片算法的实现,和使用过程中一些要注意的事项。ShardingSphere 内置的十几种算法,其实已经可以满足我们绝大部分的业务场景,不过,如果考虑到后续的性能优化和扩展性,定制分片算法是个不错的选择。

全部demo案例
GitHub
地址:
https://github.com/chengxy-nds/Springboot-Notebook/tree/master/shardingsphere101/shardingsphere-algorithms

我是小富~ 下期见

1、Seata介绍

Seata是阿里开源的一款分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。数据库事务我们都知道,事务都是遵循ACID原则。而通过使用Seata可以实现在两个服务模块通过RPC调用时触发事务,如果有异常会实现业务数据回滚,保证数据的一致性。

官网地址:
https://seata.io/zh-cn/

GitHub地址:
https://github.com/seata/seata

由于在北京时间2023年10月29日,该分布式事务开源项目 Seata 正式通过 Apache 基金会的投票决议,以全票通过的优秀表现正式成为 Apache 孵化器项目!详细信息可查看:
https://developer.aliyun.com/article/1379627
,所以现在官网最新地址为:

最新官网地址:
https://seata.apache.org/zh-cn/
https://seata.apache.org/zh-cn/docs/overview/what-is-seata

GitHub地址:
https://github.com/apache/incubator-seata

Apache孵化器地址:
https://incubator.apache.org/clutch/seata.html

2、Seata下载1.3.0

根据使用的Spring Cloud Alibaba版本下载推荐的Seata版本

https://github.com/apache/incubator-seata/releases

3、Seata服务配置

3.1、修改配置文件存储模式为使用DB高可用模式

Seata默认使用 file 模式,使用file模式启动完成可以看到持久化的本地文件root.data,除了file模式外还支持DB、redis, Seata的高可用依赖于注册中心、配置中心和数据库来实现。所以这里我们配置为DB模式。首先下载对应版本的Mysql数据库:
https://github.com/apache/incubator-seata/blob/v1.3.0/script/server/db/mysql.sql
下载成功后,把数据库表信息导入MySQL数据库。导入成功后会生成3张表:

进入seata目录修改seata/conf下面的file.conf文件store.mode属性为db,如果没有file.conf文件,把file.conf.example文件拷贝一份进行重新命名。

配置成功后。文件下面有个db属性,在db属性里面配置数据库连接信息:

db {
    ## the implement of javax.sql.DataSource, such as DruidDataSource(druid)/BasicDataSource(dbcp)/HikariDataSource(hikari) etc.
    datasource = "druid"
    ## mysql/oracle/postgresql/h2/oceanbase etc.
    dbType = "mysql"
    driverClassName = "com.mysql.cj.jdbc.Driver"
    url = "jdbc:mysql://127.0.0.1:3306/seata"
    user = "root"
    password = "1234qwer"
    minConn = 5
    maxConn = 30
    globalTable = "global_table"
    branchTable = "branch_table"
    lockTable = "lock_table"
    queryLimit = 100
    maxWait = 5000
  }

3.2、修改seata配置中心和注册中心实现高可用

进入seata目录的seata/conf里面,先将registry.conf文件拷贝一份registry.conf.init以防万一改错了,接下来编辑registry.conf。首先把注册中心改为nacos。设置registry属性类型为nacos,然后在nacos属性中配置nacos连接信息

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "nacos"

  nacos {
    application = "seata-server"
    serverAddr = "127.0.0.1:8848"
    group = "SEATA_GROUP"
    namespace = "233b70c2-d6a8-482b-8a8d-e000b7a5c3a2"
    cluster = "default"
    username = "nacos"
    password = "1234qwer"
  }

在将配置中心也设置为nacos,config属性类型为nacos

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "nacos"

  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = "233b70c2-d6a8-482b-8a8d-e000b7a5c3a2"
    group = "SEATA_GROUP"
    username = "nacos"
    password = "1234qwer"
  }
}

部署文档:
https://seata.io/zh-cn/docs/v1.3/ops/deploy-guide-beginner
https://seata.apache.org/zh-cn/docs/v1.3/ops/deploy-guide-beginner/
Seata高可用部署:
https://seata.io/zh-cn/docs/v1.3/ops/deploy-ha
https://seata.apache.org/zh-cn/docs/v1.3/ops/deploy-ha/

4、上传配置文件到nacos

4.1 创建config.txt

在seata目录里面创建一个config.txt文件在改文件中添加配置信息,配置信息可以参考
https://github.com/apache/incubator-seata/blob/v1.3.0/script/config-center/config.txt
也可以直接下载改文件。主要修改下面的信息:


//my_test_tx_group是可以自定义的修改成功后后面客户端集成要与服务器端一致,也可以不修改。
service.vgroupMapping.my_test_tx_group=default  

//把file改为db
store.mode= db 

//修改数据库连接信息
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.cj.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true
store.db.user=root
store.db.password=1234qwer

4.2 创建nacos-config.sh

在seata目录里面创建一个nacos-config.sh启动脚本文件,添加文件内容可以参考
https://github.com/apache/incubator-seata/blob/v1.3.0/script/config-center/nacos/nacos-config.sh
也可以直接下载。修改nacos连接信息

if [[ -z ${host} ]]; then
    host=127.0.0.1
fi
if [[ -z ${port} ]]; then
    port=8848
fi
if [[ -z ${group} ]]; then
    group="SEATA_GROUP"
fi
if [[ -z ${tenant} ]]; then
    tenant="96a4551b-b576-4047-88e9-c17ed48342ae"
fi
if [[ -z ${username} ]]; then
    username="nacos"
fi
if [[ -z ${password} ]]; then
    password="1234qwer"
fi

host: nacos连接地址
port: nacos连接端口号
group:分组
tenant:命名空间namespace
username:用户名
password:密码
修改成功后执行该脚本,把config.txt文件内容导入nacos。

输出以上内容,说明脚本执行成功。查看nacos配置中心:

配置已经成功导入到nacos

5、启动Seata

启动命令进入seata/bin文件路径下执行 seata-server.sh 脚本启动。

./seata-server.sh > /dev/null 2>&1 &

使用
ps -ef|grep seata
目录查看是否启动成功。

查看nacos注册中心,看看服务是否存在。


发现该服务在注册中心已经注册成功了,说明seata服务搭建成功。客户端连接端口号为:
IP:8091