(高并发问题.docVIP

高并发、海量数量服务的设计原则及策略总结 2010年6月6日| 分类: 架构之路| 标签: 互联网服务的特点就是面向海量级的用户，面向海量级的用户如何提供稳定的服务呢？基于互联网的特征，特总结以出原则和策略。 一、原则 1．Web服务的CAP原理 CAP指的是三个要素：一致性(Consistency)、可用性(Availability)、分区容忍性(Partition tolerance)。CAP原理指的是这三个要素最多只能同时实现两点，不可能三者兼顾，对于海量级服务，一般这是一条常记心中的基准准则。  关于CAP的定义： 一致性：可以参考数据库的一致性。每次信息的读取都需要反映最新更新后的数据。 可用性：高可用性意味着每一次请求都可以成功完成并受到响应数据 分区宽容度：这个是容错机制的要求。一个服务需要在局部出错的情况下，没有出错的那部分被复制的数据分区仍然可以支持部分服务的操作，可以简单的理解为可以很容易的在线增减机器以达到更高的扩展性，即所谓的横向扩展能力。 面向海量级的分布式服务设计，基本上分区容忍性(Partition tolerance)是第一要素，因此根据业务的情况，我们需要在一致性(Consistency)和可用性(Availability)之间做取舍。对于一些业务，譬如支付宝或财付通，一致性会是第一考虑要素，即使是延迟的不一致也是不可接受的，这种时候只能牺牲可用性以保证一致性。对于一些应用，譬如淘宝或拍拍交易中的评价信息，一般用户是可以接受延迟的一致性，这种时候可以优先考虑可用性，而用最终一致性来保证数据一致，譬如通过某种对帐机制。对于一些应用，甚至一致性都并非要求，只需要保证差不多一致性即可，譬如Q-zone中的农场游戏中的偷菜。 根据我们应用的业务需求，选择合适的一致性级别，以更好地保证系统的分区容忍性和可用性。 2．柔性可用 面向海量级的分布式服务设计，我们要意识到，一切都是不可靠的，在不可靠的环境的环境中构建可靠的应用，其中最重要的一点就是保持系统的柔性。 1）不可靠的环境 我们可能已经见惯一个远程服务提供不了服务了，运行一段时间后WebServer突然不响应了，数据库随着负载的不断增加再放上一条SQL语句就会垮掉。但是，硬盘坏掉、电源断掉、光纤中断，听起来似乎多么不可思议，然而，当一个海量服务需要成千上万台服务器、需要部署全国各地的数十个数据中心、需要横跨电信网通教育网三大网络的时候，一切听起来不可思议的事情会变成常态。一切都是不可靠的，唯一可靠的就是不可靠本身。 2）划分服务级别 我们应该意识到，在这种不可靠的环境中提供完美的服务，本身就是一个神话，即使不是说完全不可能，但至少是代价高昂的，因此，当某些问题发生（环境变地不可靠的时候），我们必须做出取舍，选择为用户提供用户最关心的服务，这种服务虽然听起来是有损的（至少是不完美的），但却能在一定程度上满足用户大部分的需求。譬如，当网络带宽无法为用户提供最好的体验而扩容又不是短期可以达到的时候，选择降低一些非重要服务的体验是一个比较好的选择。 在面向海量互联网的设计当中，对服务进行分级，当系统变地不可靠的时候，优先提供重要优先级的服务。 3）尽快响应 互联网用户的耐心是非常有限的，如果一个页面需要3秒以上才能看到，也许大部分用户的第一选择就是关掉浏览器。在构建柔性可用的互联网服务的时候，响应时间大部分情况下都是需要最优先考虑。还是一句话，环境是不可靠的，当我们无法尽快从远程服务获得数据、当数据库已经慢如蜗牛，也许当后台还在吭哧吭哧干活的时候，用户老早已经关闭了页面，处理返回的数据也只是在浪费表情，面向互联网用户，响应就是生命。 二、策略 如何让我们的应用提供更高质量的服务呢，这里是一些在日常开发使用到或者观察到的一些策略的总结： 1．数据sharding 海量服务相应也意味着海量的用户和海量的用户数据，大家都知道，即使是再强大的数据库、再强大服务器，在单表上亿规模的数据足够让一条简单的SQL语句慢如蜗牛（甚至于在百万、千万级别上，如果没有采取合适的策略，都无法满足服务要求），一般处理这种千万上亿级数据的大家基本上都会想到的就是数据 sharding，将数据切割成多个数据集，分散到多个数据库的多个表中（譬如将用户数据按用户ID切割成4个数据库每个数据库100个表共400个表），由于每个表数据足够小可以让我们的SQL语句快速地执行。而至于如何切割，实际上跟具体的业务策略有关系。 当然，我们要认识到，这种数