最近要搞一次抢票活动,就像小米那样,考虑到目前的用户数据,预计到时候会有瞬时30w左右的并发。这对于一个常规的web项目是灾难性的。即可能被宕机。为了解决这种情况,于是对现有系统进行了改造。先说现有系统的结构。现有的系统比较简单,属于传统的web应用,架构如下:

原始系统架构

这种架构是最传统的,对于压力不大的情况下,没有任何问题。当压力逐级增大,通过水平扩展 web 服务 和 水平扩展db就达到目的了。

但是对于瞬时30w的并发,绝对来不及扩展,而且要求的服务器资源也很多,从成本来说也不能接受。那么,就要考虑改造了。

30w的瞬时并发,对于后面的压力,主要来源于:nginx,抢票api,db。nginx裸压,轻松上15w并发。所以,nginx只需要有3个就够了。

但是抢票API就要水平扩展很多台,成本不能接受。而db就得考虑分库操作,改动比较大,对于现有数据的迁移也是成本。为此,我们只要能解决抢票api 和DB的压力就ok了。所以,考虑用MQ解耦。具体架构如下:

原始系统架构

这样子就把压力转嫁到MQ上了。只要前面得抢票API能扛住压力,MQ肯定没有问题的(调研了各种MQ,最后决定用 RabbitMQ)。而DB的压力,也就取决于Consumer的数量了,换句话说,DB也就完全没有压力了。

下面就要开始解决网络的问题了。具体请参考第2篇