大家好，今天我们来一起探讨分布式事务的相关知识。相信大家都有多多少少接触过分布式事务，因为我们现在写的代码可是服务于亿级用户量级的，那么大的请求量级不可能全部写在一台服务器上面对吧。如果你还没有研究过分布式事务，也没关系，我们今天再一起来探讨一番。我曾经接触过分布式事务相关的中间件框架，比如现在很火的阿里开源的一款分布式事务中间件Seata。目前我在Seata社区主要做一些RPC以及性能优化的相关工作，所以我可能会对分布式事务具体实现比较了解。以Seata为契机，我们一起来探讨分布式事务。
Seata 目前支持 AT 模式、XA 模式、TCC 模式和 SAGA 模式，之前文章更多谈及的是非侵入式的 AT 模式，今天带大家认识一下同样是二阶段提交的 TCC 模式。
Seata AT 模式是一种非侵入式的分布式事务解决方案，Seata 在内部做了对数据库操作的代理层，我们使用 Seata AT 模式时，实际上用的是 Seata 自带的数据源代理 DataSourceProxy，Seata 在这层代理中加入了很多逻辑，比如插入回滚 undo_log 日志，检查全局锁等。
为什么要检查全局锁呢，这是由于 Seata AT 模式的事务隔离是建立在支事务的本地隔离级别基础之上的，在数据库本地隔离级别读已提交或以上的前提下，Seata 设计了由事务协调器维护的全局写排他锁，来保证事务间的写隔离，同时，将全局事务默认定义在读未提交的隔离级别上。
Raft 是一种为了管理复制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能，但是它的算法结构和 Paxos 不同，使得 Raft 算法更加容易理解并且更容易构建实际的系统。为了提升可理解性，Raft 将一致性算法分解成了几个关键模块，例如领导人选举、日志复制和安全性。同时它通过实施一个更强的一致性来减少需要考虑的状态的数量。一项用户研究的结果表明，对于学生而言，Raft 算法比 Paxos 算法更加容易学习。Raft 算法还包括一个新的机制来允许集群成员的动态改变，它利用重叠的大多数来保证安全性。
互联网的系统常常面临庞大的用户群体，意味着系统需要时刻面临着大量高并发请求，海量的数据存储等问题的挑战，在解决这些问题的同时还要保证系统的高可用性。同时互联网行业更新迭代快，很多互联网巨头的发展初始阶段，为了快速把产品上线发布以占据用户流量，会以最简单的应用架构形态对系统进行部署，不会过多地考虑未来的应用架构的发展，所以很多互联网公司发展到一定规模，都会进行相应的架构重构与改进，以便适应业务的发展。
我这几年经历过很多家公司，从几个开发人员的小公司到拥有 10+ 亿用户规模的公司都经历过，因此我对互联网公司的系统应用架构的演进有着一些深刻的感悟。
前几天在帮同事排查生产一个线上偶发的线程池错误
逻辑很简单，线程池执行了一个带结果的异步任务。但是最近有偶发的报错：
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@a5acd19 rejected from java.util.concurrent.ThreadPoolExecutor@30890a38[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
本文中的模拟代码已经问题都是在HotSpot java8 (1.8.0_221)版本下模拟&出现的。
大家都知道,计算机的瓶颈之一就是IO,为了解决内存与磁盘速度不匹配的问题,产生了缓存,将一些热点数据放在内存中,随用随取,降低连接到数据库的请求链接,避免数据库挂掉。
TCC 分布式事务模型直接作用于服务层。不与具体的服务框架耦合，与底层 RPC 协议无关，与底层存储介质无关，可以灵活选择业务资源的锁定粒度，减少资源锁持有时间，可扩展性好，可以说是为独立部署的 SOA 服务而设计的。
在两阶段提交协议（2PC，Two Phase Commitment Protocol）中，资源管理器（RM, resource manager）需要提供“准备”、“提交”和“回滚” 3 个操作；而事务管理器（TM, transaction manager）分 2 阶段协调所有资源管理器，在第一阶段询问所有资源管理器“准备”是否成功，如果所有资源均“准备”成功则在第二阶段执行所有资源的“提交”操作，否则在第二阶段执行所有资源的“回滚”操作，保证所有资源的最终状态是一致的，要么全部提交要么全部回滚。
消息中间件是分布式系统常用的组件，无论是异步化、解耦、削峰等都有广泛的应用价值。我们通常会认为，消息中间件是一个可靠的组件——这里所谓的可靠是指，只要我把消息成功投递到了消息中间件，消息就不会丢失，即消息肯定会至少保证消息能被消费者成功消费一次，这是消息中间件最基本的特性之一，也就是我们常说的“AT LEAST ONCE”，即消息至少会被“成功消费一遍”。