10个基于java的cms网站内容管理系统( 小型电商网站的商品详情页系统架构(小型)系统)

　　10个基于java的cms网站内容管理系统(

小型电商网站的商品详情页系统架构(小型)系统)

　　小电商网站商品详情页系统架构

　　小电商网站的页面展示采用全静态页面的思路。所有商品信息都存储在数据库中，将页面静态填充到静态模板中，形成静态页面并推送到Nginx服务器中。用户浏览网站页面时，取一个静态制作的html页面，直接返回，无需任何业务逻辑处理。

　　下面是页面模板的简单演示。

商品名称：#{productName}

商品价格：#{productPrice}

商品描述：#{productDesc}

　　这样做的好处是，用户每次浏览页面时，不需要与数据库进行任何交互逻辑，也不需要执行任何代码，直接返回一个html页面，速度和性能都非常高。

　　对于小网站，页面很少，很实用，很简单，可以在Java中使用velocity、freemarker、thymeleaf等，然后制作一个cms页面内容管理系统，当模板更改，点击按钮 或系统自动重新渲染全量。

　　缺点是只适用于一些小的网站，比如页面大小从几万到几万不等。对于一些大型的电商网站，几亿的页面，你说每次修改页面模板，都要让这么多页面静态化，靠谱吗？每次渲染都需要几天时间，而且你的整个 网站 都没用。

　　大型电商商品详情页系统架构网站

　　在大型电商网站的商品详情页的系统设计中，当商品数据发生变化时，变化消息会被推送到MQ消息队列中。当缓存服务从消息队列中消费这条消息时，感知到数据发生了变化，调用数据服务接口获取变化的数据，然后将整合后的数据推送到redis。Nginx本地缓存的数据有一定的时间限制，比如10分钟。当数据过期时，会从redis获取最新的缓存数据，并缓存到本地。

　　当用户浏览网页时，Nginx本地数据动态渲染到本地html模板返回给用户。

　　虽然没有直接返回一个html页面那么快，但是因为数据是在本地缓存的，所以也很快。其实代价就是动态渲染一个html页面的性能。如果html模板发生变化，不需要重新静态化所有页面，也不需要发送请求。没有网络请求开销，可以直接将数据渲染成最新的html页面模板然后响应。

　　在这种架构下，我们需要保证系统的高可用性。

　　如果系统访问量大，Nginx本地缓存过期，redis中的缓存也被LRU算法清理了，那么就会有大流量，从缓存服务中调用商品服务。但是，如果此时商品服务的接口出现故障，则调用延迟，缓存服务的所有线程都被调用的商品服务接口耗尽。当每个线程调用商品服务接口时，会卡住很长时间。时间长了，后续的大量请求就会卡在那里。此时缓存服务没有足够的线程调用其他一些服务的接口，导致整个大量的商品详情页无法正常显示。

　　这实际上是一种商品接口服务故障导致缓存服务资源耗尽的现象。

　　【感谢阅读，如果对你有帮助，请点个赞~】

　　更多经验和技术欢迎前来学习交流：

　　A Little Classroom——为梦想而奋斗的在线学习平台