分布式架构（分布式ID+分布式事务） - 服务器托管|北京服务器租用|机房托管租用|IDC托管租用|机房机柜带宽租用-价格及费用咨询

分布式架构

=====================

分布式事务产生的场景：

跨JVM进程产生的分布式事务

单体系统访问多个数据库实例

多服务访问同一个数据库实例

CAP理论

C：一致性，指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意节点读取到的数据都是最新状态。
写入主数据库后要将数据同步到从数据库
写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入成功后，向从数据库查询到旧的数据

A：可用性，指任何事务操作都可以得到响应结果，且不会出现响应超时或响应错误。
写入主数据库后要将数据同步到从数据库
由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定
即使数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照约定返回一个默认的信息，但不能返回错误或响应超时。

P：分区容忍性，网络分区的不同结点出现的网络问题导致节点之间通信失败，此时仍然可以对外提供服务。
尽量使用异步取代同步操作，使用异步方式将数据从主数据库同步到从数据库，这样节点之间能够有效的实现松耦合
添加从数据库节点，其中一个节点挂掉后，其他从节点提供服务。

CAP组合

Base理论

========================================

分布式事务解决方案

2PC 两阶段提交

XA方案
需要本地数据库支持XA协议
资源锁需要等到两个阶段结束才释放，性能较差

Seata方案
阿里中间件，分布式事务框架
提供AT模式（2PC）以及TCC模式的分布式事务解决方案
把分布式事务理解为一个包含了若干分支事务的全局事务，全局事务的职责是协调其下管辖的分支事务达成一致
要么一起成功提交，要么一起失败回滚。

程序实现

配置文件
application.yml
application-local.yml
file.conf

dtx-seata-demo-bank1
张三账户减少金额，开启全局事务
远程调用bank2向李四转账

//Dao   MyBatis框架进行
@Mapper
@Component
public interface AccountInfoDao{
	@Update("update account_info set account_blance = account_balance + #{amount} where account_no = #{accountNo}")
	int updateAccountBalnce(@Param("accountNo") String accountNo,@Param("amount") Double amount);
}

//张三扣减金额
public interface AccountInfoService{
	public void updateAccountBalance(String accountNo,Double amount);
}

@Service
@Slf4j
public class AccountInfoServiceImpl implements AccountInfoService{
	@Autowired
	AccountInfoDao accountInfoDao;

	@Autowired
	Bank2Client bank2Client;
	
	@Transactional
	@BlobalTransactional//开启全局事务
	@Override
	public void updateAccountBalance(String accountNo,Double amount{
		//扣除张三的金额
		accountInfoDao.updateAccountBalance(accountNo,amount * -1);
		
		//调用李四的微服务来转账
		String transfer = bank2Client.transfer(amount);
		if("fallback".equals(transfer)){
			服务器托管网//调用李四微服务异常
			throw new RuntimeException("调用李四微服务异常");
		}
	}
}

//FeignClient
@FeignClient(value="seata-demo-bank2",fallback=Bank2ClientFallack.class)//如果调用失败，降级
public interface Bank2Client{
	
	//远程调用李四的微服务
	@GetMapping("/bank2/transfer")
	public String transfer(@RequestParam("amount") Double amout);
}

//调用失败降级
@Component
public class Bank2ClientFallback implements Bank2Client{
	@Override
	public String transfer(Double amount){
		return "fallback";
	}
}

//启动类
@SpringBootApplication
@EnableDiscoveryClient
@EnableHystrix
@EnableFeignClients(basePackages = {"cn.michael.bank1.spring"})//专门扫描客户端的包
public class Bank2Server{
	public static void main(String[] args){
		SpringApplication.run(Bank2Server.class,args);
	}
}

dtx-seata-demo-bank2

//李四账号增加金额
//分支事务，不适用@GlobalTransactional
@Mapper
@Component
public interface AccountInfoDao{
	@Update("UPDATE account_info SET account_balance = account_balance + #{amount} WHERE account_no")
	int updateAccountBalance(@Param("accountNo") String accountNo,@Param("amount") Double amount);
}

public interface AccountInfoService{
	public void updateAccountBalance(String accountNo,Double amount);
}

@Service
@Slf4j
public class AccountInfoServiceImpl implements AccountInfoService{
	@Autowired
	AccountInfoDao accountInfoDao;

	//不使用@GlobalTransactional
	@Transactional
	@Override
	public void updateAccountBalance(String accountNo,Double amount){
		accountaInfoDao.updateAccountBalance(accountNo,amount);
	}
}

=========================================

分布式ID

一、数据库自增

①、创建一个数据库表

stub 字段无意义，只是为了占位，便于插入或者修改数据。并且，给 stub 字段创建了唯一索引，保证其唯一性。

CREATE TABLE `sequence_id` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `stub` char(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `stub` (`stub`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

②、通过replace into 来插入数据

插入数据这里，没有使用 insert into 而是使用 replace into 来插入数据，具体步骤是这样的：

尝试把数据插入到表中
如果主键或唯一索引字段出现重复数据错误而插入失败时，先从表中删除含有重复关键字值的冲突行，然后再次尝试把数据插入到表中

BEGIN;
REPLACE INTO sequence_id (stub) VALUES ('stub');
SELECT LAST_INSERT_ID();
COMMIT;

优点：实现起来比较简单、ID 有序递增、存储消耗空间小
缺点：支持的并发量不大、存在数据库单点问题（可以使用数据库集群解决，不过增加了复杂度）、ID 没有具体业务含义、安全问题（比如根据订单 ID 的递增规律就能推算出每天的订单量，商业机密啊！）、每次获取 ID 都要访问一次数据库（增加了对数据库的压力，获取速度也慢）

二、数据库号段模式

数据库主键自增这种模式，每次获取 ID 都要访问一次数据库，ID 需求比较大的时候性能问题

可以批量获取，然后存在在内存里面，需要用到的时候，直接从内存里面拿就舒服了！这也就是我们说的基于数据库的号段模式来生成分布式 ID
数据库的号段模式也是目前比较主流的一种分布式 ID 生成方式。像滴滴开源的Tinyid[1] 就是基于这种方式来做的。不过，TinyId 使用了双号段缓存、增加多 db 支持等方式来进一步优化。

①、创建一个数据表

current_max_id 字段和step字段主要用于获取批量 ID，获取的批量 id 为：current_max_id ~ current_max_id+step
version 字段主要用于解决并发问题（乐观锁）,biz_type 主要用于表示业务类型。

CREATE TABLE `sequence_id_generator` (
  `id` int(10) NOT NULL,
  `current_max_id` bigint(20) NOT NULL COMMENT '当前最大id',
  `step` int(10) NOT NULL COMMENT '号段的长度',
  `version` int(20) NOT NULL COMMENT '版本号',
  `biz_type`    int(20) NOT NULL COMMENT '业务类型',
   PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

②、先插入一行数据

INSERT INTO `sequence_id_generator` (`id`, `current_max_id`, `step`, `version`, `biz_type`)
VALUES
 (1, 0, 100, 0, 101);

③、通过 SELECT 获取指定业务下的批量唯一 ID

SELECT `current_max_id`, `step`,`version` FROM `sequence_id_generator` where `biz_type` = 101

④、不够用的话，更新之后重新 SELECT 即可。

UPDATE sequence_id_generator SET current_max_id = 0+100, version=version+1 WHERE version = 0  AND `biz_type` = 101
SELECT `current_max_id`, `step`,`version` FROM `sequence_id_generator` where `biz_type` = 101

相比于数据库主键自增的方式，数据库的号段模式对于数据库的访问次数更少，数据库压力更小。
另外，为了避免单点问题，你可以从使用主从模式来提高可用性。

优点：ID 有序递增、存储消耗空间小
缺点：存在数据库单点问题（可以使用数据库集群解决，不过增加了复杂度）、ID 没有具体业务含义、安全问题（比如根据订单 ID 的递增规律就能推算出每天的订单量，商业机密啊！）

三、NoSQL

通过 Redis 的 incr 命令即可实现对 id 原子顺序递增

为了提高可用性和并发，可以使用 Redis Cluster。Redis Cluster 是 Redis 官方提供的 Redis 集群解决方案（3.0+版本）。

除了 Redis Cluster 之外，也可以使用开源的 Redis 集群方案Codis[2] （大规模集群比如上百个节点的时候比较推荐）。

除了高可用和并发之外， Redis 基于内存，我们需要持久化数据，避免重启机器或者机器故障后数据丢失。Redis 支持两种不同的持久化方式：快照（snapshotting，RDB）、只追加文件（append-only file, AOF）。并且，Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。

优点：性能不错并且生成的 ID 是有序递增的
缺点：和数据库主键自增方案的缺点类似

除了 Redis 之外，MongoDB ObjectId 经常也会被拿来当做分布式 ID 的解决方案。

MongoDB ObjectId 一共需要 12 个字节存储：

0~3：时间戳
3~6：代表机器 ID
7~8：机器进程 ID
9~11：自增值

优点：性能不错并且生成的 ID 是有序递增的
缺点：需要解决重复 ID 问题（当机器时间不对的情况下，可能导致会产生重复 ID）、有安全性问题（ID 生成有规律性）

四、算法UUID

UUID 是 Universally Unique Identifier（通用唯一标识符）的缩写。UUID 包含 32 个 16 进制数字（8-4-4-4-12）

JDK 就提供了现成的生成 UUID 的方法，一行代码就行了。

//输出示例：cb4a9ede-fa5e-4585-b9bb-d60bce986eaa
UUID.randomUUID()

不同的版本对应的 UUID 的生成规则是不同的

版本 1 : UUID 是根据时间和节服务器托管网点 ID（通常是 MAC 地址）生成
版本 2 : UUID 是根据标识符（通常是组或用户 ID）、时间和节点 ID 生成
版本 3、版本 5 : 版本 5 – 确定性 UUID 通过散列（hashing）名字空间（namespace）标识符和名称生成
版本 4 : UUID 使用随机性或伪随机性生成

JDK 中通过 UUID 的 randomUUID() 方法生成的 UUID 的版本默认为 4

UUID uuid = UUID.randomUUID();
int version = uuid.version();// 4

UUID 可以保证唯一性，因为其生成规则包括 MAC 地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素，计算机基于这些规则生成的 UUID 是肯定不会重复的。

虽然，UUID 可以做到全局唯一性，但是，我们一般很少会使用它。比如使用 UUID 作为 MySQL 数据库主键的时候就非常不合适：

数据库主键要尽量越短越好，而 UUID 的消耗的存储空间比较大（32 个字符串，128 位）
UUID 是无顺序的，InnoDB 引擎下，数据库主键的无序性会严重影响数据库性能

优点：生成速度比较快、简单易用
缺点：存储消耗空间大（32 个字符串，128 位）、不安全（基于 MAC 地址生成 UUID 的算法会造成 MAC 地址泄露)、无序（非自增）、没有具体业务含义、需要解决重复 ID 问题（当机器时间不对的情况下，可能导致会产生重复 ID）

五、算法雪花

Snowflake 是 Twitter 开源的分布式 ID 生成算法。Snowflake 由 64 bit 的二进制数字组成，这 64bit 的二进制被分成了几部分，每一部分存储的数据都有特定的含义：

sign(1bit):符号位（标识正负），始终为 0，代表生成的 ID 为正数
timestamp (41 bits):一共 41 位，用来表示时间戳，单位是毫秒，可以支撑 2 ^41 毫秒（约 69 年）
datacenter id + worker id (10 bits):一般来说，前 5 位表示机房 ID，后 5 位表示机器 ID（实际项目中可以根据实际情况调整）。这样就可以区分不同集群/机房的节点。
sequence (12 bits):一共 12 位，用来表示序列号。序列号为自增值，代表单台机器每毫秒能够产生的最大 ID 数(2^12 = 4096),也就是说单台机器每毫秒最多可以生成 4096 个唯一 ID。

在实际项目中，一般也会对 Snowflake 算法进行改造，最常见的就是在 Snowflake 算法生成的 ID 中加入业务类型信息。

优点：生成速度比较快、生成的 ID 有序递增、比较灵活（可以对 Snowflake 算法进行简单的改造比如加入业务 ID）
缺点：需要解决重复 ID 问题（ID 生成依赖时间，在获取时间的时候，可能会出现时间回拨的问题，也就是服务器上的时间突然倒退到之前的时间，进而导致会产生重复 ID）、依赖机器 ID 对分布式环境不友好（当需要自动启停或增减机器时，固定的机器 ID 可能不够灵活）。

有很多基于 Snowflake 算法的开源实现比如美团的 Leaf、百度的 UidGenerator（后面会提到），并且这些开源实现对原有的 Snowflake 算法进行了优化，性能更优秀，还解决了 Snowflake 算法的时间回拨问题和依赖机器 ID 的问题。

并且，Seata 还提出了“改良版雪花算法”，针对原版雪花算法进行了一定的优化改良，解决了时间回拨问题，大幅提高的 QPS。

分布式ID开源框架（百度、滴滴等）

=========================================

分布式事务解决方案TCC

TCC需要主义三种异常处理：空回滚幂等悬挂

启动类

@SpringBootApplication
@EnableDiscoveryClient
@EnableHystrix
@EnableAspectAutoProxy //
@EnableFeignClients(basePackages = {"cn.....spring"})
@ComponentScan("xxx.bank1/bank2","org.dromarn.hmily")//要扫描的hmily
public class BankTccServer{
	public static void main(String[] args){
		StringApplication.run(BankTccServer.class,args);
	}
}

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net

相关推荐: MySQL中常用的数据类型

MySQL支持多种数据类型，主要包括以下几类： 1.数值类型：整数类型：tinyint、smallint、mediumint、int、bigint。区别：存储大小和范围不同。 tinyint：占用1字节的存储空间，有符号的范围是-128 ~ 127，无符号…