淘宝网的高并发处理与压力测试

其实到现在为止距离淘宝双十一事件已经过去蛮多天了，但在整个技术圈里面大家还是津津乐道。我这次在采访之前在和一些网友做沟通的时候，他们也提出了非常多非常有意思的问题，包括一些高并发的，一些压力测试的等等，那我希望也代表这些网友和你做一个交流。那第一个问题就是，在那么大的访问量，淘宝的技术团队是如何做到一个高并发处理的？

对于高并发处理，简单来说呢，就是如何通过集群方式去并发处理用户的请求，那说复杂它是一个比较完整的体系，那可能我就没有办法一一的把它说全了。我可以从前往后给大家说几个点：

比如说我们的CDN，你如何把静态的图片，还有静态的JS文件和一些HTML文件放在用户最近的一个节点上让他去最快的访问？那当用户要去访问淘宝主站，要去做交易的时候，我们如何去平均的分他用户的请求，把他放到后台的应用机群里面去均衡的做处理？在这个过程中还有一个问题，你用户的登录状态你怎么去记录，那这个关键点你还要去把它处理。每一次去处理你请求的服务器可能是不一样的，它不可能记录你每个人的状态，那这时候状态处理如何去处理？那在应用机群内部呢，应用机群和服务之间，他如何去调度的？因为服务本身它也是一个机群，那你用应用机群和后端的服务机群之间，你如何均衡的处理它的访问请求？

还有服务器，就是你核心服务和数据库之间，还有这种之间分布式缓存之间，或者说分布式存储之间，和分布式数据库之间，是如何去交互的，平均的分摊压力的？这个就是从前到后的，它其实都有很多点去对应的做处理的。那对于处理这种高频发还有一个很关键的点，如何做到水平扩容，也是因为这一个点，你每次做一个系统的时候，你都是可以去做到的，只有你可以做到水平扩容，你才能在你流量大增的情况下，通过增加机器去解决问题，你没有办法做到水平共容的话，可能你当时增加机器已经没有用了，这时候只有等死了。

一个比较具体的问题就是像高并发访问页面数据，如果说实时更新的话，它应该是如何去做到实时的同步？

对于淘宝这种电子商务系统，除了我们的图片和一些JS文件，其他基本上都是动态数据。而这种数据呢，可能大家不相信，它的存储的语言和访问的语言是一样的。所以说我们根本就不需要说去做两个数据之间的同步，就是存储数据和访问数据同步式是不需要去做的。

那刚才我们之前提到过就是我们做的读写分离。那读写分离的话，它就是两个元素不在一起的。其实当时我们也是做了实时，但是这个实时上面是要打一个问号的，比如说我们可以在十毫秒、二十个毫秒，就保证我们两个数据机群之间的数据就同步了，那这样子，就保证了前端，他看到的这个数据就很快是一致的，就是基本上没有存在任何差别。

至于说我们数据库层面的读写分离如何去做呢？我也可以简单介绍一下，第一个层面应用就是你有时候数据可以同时写两份，或者通过消息去做异步的一个复制，或者甚至去做数据库本身日志的一个分析，因为我们对文本分析的成本和代价是最小的，而且准确率是最高的，当这个数据库它把它的日志存储下来以后，我们对它其分析发现那些数据发生变更了，就同步到另外一个机群里面去，这些手段都是可以去用的，那具体用那一个手段，要看你当时的整个应用的场景。

那我们来谈一谈就是一些关于压力集成测试的问题，很多网友他想了解一下在淘宝双十一事件之前，淘宝的整个技术支撑团队，有没有对网站做一些比较大的压力集成测试？

没有，因为很难，淘宝是不算是一个耦合性很弱的一个系统，它很难去做到说对整个系统去做一次大型的压力测试，因为这个测试只能当你有现实的访问请求你才知道的。设想一下，你要把整个淘宝复制一份，然后又要去模拟那么多用户真实的访问请求，这是很难做到的。但是我们自己有一些经验，比如说我们可以把每个系统独立开来，对他进行做性能测试，然后我们可以对整个核心系统去做分析。做分析什么？找到短板，然后对它的短板进行压测，然后通过这一系列的压测的结果来分析你整个系统的支撑量是多少，这其实就是由那个短板决定的。那你那个短板是什么？你一定要去发现。而对这种单个系统，你如何去模拟线上的压力，也是一个很重要的研究课题，比如说很简单一个道理，你用户中心要做压测，你怎么把它真实的现状压测出来？那我们的性能测试团队，就是经过了半年摸索，建立了这样的一套大型的系统压测模型。

我们可以做到什么程度呢？我们现在可以把数据库的缺陷点压测出来，把JVM的缺陷给压测出来，只要在线上高峰期可能出现的一些波段导致一些后台系统之间的一些BUG，我们现在基本上都可以模拟出来。那这个模拟就比较复杂了，包括成本和包括人力投入还是蛮大的，因为你要模仿线上的压力，你必须有线上的那批机器，硬件条件要是一样的，你系统部署要是一样的。几乎要尽可能去模拟真实的场景，这是一个方式，就是我们通过大型的一个性能压缩的模拟。还有一个模式是什么呢？

我们在线上做了一件事情，就是在交易非高峰期引流量，就是把几台机器的流量引到一台机器上，对这台机器进行大规模的压测，就是用线上真实的一个应用场景对他进行压测，这个也是可以做得，但是你一定要清楚它的风险在那里。因为你这样做如果出现问题的话，会导致部分用户的访问受损。但是我们尽量通过这种方式可以模拟出来一个不要在这个上面去追求极限数字，比如说现有的能力上，我们是不是能支撑200%的能力，只要到200%我们就觉得OK，这个压力测试是可行的，那我们就可以把这些就是释放掉了，就把它恢复原状，这样也可以做得。

经过这个压力测试，包括对数据库，对JVM，包括对操作系统，可能都会它们的缺陷给找出来，那么你们会针对这些缺陷会调整它们的系统参数吗？

肯定会的。因为就是包括JVM、你的 LINUX的内核，还有你数据库的MySQL，还有一些，第二方厂商或者第三方厂商，他们提供的一些应用服务，或者硬件，或者软件，其实都有参数的。但是什么参数是最优的呢？是你需要去探索的，那这也要依赖于我们的大型的性能压测的模型，只有在这个压测模型下，你每调整一个参数，它所起的作用，它产生的风险，它带来的好处才能体现出来。当你通过这种压测，你会找到配置是最优的一个均衡点，这时候这些配置才会定下来，在线上去实际的运营，去实践，然后如果发现问题，我们再通过压测再去做，它是一个这样的一个过程。所以说我看到有网友问到说，我们在就是双十一那天有没有去调整系统参数？没有的。我们就是要追求12个参数就是最优的，所以说我们是之前做的工作来保证双十一，如果说当时还要去调系统参数的话，那我觉得当时我们之前的工作是不到位的，我们工作没有做到平时。

其实在双十一事件之前，你们也做了很多的预案，当然对访问量也做了一些预估，有些人就想了解一下，如何对访问量做预估，能够让它的准确性更高。因为你准确性更高的话，这样你才能准备更多的机器包括一些存储设备来应付这样的情况？

我想我们的网友是想要知道，在双十一那天，淘宝能不能准确的预估到当天的流量是多少，就是带来的增量是多少。这是很难去预估的，因为我们很难预估我们的会员，他的整个购物热情能高涨到什么程度，但是我们可以做的是什么呢？因为我们根据历史数据，都知道整个系统的压力情况和压力的配比情况，那我们可以预估说，比如说我们系统压力增长50%，我们需要预留多少台机器给这个系统，我们增长100%的时候，我们要预留多少台机器给这个系统，我们会根据这个压力的情况去做预估。但双十一那天我们只预估了很少的一个量，幸好我们有刚好到了一批机器可以临时的去用，否则的话，当天风险也挺高的，但是还是撑住了，还挺好。

那么大的访问量有运用到一些像虚拟化技术或者云计算技术这样的一些技术吗？

虚拟化技术，现在我们所有的服务器，全是运行在虚拟机上的，就是我们一台实体机会被分割成三到四台虚拟机，在这个上面去就是搭建在这些系统。但是你说具体用到云，从我这个层面，我感觉还没有真正到云那个程度，就是我可以随时的去划分一部分服务，就是那个机器为这个服务去提供扩容等等，这个还是做不到，我们为了单台的系统，还是要去加机器，当然是加虚拟机了，把它应用上去，然后让它整个系统领域去扩充。

我觉得云计算和云服务是淘宝将来的一个未来，一个技术方向。但是我们能做到哪一步呢？这个只能期待了，在我们自己的观点里面，我们渴望，但不强求，因为你任何一个应用场景，任何一家公司都有你客观存在的现实情况，你只能根据这个现实，和你的业务等等来决定你的技术方向。但是我觉得淘宝有希望，因为淘宝有这么大的用户群体，有这么高的访问量，双十一中已经体现出来了，真的是震惊业界。

那面对这么高的访问量，淘宝技术团队是怎么来监控各个关键点压力的？就是如果说某一个节点上出现压力或者故障，如何去比较平滑的去切换处理？

这可能要从几个方向来说：

第一淘宝有一个监控中心，他会对包括网络流量，包括系统的压力情况，还有包括访问量等等，做一个监控，我们会设置预警点。这个预警的机制是江枫构建的，后面你会采访江枫，他可以给你们介绍一下。这是一个大的方面。

但是我们要求每个系统的服务团队，你的支撑团队必须要有自己的监控和预警的机制，你不能依赖于整体的那一个。因为只有你对自己的这个系统最了解的，只有你自己才知道它里面的细节和你能支撑的量是多大。那这时候我们要求你要做到心中有数，你要自己能够去监控个系统的压力，或者系统的访问量等等。我们甚至允许他自己就这个团队自己，去建自己的一套监控体系来做这个系统服务架构。如果你做不到，你这个团队是不到位的，你做的工作是不到位的。那现在我们每一个系统，都有自己这样一套体系，可能方法上或灵活一点，或笨拙一点，但他们都知道自己这个系统支撑量可以到什么程度。然后我们要求他们，当你的系统发生风险的时候，你一定要反馈回来，告诉我们整个的“战地指挥所”。

如果不是双十一你要汇报给你的Leader，然后你的Leader应该要配合你这个系统去做技术改造，让他可以支持更大的量，所以说他不是一个点去做监控的，他是多个点去做监控的，而且我们是要求全员负责的，你负责这个系统你就不要丢下负责人。然后至于说根据压力做一些水平的可能访问的一些流量等等，这些是会做的。但是还是那句话，工作要在平时。就是在平时，你能够支撑更大的量，就不用去做拆分，因为那个时候你去做的这种服务，就是那个切分，风险是很高的。所以说我们还是希望在你平时你本身就可以支撑那么大的量，当然你也需要去做一些预警的措施，或者说预案，当你超过这个量的情况下，你服务如何去降级。

我听过一些传言说，如果说这个交易再持续那么几分钟，那整个的系统可能就会出现问题，有没有这么回事？

这个问题不太准确，因为从我来说时间不是问题，当我们支撑过去的时候，你三十分钟，三个小时和三天是没有任何区别的，他是在量上区别。当我们这个在高峰期的交易量再上涨10%到20%，那可能我们真的就倒掉了。

所以说这也是我们那天比较庆幸的地方，没有朝那个量上去。但也不庆幸，就是我们还是希望看到交易量越高越好，但是如果说真的再涨10%到20%，周边合作的一些公司的系统，包括银行，包括支付宝，包括旺旺，以及淘宝的一些系统，可能都会崩溃掉，这个很正常。这个也是双十一给我们带来的冲击之一，打破了我们很多以前已有的经验。在原来当天超过200%、300%这种系统压力也是有希望的情况下，我可能我在设想明年是不是一天超过百分之四百，那可能明年我们整个预案也要为百分之四百、五百去做努力而准备，所以说那个问题不太准确，几分钟是垮不了的，但是再上涨10%到20%的那个流量和压力，我们这里就垮掉了。

整个实践来讲还是比较平滑的。那我们想了解一下，作为整个淘宝研发团队的负责人之一，在未来淘宝在做一些技术改造的时候，它应该沿着一种什么样的方向去走，有没有什么样的一种思路？

对淘宝自己来说，我们就希望保证整个交易的核心系统是稳定的，是可水平扩容的。基于这个交易核心系统的基础上，我们有一些更多的额外的服务，因为业务是多样化的，我们必须去支持这种业务多样化。

为了支持这种业务多样化，我们会增加很多很多的一些额外的系统，它是附属于核心系统的。那么在必要的情况下，这些核心系统是可以做剥离的，如果简单来说就是我们是不是可插拔。但是SOA可插拔概念又不太一样，因为这种可插拔可能会只是提供服务，做展示而已，它会更灵活，更直接。那在某种程度下在我们支撑下的交易组合性也是可行的。

另外一个方向就是之前我也提到过，现在我们单打独斗的时代已经结束了，就是我们的技术人员在做方案的时候，我们必须要预估到本身他的业务会给技术带来什么样的一个压力，而技术对后端、对网络有什么要求，技术对后端的存储有什么要求，他是要综合考虑的，就是他需要看得更广的一个范围，否则也没有办法为我们这个整个系统去提供服务。

我举一个很简单的例子，UIC，我们称之为用户中心，如果说你只是做好UIC应用本身，现在已经不行了。因为他包括后台的存储，你说和DBI的合作，还有和网络的合作，那这大家可能都不可预估是吧。我们在之前，就是在一个月两个月之前，我们做了一次Review，发现UIC应用服务器和缓存服务器之间它的一个路由器到瓶颈了，所以说你连这种网络拓扑图你都要知道。所以我们还是强调说你在做方案的整体性，单打独斗说实在真的结束了，我们就是要靠整体去取胜，这可能也算是技术方案的方向之一。因为这个问题的确比较难回答，因为它的范围太广，太细了，而且针对不同的团队，比如搜索团队，比如说我们的DB的存储团队，比如说我们应用团队，比如网络运围团队，他都有自己的方向，还是一个整体，可能真的是要看整体去做，但他们里面每一个人的每个部分的细节是不一样的，所以这个问题蛮难回答。