前面，我们基本上阐述到同城双活的方方面面，大部分讲的都是如何落地实践、如何应用对挑战和问题。好像少了点什么？ 无论是现在的二地三中心，还是架构更复杂，看起来更牛X，传说中的五地三中心，都绕不开一个理论，那就是CAP理论。1. CAP理论
CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼，满足其中二个，必然造成第三个些许损失。比如：同城双活中，DB单活，是损失分区容忍性，来满足一致性和高可用。DB跨IDC主从同步，容灾切换时，是损失一致性，来增满足可用和分区容错性。服务注册中心数据同步，是损失一致性，来满足高可用和分区容错性。DB分库分表，是损失一致性，来满足高可用和分区容错性。关联方故障，关闭部分功能，是损失高可用，来保障一致性。总之，架构管理的本质是管理架构复杂度，而架构复杂度是由对上述三者的保障组成。而三者不可兼得，就需要权衡三者关系。同城双活的架构本质是提升了高可用和分区容错性，损失了一定的一致性，打破了单活架构下的三者的平衡关系，需要在双活架构中重新平衡三者的关系。在大型分布式系统中，基本上是损失些许一致性，来满足高可用和分区容错性，然后一致性再通过一些手段进行补救，这里就延伸出另外一个理论，叫：BASE（下一章节介绍）。2. BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
接下来我们着重对BASE中的三要素进行详细讲解：
1. 基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。注意，这绝不等价于系统不可用，主要从二个方面有损失：
a. 响应时间上的损失：正常情况下，一个请求响应间是0.5秒，但由于出现异常，查询结果的响应时间增加到了1~2秒。
b. 功能上损失：比如， 故障期间会员注册不可用，会员登陆是可用的，保证95%的用户是可用的。 比如，故障期间，人脸登陆不可用，可降级到账密登陆。 基本可用可降级的策略，也是同城双活中一个很重要的策略。我们不一定要保障所有场景所有业务绝对可用，在故障时，损失一些不关键的功能，损失小部分用户，是可以接受的。 2. 软状态：也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
比如： A转账100元给B时，先冻结A的100元，当确认B已收到100元时，再进行扣减A冻结的100元。在这里，冻结状态 就是一个软状态。 3. 最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。
与之相反的，是强一致性，比如DB单库事务（ACID）。我们用得比较多的是通过对账机制来保证最终一致性，以及通过“不可丢MQ异步消息补偿“来保证最终一致性。以上面转账场景为例：强一致性情况就是：A减100元，B加100元，AB在同一个DB且使用DB强一致性事务，无须冻结。最终一致性情况就是：AB可以分库分表，分布在二个DB，当B确认收到100元时，发消息通知A解冻扣减，然后再通过日终对账，处理极端情况下的异常。最终一致性的理念就是一致性是可补偿的。当然，这些补偿措施，也会增加架构复杂度和研发成本。 3. 应用无状态
前面，我们讲到，一致性保障是有成本的。应用只有做到“无状态”，应用即无须进行一致性保障，可以无限横向扩展，这是双活一个很重要的原则。
如果应用有状态，即表示应用存在有状态数据，双活架构中，即需要考虑数据一致性，对一致性保障也将会付出比较大的成本。
常见有状态的例子：
1. Weblogic本地会话+F5会话维持：应该用分布式Redis会话替代，F5无状态请求分发2. UFEP文件处理单节点处理：改用分布式存储BFTS/Wefiles/UDMP对于应用有状态数据的情况，都需要进行必造，让它无状态化。
总之，应用无状态，本质是应用除了存储，整个调用链路上，不存在状态数据，包括负载均衡中间件（F5/Nginx）、应用中间件(Tomcat）、消息中间件（RocketMQ等）。
4. 二地三中心
二地三中心，即等于同城双活+异地数据容灾。我们的情况是：深圳+上海二地，三中心指：深圳观澜IDC、深圳福田IDC、上海外高桥IDC。即观澜IDC+福田IDC进行同城双活。上海外高桥IDC异地数据灾备：进行异地从库数据增量同步，进行容灾。
同城双活构建完成后，我们就是一个标准的二地三中心的架构。 5.总结Finally
双活本质是为了提升高可用、分区容错性，也就对一致性造成了些许损失。为了补救一致性的损失，又增加了一些一致性保障措施，确保最终一致，重新平衡了CAP三者关系。这些，都会增加了架构复杂度，而且都是有成本的。高可用从3个9（99.9%）到4个9（99.99%），再到5个9（99.999%），三个简单的数字背后，是巨大的成本和架构复杂度。但是，金融行业特性，监管要求，对高可用、一致性是很苛刻的，在一次次的故障救火中，相信大家深有体会，所以，它是必须的。 挑战在落实，能否真正做成一个稳定实用的多活架构，而不是一个摆设，是给研发团队的一个考验，也是给基础设施的一个考验。最后，重复调强一下：尽量保持架构简单，不要过度设计，这是给架构师的一个考验。
作者：李兴楠（LIXINGNAN945），网金研发团队架构师
本文系个人观点，描述不当或不正确，欢迎指正。
