昨晚参与了天猫的双11活动，自己也下单了，中间遇见了一些问题，相信大多参与该活动的人都碰到了，先看问题吧：
问题：
- 首页打不开
- 购物车数据丢失
- 无法添加到购物车
- 无法下单
- 无法付款
- 进入支付宝后，网银不给力，不响应请求
总结的看导致以上问题的原因只有一个：大流量的涌入。那对面这个大流量有什么好的办法呢？
其实对于对于这个问题，古人早就给出了宏观层面的答案，大流量就如洪灾，手段非堵即疏，大禹时期由于时代的客观局限性，之前采用的都是堵的方式(这里的堵并不是完全堵死的概念，因为那样肯定是会奔溃的，堵是堵住大部分流量，放小部分过去，通过时间慢慢卸掉洪水)，但是效果一般，后经大禹改成疏导的方式，效果却很是明显，后也有西门豹引漳十二渠灌溉工程，引河水灌农田，效果也是杠杠的！
那么对应到软件的架构设计上看，也无非这两招：堵和疏。
先看疏导：疏又可分为两种，一是扩宽现有河道的宽度，这个是内部改造，另一种是另辟支流，将流量导入到支流中去。
网购的下单业务模型是呈漏斗模型的，浏览 -- 进入购物车 -- 下单 -- 付款。 越往后流量就越小。浏览，购物车都是在主干道河流上的，我们无法将这些流量进行分流，因为这家店是你开的，总不能说：亲，请您去京东或是苏宁买。所以这几个环节唯一能干的就是努力拓宽自己的主干道，应对洪流的涌入。
1.源头的控制
既然是疏导那么就要从源头做起，洪流的形成是上游每个小溪汇聚到一个总河流上后形成巨大的杀伤力，那么第一步要做的就是将每个小溪流入的水量尽量的减少，对比的看就是降低访问页面的请求数据量，前段压缩需要返回的页面数据，降低渲染一个页面需要发起的请求数，一方面是降低服务器的请求响应，另一方面也是加快浏览器的加载数据(现在浏览器都有并发加载的个数限制，不同浏览器各个不同)
2.分流的开始
我们的主河道对外提供了一个唯一入口，但幸运的是我们可以在后台进行自由的分流措施，DNS的智能解析，将每个小溪的流量导入到最近的支流上，静态资源的CND缓存。使得部分请求的流量通过河道旁边的树枝吸收掉，不再往下流去，进一步降低流量。
既然已经通过了DNS解析，那么就对进入某个支流流量较大的分支进行特殊处理，努力拓宽河道(热点地区的特殊处理)。
当然这里说的都不是很细节的东西，通过这些已经基本能解决：浏览、添加购物车这两个环节的问题，从微薄的反馈上看，大家对于这两个环节的抱怨还是较少的，说明天猫对于这两块还是做了很多的处理。
3.堵流量
若是做了以上的措施还是撑不住怎么办？我们努力拓宽主干道的河道，开辟了很多分支，但是洪峰还是太猛，为了分支冲垮我们的河道和分支，只能采用的方式就是堵了，将同一时间能流入河道的流量控制在我们河道能承受的最大峰值之下，这个也是在有限的资源下采用的办法，当然通过开辟无限的分支河道能解决一切的大洪流，当然这个只存在于理想之中。
从天猫相关技术负责人的微博上看，天猫也基本采用了堵+疏的方式来处理，但是还是出现了很多问题，那么根源在哪里呢？
我们回头看看上面的几个环节，浏览--购物车--下单--付款。
浏览和购物车不是问题关键(虽然也存在数据一致性等问题)，因为做了上面的努力，关键在于下单环节，淘宝或是天猫业务流程中一个最关键点就是下单必须通过支付宝。不管你是通过网银支付还是支付宝支付都需要通过支付宝，你必须在支付宝建立一个订单，这才是导致前面做的所有疏导堵做的努力都浪费了，最后所有的支流又汇聚到这个点上，虽然在支付宝中你可以通过不同网银进行分流，而且也当心网银承受不住压力，一直推荐大家先存钱到支付宝等措施来应对各种问题，但是、但是，一个支付宝成为了整个架构的瓶颈。这种架构将原本是漏斗模型的流量生生畸形成了沙漏模型，两头宽，中间窄。
若是中间的下单环节不单一的通过支付宝，一个很简单的页面，提供各个第三方支付或是网银，来分担支付的压力，那么相信前面做的各种分流措施会继续分流下去，最终完成一个完整的业务。如此形成就是会是一个圆柱形的模型，而不再是沙漏模型。
4.真的跟12306一样吗？
很多人说12306也可以嘲笑某某电商的架构师门了，其实他们只是表象相同，本质上有大的区别，12306是在浏览和购物车这两个环节就已经挂了，他们的支付是圆柱形的，而不是沙漏型，根本无法跟天猫的双11相比，因为两者不是一个模式上的比较。