老话说的好：人不可貌相，海水不可斗量。以貌取人是非常不好的，我们要平等的对待每一个人。
2. 分布式全局ID
2.1 分布式数据库引发的问题
在数据库中，每个表都有一个主键（ID），用于作为一条数据的唯一标识。
在单体数据库中，大多数时候，我们会采用主键自增的方式生成 ID。
但在分布式的数据库中，使用了分库分表后，数据会被分配到多个表中，这时再用主键自增的方式就不合适了，每张表的 ID 都是从 0 开始自增，多个表中会出现重复的 ID，从而引发业务问题。
2.2 分布式全局ID的常用策略
2.2.1 UUID
UUID 我们再熟悉不过了，即使是单体数据库，我们也常常会使用 UUID 作为 ID 的值。
UUID的好处是使用简单，一句Java代码就能简单的生成，而且保证绝对全局唯一。
UUID也有不好的地方，一个是长度较长，至少需要32位，而且只是单纯的ID，没有实际意义，也不能作为排序的依据。
之前介绍过的 MyCat 和 ShardingJDBC 都有自动生成ID的机制，但 MyCat 不支持 UUID。
我们也可以使用工具类帮我们生成UUID，或者使用框架生成，例如：JPA。
2.2.2 雪花算法
雪花算法生成的ID，是一个 64bit 的 Long 型数字，是一个递增的数字，可用于排序。
雪花算法基本可以保持全局唯一，毫秒内可并发4096个数字。
但时间的回调可能会引起 ID 的重复。
3. 分布式事务
3.1 分布式数据库导致的事务问题
事务这个词，我们并不陌生，在单体数据库中，所有的业务表都在一个数据库中，在 SpringBoot 中我们常常会使用 @Transactional 注解去保证事务。
但到了分布式数据库，常常会根据业务对数据库进行 垂直切分 和 水平切分，一个业务方法常常会操作两个或多个数据源，此时 @Transactional 注解 就无法保证事务了。
3.2 分布式事务的常用策略
3.2.1 基于XA协议的两阶段提交
两阶段提交，分为两个阶段，准备阶段 和 提交阶段。
简单理解就是 所有的事务先准备成功后，然后一起提交，如果有一个事务准备失败，所有事务都会回滚。
如果在提交阶段出现了问题，则会造成事务的不一致，需要人工介入。
在两阶段提交过程中，在所有事务没有完全提交完成前，数据是锁死状态，其他线程访问会被阻塞。
由于两阶段提交需要等待所有的事务提交完成，因此效率低下，性能与本地事务相差10倍，用户体验不是很好。
在生产环境不建议使用。
3.2.2 事务补偿机制（TCC）
TTC就是 try、confirm、cancel，简单说就是每个操作都有一个对应的取消（cancel）方法，如果执行失败，则调用取消（cancel）方法撤销之前的操作。
如果取消（cancel）方法执行时发生了错误，则需要定时任务去轮询补偿，或者人工介入。
事务补偿机制的好处是逻辑比较简单，先执行 A 事务，再执行 B 事务，B 事务执行失败了，则调用 A 事务的取消（cancel）方法撤销 A事务 之前的操作。
但需要程序员自己编写的代码较多，无形中增加了很多工作量，且容易出错。
3.2.3 使用消息队列（MQ）实现最终一致性
利用消息队列的机制，异步的去执行每一个事务，达到最终一致。
通常的做法是 在本地维护一个消息表，或者给业务数据增加一个消息状态字段。
将后续的操作以消息的形式发送到消息队列，消息队列收到消息后给予Ack回执，收到回执后修改消息的状态。
消费者从消息队列订阅消息，执行接下来的逻辑，要注意消费方法的幂等性。
当然还需要有一个定时程序，轮询消息表，发现有问题的消息，执行重发或修改状态人工介入。
推荐以这种方式实现分布式事务。
4. 综述
今天聊了一下 分布式全局ID与分布式事务，希望可以对大家的工作有所帮助。
欢迎帮忙点赞、评论、转发、加关注 ：）
关注追风人聊Java，每天更新Java干货。
5. 个人公众号
追风人聊Java，欢迎大家关注