领域驱动设计：

什么是领域驱动设计(DDD)

领域驱动设计是一种软件开发方法，它围绕业务概念构建领域模型，指导我们将复杂问题进行拆分，解决大型复杂系统在落地中遇到的问题，设计出能够准确表达业务意图的软件模型。

功能：

1. 支持嵌套分布式事务。
2. 支持二阶段异步提交。
3. 支持二阶段延迟提交。秒杀抢购等业务峰值时可以将二阶段延迟到低峰期执行。

从业务服务

POM引入

1
2
3
4
5

<dependency>
    <groupId>cn.blogxin</groupId>
    <artifactId>dt-client-api</artifactId>
    <version>0.0.1-SNAPSHOT</version>
</dependency>

SpringBoot-Starter

基于前面开发好的模块，创建SpringBoot-Starter进行整合，通过Spring-Boot的加载机制进行分布式事物组件DT的自动装配，便于使用。

pom文件：

在项目的pom文件中定义之前开发过程中需要使用的模块，以及使用的相关依赖。

Transaction Coordinator：事务协调器。维护分布式事务的状态，负责对分布式事务进行补偿提交或回滚。

事务协调器定义的接口如下：

Resource Manager：资源管理器。控制分支事务，负责分支注册、状态汇报，驱动分支事务的提交和回滚。

资源管理器器定义的接口如下：

Transaction Manager：事务管理器。控制分布式事务的边界，负责开启一个分布式事务，并最终发起分布式事务提交或回滚的决议。

事务管理器定义的接口如下：

事务记录是用来记录每笔分布式事务状态的记录以及事务中各个分支事务状态的记录，需要在实际事务操作发生前，先写入到事务记录表，再进行事务操作，如果遇到异常情况，就可以根据存储的事务记录，通过二阶段接口进行分布式事务的恢复，来保证分布式事务的最终一致性。

这种数据恢复的思路也叫做WAL(Write-Ahead-Log) 预写式日志 ，该机制用于数据的容错和恢复，在数据写入到数据库之前，先写入到日志，再将日志记录变更到存储器中。

根据上篇描述的实现思路和原理，进行功能拆解和组件的划分，梳理出如下整体架构图：

在工作的过程中，经常会遇到一些分布式环境下数据一致性的问题，尤其是在做一些交易、支付、账户等业务的时候，其中不可避免的会涉及到一些分布式事务领域的技术方案，在之前的工作中也曾经使用过分布式事务框架来解决问题，一直对这一领域的问题十分感兴趣，所以就想着自己动手造个轮子，从零开始写一个分布式事务框架，以此加深自己对分布式事务的理解和在系统架构与实现上的经验积累，在这里记录一下自己造轮子过程中的过程和思考。

一般随着业务的高速发展，业务量越来越大，业务也越来越复杂，数据量也越来越大，数据库层面的优化通常会使用分库分表、主从读写分离的策略进行扩展。本文介绍了分库分表，主从读写分离的优缺点，并对其中一种实现方案进行了原理描述，并亲自动手实现了一个可实用的demo。

分表的优缺点

垂直拆分：

垂直拆分分表指的是将一张大表根据业务、字段冷热、大字段等因素，拆分成多个结构不同的表。

为什么要做多活

多活架构主要是为了提升系统的容灾能力，提高系统的可用性，保障业务持续可用。比如单机房的网络故障、地震火灾等不可抗因素，都有可能造成整个机房瘫痪，对业务的可用性造成严重影响。多活架构还可以解决单机房容量问题，提高系统的扩展能力。

SpringBoot是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。

下面通过源码来了解下SpringBoot的启动流程。(展示代码基于2.1.1.RELEASE)

1
2
3
4
5
6
7

@SpringBootApplication
public class DemoApplication {
	public static void main(String[] args) {
		SpringApplication.run(DemoApplication.class, args);
	}
}

问题背景

线上突然收到某应用端口报警，登陆服务器后，发现机器上的Java应用进程莫名其妙的消失了，便进行了一番排查，并把排查分析的过程做了下总结记录。

随着业务的发展，为了提高系统的可用性，可维护性等，单一系统逐渐分解为业务功能独立的多个微服务组成的分布式系统集群，事务处理能力也被拆解到各个微服务中。这个时候一笔交易会涉及到交易，支付，券，账户等多个微服务系统的交互，多个微服务之间的交互如何保证上下游系统的数据一致性，就成了在日常研发过程中比较头疼的事情。