海量互联网系统访问量、存储规模等都远大于企业、金融、电信等行业的系统。其系统设计中有损的价值观主要体现在两个方面，1、放弃绝对的一致，重新分配一致性、可用性、可分布三者的权重。2、柔性可用，合理的降级服务体系。本篇就这两点与大家进行一个探讨。
一、放弃绝对的一致 先重温一下CAP原理。分布式系统中，一致性(Consistency) 、可用性(Availability) 、分区容忍性(Partition tolerance，可分布)这三个要素最多只能同实满足其中两点，不可能三者兼顾。详细大家可以到网上查询“CAP原理”，有很多文章可以参考。
金融行业最强调的是一致性，同时为了容灾，分布也有很高的要求。处理不过来的时候用户排一下队也是可以接受的。海量互联网服务其实对一致性要求不高，所以可以降低一致性的要求来提升可用性与可分布能力。但有些初涉海量互联网系统的同事可能会一时转不过弯来。可用性不能通过增加带宽和设备来实现吗。如果数据一致性没有保证，怎么能保证业务逻辑的准确呢。
互联网服务AUP值是电信或金融行业的几十或上百分之一。这决定了不能像他们一样主要通过设备和带宽的投入来达到性能的要求。
这里说的损失一些数据一致性不是指数据完全混乱。首先，总是会产生不一致，但不断被消除，最终在一定范围会达到一致。例如一个数据分布在不同城市IDC的论坛，发布在IDC1的帖子马上会被IDC1所有的用户看到，后台再不断同步到IDC2。因为维护或故障导致的两边数据的差异，也可以由后台不断互相同步。其次，不一致的数据占整体比例总是很小。以上论坛的例子，两边存在同步的时间差，但是这个时间相对于用户可感知的时间来说很小。绝大部分用户感觉不到。
类似的原理在非跨IDC的应用中也适用。某些时候硬件故障时可能导致正在处理的数据不一致。但可以在故障恢复后做一定的修复或者让用户自己重做。
进阶一点的处理方法，可以通过精心设计的业务逻辑，减少对事务的依赖或者减小事务的规模。一个很好的例子就是网上竞拍，假定某些情况下比如非常有诱惑的初始价格并且有非常大的推广活动，导致短时间内大量用户并发出价。简单设计是每一次出价都是一个事务，需要先判断当前价格是否比以前高，然后增加一条出价记录，否则提示用户出价失败。这种情况下一件商品一人出价的同时，其他用户的出价只能排队等候处理，对系统产生了很大压力。如果业务逻辑改成在拍卖期间，任何人都可以出价，拍卖截止后，把所有出价记录进行排序，截止时间前的最高出价即是拍卖结果。大大提高了系统的并发处理能力。
二、柔性可用，降级服务 在系统成长到设备和带宽都有相当规模后，这时设备和带宽的故障大多是局部的。但如果系统没有针对局部的故障进行合理设计，往往会出现系统过载拒绝所有用户访问的情况。即使有很好的过载保护措施，使系统不至于瘫痪，但这终究是被动处理方式，对用户来说还是过于生硬。好一点的做法是将业务体验划分成多个级别（适应不同带宽和处理能力的情况），在负载和环境发升变动时，通过开关设置，选择适合当前带宽和处理能力的级别。
实现合理的柔性，首先要找出系统最容易变动的环节，有些是系统容量问题，比如手机农场在高峰期和低谷访问量差别很大，短期无法上架足够的设备。有些是带宽不稳定或有限，比如相册服务。第二步，结合用户使用场景，根据资源消耗，设计几个级别下的用户体验。比如相册高峰期的时候，默认图片改成小图，第一屏展示的数量也适当减少。这一步要求对用户需求的理解特别透彻，知道在各种情况下，用户一定要的是什么，可以放弃的是什么。第三步，根据以上设计，实现不同的开关。运营时手动或自动进行设置。
除了整体系统的柔性，单个用户也可以柔性。相比以前，有相当数量的用户会经常使用不同的网络接入方式。比如上班的时候，使用的可能是高速的办公网络，在家使用2M的adsl，在机场或者其他一些移动中的场合，会使用速度更慢的GPRS或WCDMA。如果系统只能提供高速网络下很好的体验，在慢速网络场合，用户就会慢得无法接受。在很好的测速系统支持下，可以让用户非常便捷的选择不同级别的服务，放弃很炫但耗带宽的业务，保证用户能快速得到当前最需要的服务。
海量互联网服务技术发展还很快，除了本篇柔性可用和弱化一致性，还可能有更多有损的实践。对于架构师来说，重要的是敢于打破老的观念，加强从用户视角看问题的能力，不断追求更适合海量互联网服务的架构。欢迎同事们一起讨论补充。 |
