双十一还没到，为何淘宝就崩了？

双十一还没到，为何淘宝就崩了？那是因为我们中国的人民群众已经经历过很多个双十一了，我们都知道在双十一的那一天就会有很多人在那一天当中的半个小时里面购物，在那半个小时里面是一年当中优惠力度最大的时候，但是呢，那时候付款是很难才能够付款成功的，因为在中国有成千上万的人在那半个小时里面争先恐后的去付款。

之所以双十一还没到淘宝就崩了，就是因为有很多人为了避免在双十一那天争先恐后的下单，所以他们就提前下单了，导致了淘宝崩了，众所周知，在双十一的那一天当中的半个小时下单购买东西的时候是很难才能付得了款的，因为那时候有很多人都在付款，所以导致服务器很缓慢，我姐那时候付款文化，那么快递也会很慢的，因为面临双十一，就有很多人购买东西，所以快递也是很慢，很多人都决定在双十一之前购买东西，能够让快递更快的送过来。

因为双十一的那一天基本上是淘宝的巅峰时期，一年比一年的数据量增多，我们看过数据就知道每一年的双十一都是突破前一年的交易量，所以说在那一天淘宝是很卡的，就是因为有很多人在里面购买东西，所以说为了避免这种情况的发生，有很多人就在双十一之前购买东西，这样的情况一多起来，那么淘宝就崩了。

总的来说，都是正常的事情，因为在双十一那天，真的很多人在购买东西，为了避免快递太过于缓慢，付款付不上的情况，很多人就在双十一之前购买东西了，这样的话就造就了双十一还没到，然后淘宝就直接崩了的情况。

一应用无状态(淘宝session框架)

俗话说，一个系统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢咱们试想一下，假如我们在session中保存了大量与客户端的状态信息的话，那么当保存状态信息的server宕机的时候，我们怎么办通常来说，我们都是通过集群来解决这个问题，而通常所说的集群，不仅有负载均衡，更重要的是要有失效恢复failover,比如tomcat采用的集群节点广播复制，jboss采
用的配对复制等session状态复制策略，但是集群中的状态恢复也有其缺点，那就是严重影响了系统的伸缩性，系统不能通过增加更多的机器来达到良好的水平伸缩，因为集群节点间session的通信会随着节点的增多而开销增大，因此要想做到应用本身的伸缩性，我们需要保证应用的无状态性，这样集群中的各个节点来说都是相同的，从而是的系统更好的水平伸缩。

OK，上面说了无状态的重要性，那么具体如何实现无状态呢此时一个session框架就会发挥作用了。幸运的是淘宝已经具有了此类框架。淘宝的session框架采用的是client cookie实现，主要将状态保存到了cookie里 面，这样就使得应用节点本身不需要保存任何状态信息，这样在系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的但是采用客户端cookie的
方式来保存状态也会遇到限制，比如每个cookie一般不能超过4K的大小，同时很多浏览器都限制一个站点最多保存20个cookie淘宝cookie框 架采用的是“多值cookie”， 就是一个组合键对应多个cookie的 值，这样不仅可以防止cookie数 量超过20， 同时还节省了cookie存储有效信息的空间，因为默认每个cookie都会有大约50个字节的元信息来描述cookie。

除了淘宝目前的session框架的实现方式以外，其实集中式session管理来完成，说具体点就是多个无状态的应用节点连接一个session 服务器，session服 务器将session保 存到缓存中，session服务器后端再配有底层持久性数据源，比如数据库，文件系统等等。

二有效使用缓存(Tair)

做互联网应用的兄弟应该都清楚，缓存对于一个互联网应用是多么的重要，从浏览器缓存，反向代理缓存，页面缓存，局部页面缓存，对象缓存等等都是缓存应用的场景。

一般来说缓存根据与应用程序的远近程度不同可以分为：local cache 和 remote cache。 一般系统中要么采用local cache，要么采用remote cache,两者混合使用的话对于local cache和remote cache的数据一致性处理会变大比较麻烦

在大部分情况下,我们所说到的缓存都是读缓存,缓存还有另外一个类型:写缓存 对于一些读写比不高，同时对数据安全性需求不高的数据，我们可以将其缓存起来从而减少对底层数据库的访问,比如 统计商品的访问次数,统计API的 调用量等等,可 以采用先写内存缓存然后延迟持久化到数据库，这样可以大大减少对数据库的写压力。

OK，我以店铺线的系统为例，在用户浏览店铺的时候，比如店铺介绍，店铺交流区页面，店铺服务条款页面，店铺试衣间页面，以及店铺内搜索界面这些界面更新不是非常频繁，因此适合放到缓存中，这样可以大大减低DB的负载。另外宝贝详情页面相对也更新比较少，因此也适合放到缓存中来减低DB负载。

三应用拆分(HSF)

首先，在说明应用拆分之前，我们先来回顾一下一个系统从小变大的过程中遇到的一些问题，通过这些问题我们会发现拆分对于构建一个大型系统是如何的重要。

系统刚上线初期，用户数并不多，所有的逻辑也许都是放在一个系统中的，所有逻辑跑到一个进程或者一个应用当中，这个时候因为比较用户少，系统访问量低，因此将全部的逻辑都放在一个应用未尝不可。但是，兄弟们都清楚，好景不长，随着系统用户的不断增加，系统的访问压力越来越多，同时随着系统发展，为了满足用户的需求，原有的系统需要增加新的功能进来，系统变得越来越复杂的时候，我们会发现系统变得越来越难维护，难扩展，同时系统伸缩性和可用性也会受到影响。那么这个时候我们如何解决这些问题呢明智的办法就是拆分(这也算是一种解耦)，我们需要将原来的系统根据一定的标准，比如业务相关性等分为不同的子系统，不同的系统负责不同的功能，这样切分以后，我们可以对单独的子系统进行扩展和维护，从而提高系统的扩展性和可维护性，同时我们系统的水平伸缩性scale
out大大的提升了，因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统，而不会像拆分以前，每次系统压力变大的时候，我们都需要对整个大系统进行伸缩，而这样的成本是比较大的，另外经过切分，子系统与子系统之间的耦合减低了，当某个子系统暂时不可用的时候，整体系统还是可用的，从而整体系统的可用性也大大增强了。

因此一个大型的互联网应用，肯定是要经过拆分，因为只有拆分了，系统的扩展性，维护性,伸缩性，可用性才会变的更好。但是拆分也给系统带来了问题，就是子系统之间如何通信的问题，而具体的通信方式有哪些呢一般有同步通信和异步通信，这里我们首先来说下同步通信，下面的主题“消息系统”会说到异步通信。既然需要通信，这个时候一个高性能的远程调用框架就显得非常总要啦，因此咱们淘宝也有了自己的HSF框架。

上面所说的都是拆分的好处，但是拆分以后必然的也会带来新的问题，除了刚才说的子系统通信问题外，最值得关注的问题就是系统之间的依赖关系，因为系统多了，系统的依赖关系就会变得复杂，此时就需要更好的去关注拆分标准，比如能否将一些有依赖的系统进行垂直化，使得这些系统的功能尽量的垂直，这也是目前淘宝正在做的系统垂直化，同时一定要注意系统之间的循环依赖，如果出现循环依赖一定要小心，因为这可能导致系统连锁启动失败。