淘淘商城第83讲——商品详情页面静态化方案的分析

如果我们要将商品详情页面静态化，那么就得准备一套方案。首先我们来考虑一下输出文件的名称，即静态网页的名称，要知道每个商品的详情页面都是不一样的，因此我们最好把商品的ID加".html"作为静态网页的名称。

然后来考虑一下输出文件的路径，即生成的静态网页应该放到哪儿。输出文件的路径可以是工程外部的任意目录，例如，这里我将生成的静态网页放在了如下图所示的目录中。

接着我们再来思考一下如何访问生成的静态网页这个问题。在我们的这套解决方案中，taotao-item-web这个工程的作用就是用来生成静态页面的，访问我们也用不着它，它生成完静态页面，它的活就没有了。我们还有必要通过Tomcat服务器来访问静态资源吗？既然已经静态化了，那么我们就有多种解决方案来访问静态资源了，而且效率比Tomcat服务器要高的多，显然没有必要使用Tomcat服务器了。当然了，就使用Tomcat服务器来访问也是可以的，只不过Tomcat服务器访问静态资源的效率不高。

除了可以通过Tomcat服务器来访问静态资源之外，我们还可以通过Http服务器来访问，其实，Tomcat服务器也算是Http服务器中的一种。

注意，这儿我们使用的是Nginx服务器。

紧接着，我们就要考虑taotao-item-web这个工程的部署问题了，假如说一台服务器下的静态资源并发量超过50000了，这时候一台服务器也就不行了，此时我们可以把taotao-item-web这个工程部署到多台服务器上，在每台服务器上都生成静态页面，这样就可以了。

最后来思考下静态网页的生成时机，我想大概是有以下三种生成时机的。

第一种是当用户点击商品详情的时候生成静态页面。但是这种生成时机是有严重问题的，当并发量高时，第一个人点击商品详情，然后去生成静态页面，有可能就在静态页面生成的过程中另外一个人也来访问这个商品详情页面，这时程序应该是要判断有没有这个商品的静态页面的，如果发现有了，那么就去展示，但其实这时静态页面还没有生成完呢，这样就会造成页面不全的问题，也就是可能会存在数据丢失的情况。

第二种是在服务启动的时候，生成所有商品的静态页面。这种生成时机又会存在一个问题，就是在新增或者修改了一个商品时，因为此时静态页面中的数据是不会发生改变的，这就会两相矛盾。

第三种是在服务启动的时候，先生成一部分商品的静态页面，再在商品新增/修改的时候，使用MQ发送消息（消息的内容为商品id就行），Java工程（在这儿是taotao-item-web这个工程）接收到消息后，生成静态页面。

经过上面的这套方案分析，我们不难画出如下图所示的流程图，商品服务（taotao-manager）添加商品的时候发布Topic消息到消息队列中，Server1和Server2是两套Http服务器，这样做的好处是提高系统的高可用性，Server1或Server2从消息队列中去获取消息，知道添加了商品后，于是就生成这个商品的静态页面并存放到Http服务器上，当用户访问的时候通过Nginx反向代理服务器（后面会学习Nginx）去访问其中任意一台Http服务器，从中便可获取静态页面进行展示。