在单体到微服务架构的迁移过程中，我们经常会问一个问题：在什么情况下我需要从单体中剥离一部分出来将其作为一个微服务？答案有很多，其中有一个答案就是：我发现好多单体都有相似的功能，我觉得可以把它抽出来做一个公共服务。

1987年普林斯顿大学的Hector Garcia-Molina和Kenneth Salem发表了一篇Paper Sagas，讲述的是如何处理long lived transaction（长活事务）。听起来是不是觉得和分布式事务很像？没错，下面来看看这个来自1987年的解决方案是如何启发当今的分布式事务问题的。

在前一篇文章中讲到了BASE模式，这种模式可以应用在单库or跨库事务的场景下。事实上BASE模式不仅仅局限于数据库层面，还可以应用于分布式系统，这类分布式系统最典型的例子就是电商平台，它们有以下几个特征：

事务 - BASE模式 github ACID的局限 在本地事务这篇文章里我们讲到了数据库事务必须保证ACID，在2PC这篇文章里，我们探讨了跨数据库事务是如何保证ACID的。 当数据量越来越大的时候，我们会对将大数据库拆分成若干小库，随着数据库数量越来越多，2PC（及XA）就显得有些捉襟见肘了： 性能低下，2PC协议是阻塞式的。当协调...

在上一篇文章中我们介绍了本地事务，随着软件复杂度的上升，我们会需要一种可以在多个数据库之间完成事务（分布式事务）的方法，而这个方法也必须能够保证ACID。于是就出现了2PC - Two phase commit protocol。事实上2PC不仅仅适用于多数据库事务场景下使用，也适用于所有支持2PC的参与方（Participants)。

事务 - 本地事务 github 什么是本地事务（Local Transaction）？本地事务也称为数据库事务或传统事务（相对于分布式事务而言）。它的执行模式就是常见的： transaction begin insert/delete/update insert/delete/update ... transaction commit/rollback 本地事务有这么几个特征: 一次事务只连接一个支持事务的数据库（...

数据还未缓存，大量并发请求 在数据还未缓存的情况下，大量并发请求过来的话，如果处理不好，很容易就打到DB。 解决思路（1）：预先缓存 如果可以事先知道需要缓存哪些数据，那么就预先将这些数据缓存起来。处理方式可以是： 程序启动时 人工在后台触发 解决思路（2）：排队 把映射到同一个缓存key的请求排队，挨个处理...