“2008 年 Dan Pritchett 提出一个与两阶段提交截然不同的分布式事务实践: BASE（Basically Available，Soft state，Eventually consistent）实践。BASE 实践突破了传统解决分布式事务的思维，放弃 ACID 个性以换取零碎的可用性，BASE 实践强调根本可用、软状态、最终统一，而不像 ACID 保持强一致性。BASE 实践是一种解决分布式事务的思维，没有具体的操作步骤，要了解 BASE 实践须要联合具体的例子。”
敲完这段话当前，我顿了下，齐全停下了打字。思考了很久，我决定把筹备了四五天的，各种为了讲清楚 BASE 实践的利用实例全副删掉。
因为我很想谈谈本身的一些经验。兴许，那些折腾和熬人的经验能更分明的通知大家，为什么会有 BASE 实践这套货色进去。
一、
前些年，互联网行业里对架构师这个岗位的规范还不是很清晰。所以，很多架构师的工作往往就是一些技术被公司认可的资深工程师负责。
彼时，刚巧我也是这类人员之一，故也失去了一个从零开始架设一套广告投放平台的机会。
我很喜爱钻研技术，对这种机会天然很看重。
那时候，架构并无现在这么简单，一开始就是后面搞几个 Web 利用，前面共享个数据库。
当然，下面的架构其实做了很多简化，省略了很多细节。比方，为了进步性能做的缓存，为了进步吞吐做的负载平衡通通没有在上图给出。因为这些和本章话题无关，临时咱们就疏忽这些货色，只看外围局部。
这套架构初期运行还是没什么问题的，再加上一些缓存机制，初期一些性能问题都通过调整缓存晋升缓存的碰撞率应酬了过来。
可是，随着广告投放量的增大，广告的访问量也在暴涨。这些暴涨的访问量引发了性能问题。过后，因为前端有负载平衡，应用层倒是没呈现什么问题……
问题出在前面的数据库上
二、
这套架构数据库用的是 MySQL，自身也只有一台主库在对外服务，另外一台备库采纳了 MySQL 本人的全同步机制做实时备份。
当广告访问量暴涨的时候，因为业务须要，很多数据须要在数据库中做实时插入，这就导致了大量的磁盘 IO 产生。这些大量的磁盘 IO 造成了数据库自身性能的急剧下降。
悲催的是，整套广告平台的所有性能又都是共享一个数据库的，所以随着数据库自身的性能降落，平台的所有性能都受到了影响。
因为问题次要在于大量广告流量的写入，所以，靠读写拆散的计划去缓解问题这条路就走不通了。
只好先降级硬件了。在通过了几轮硬件降级和数据库调优之后，单数据库再也无奈撑持一直上涨的流量了。没方法，要思考搞数据库切分了。
那时候，我集体是很恐怖数据库切分的。
起因不仅仅在于须要在应用层多写很多简单的逻辑，其根本原因是过后风行的 2PC（两阶段提交）计划，这个计划自身能保障在数据库切分的状况下，原来的事务仍然保留着本身的 ACID 性质。即:
Atomicity（原子性），不论事务里执行多少命令，对外它们都是一体的，要么都执行，要么都不执行。
Consistency（一致性），正因为事务里要么做要么都不做，所以数据库的状态变动只能由事务变更后，才会叫一致性状态。
Isolation（隔离性），事务里做的事儿事务里面谁也看不到，就跟个盒子把数据罩起来一样，到底两头怎么变动的，事务里面的察看不到。
Durability（持久性），事务确认胜利了，那这状态就永恒不变了。
但也正因为这 4 个个性，2PC 才让我悍然不顾。
顾虑 1：首先，数据库拆分了，那么依据事务的原子性，事务本身必须是一体的，那么事务波及到的不同的数据库就必须都拜访一遍，而这自身就意味着很高的通信老本。
再加上，为了放弃一致性，事务失败后，还必须复原各个数据库原来的状态，这就必须让曾经胜利执行过本地事务的数据库全副回滚。
而略微懂点数据库的人都晓得，这个老本有多大。
更可怕的是源码交易，自身事务的隔离性还可能加上锁。一旦一个热点数据区域被大量拜访，最差状况就可能呈现串行拜访。而这对此套平台，包含我本人都将是个喜剧。
顾虑 2：数据库的拆分会造成整个平台的可用性降落。
假如我当初有一台数据库，它的可用性是 99.9%。如果因为分库，数据库从一台变成两台，那么平台的可用性就会变成：
平台的可用性 = 99.9% * 99.9% = 99.8%
从 99.9% 变成了 99.8%，这意味着可用性降落了 0.1%，每个月的不可用工夫会减少 43 分钟之多。
一边是硬件降级曾经到顶，单机数据库也优化到了极限，再不做数据库拆分，平台可能随时瘫痪。一边是没有好的策略，可能拆分数据库后，每个月都有宕机的危险，同时性能也可能会呈现激烈的降落。
我被逼入了死角。
三、
这种苦楚的纠结折磨了我大略一周，直到我看到了 CAP 定理。当 CAP 定理说分布式系统在分区容错的时候，只能一致性和可用性二选一时，我快乐的蹦了起来。
原来，可用性和一致性是不能兼得的。
为何我会那么快乐？因为逼我入死角的可不仅是技术上的问题了，我还接受着来自于业务方和领导的压力。每天一下班，我就须要面对业务各方的埋怨，以及领导一轮又一轮的督促。
有了 CAP 定理的反对，我晓得我最终是要面临抉择的。既然在这个世界上做分布式架构的所有人都要面临抉择，那我又怎么可能独善其身呢？
在对单机数据库引发的各种问题做了一次彻底的各种归因当前，我下了信心：
肯定要搞定拆分数据库并给出良好计划。
只是，2PC 这个拦路虎，它成为了我的大敌。通过 CAP 定理，我十分必定，只有我选了 2PC 计划，可用性就肯定会呈现重大的问题，这个计划也必定不可能拿进去丢人现眼的。
我惟一的方向就是去就义一些一致性，往可用性方向走。可是，怎么走呢？
兴许是老天眷顾，兴许是大家都接受着和我一样夜不能寐的压力，很快，BASE 实践在国内传开了。
BASE 实践让我晓得了，这个世上能排到前几名的技术大公司也一样会出问题，也一样会对这些问题进行斗争。而且 BASE 实践的思维让我的思路一下子就关上了，苦思而不得的问题开始有了脉络。
我要开始着手制订技术计划了。