分布式架构
=====================
分布式事务产生的场景:
跨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);
}
}