腾讯经历了十几年的互联网服务运营的经验，见证了互联网从窄带到宽带，用户规模从几千万到几亿，从定制的Web1.0到以UGC为主的Web2.0高速发展期。腾讯拥有海量的服务量级，在实战过程中积累了很多成功的经验和失败的教训，由此沉淀出了腾讯的海量服务价值观。
1. 为什么要去做有损服务？为什么要去做有损服务呢？是因为我们现在面对的是海量用户，架构师需要在用户体验和服务成本之间去做平衡。用户体验包括可用性、速度，还有一致性。服务成本，包括投入的带宽、设备，还有人力。
平衡用户体验和服务成本的原则是 CAP 理论。CAP 理论告诉我们：一个分布式系统，是不可能同时满足一致性、可用性、分区容错性这三个要素的。
三个要素里面最多只能同时满足两点，而不能兼顾。在云时代，可分布性和分区容错性已经成为了基本配置。因此作为架构师，更多要在一致性和可用性之间做取舍和平衡。
其实 CAP 理论早在20多年前就已经被学者证明了它的正确性。我们在此之上延伸出来另外两个概念。
第一是ACID，指在关系型数据库管理系统里，事物所具备的4个特性：原始性、一致性、隔离性、持久性。在数据库系统里指的就是一系列数据库操作组成的完整逻辑过程。
ACID比较典型的业务是应用于金融业，比如银行转账。用户从原账户里面扣除金额转到目标账户。增加金额过程，应当从整体考量，库存的完整逻辑过程是不可拆分的，一旦出现问题，必须回滚，这个过程就具备ACID的特性。
另外一个是 BASE 理论，BASE 理论来自于互联网，在互联网的电商领域最早被提出来，它最核心的特性就是最终一致。它的核心思想可以这样理解：即便不能达到强一致，也可以根据应用的特点，利用实践方式实现基本可用，然后提供一个柔性状态，最终达到最终一致。
在金融业、电子商务，海量UGC三种不同的业务类型当中，CAP三要素是如何取舍的呢？
首先对于金融业，很明显需要保证数据的强一致性，所以全部都要是ACID，因此需要投入巨大的IT成本。
电子商务是少量的ACID事务处理，加上大量BASE的最终一致性。比如用户在电商网站搜索商品、浏览商品，还有评论商品，其实是可以容忍数据在一定的时间窗口范围内不一致，而这类行为的并发量恰恰又非常大。高可用性是优先考虑的因素，这个时候BASE是非常合适的。
海量UGC其实基本放弃了联机交易的事务，追求的是高性能和高可用，以及用户体验。
我们用一个案例来进一步理解 CAP 理论以及最终一致性。这是一个比较典型的分布式系统的原型，是我当年做网站开发的时候，做的一个投票系统产品。它需要支持这样的需求：要求腾讯的用户能就相关的议题自由投票支持不同的观点，并将这种投票情况实时准确地反馈给用户。
开始的时候，我们根据这个要求，设计了一个相对无损的产品原型，如下图左边所示，通过跨越南北IDC分布的系统，实现投票系统，两地中间是通过一个专线连接的，实时交换投票的数据，保证数据的一致性，让用户得到一个一致的展示结果。
这个系统的并发是比较差的，性能也不高，因为它整个过程是串行的，还有跨地域的事务处理，响应会比较慢，用户体验也比较差。而且它的成本也比较高，系统依赖专线做大量的数据互相同步，需要消耗很多资源，有时候专线发生抖动或者故障，就会影响用户体验。
有没有更好的方案呢？我们尝试用 CAP 理论包括最终一致性的思路来看待整个产品，就可以获得一个新的视角。在这样一个并发量非常大的的投票系统里面，用户对投票数据的最终一致性窗口的敏感时间其实是比较长的。因为在这种高频发的投票活动中，数据无时无刻都在变化，所以我们只需要做小小的调整，就可以做出一个更好的实现。
