系统优化笔记 - 商品系统数据展示优化方案
背景
目前手上有一个微信优惠券抢购系统，由于在初期限于客户的工期、用户规模不够大、并发量小等情况下，除了抢购、销售数据利用了 Redis外，其他的均是直连数据库进行操作。
系统使用的技术：spring boot全家桶、mybatis，spring data jpa、Redis、MySQL等。spring data jpa只用于后台管理系统，主要是为了和mybatis进行对比，看哪个更利于当前系统的开发工作及维护。
1 商品详情展示
商品这块的设计，分为商品表、商品版本表。设计目的：
1）利用版本表达到商品信息快照目的，避免订单上存放购买时的商品相关信息；
2）因有版本概念，所以每次编辑后，会生成一个未发布版本，为未来的性能优化留下空间，这也是本次优化的一个地方。
优化方案：
利用版本发布功能，将MP前端展示的商品详情数据，缓存到Redis中，应对商品详情的频繁展示。
缓存过期时间，则设置为商品销售结束后，因商品一旦销售结束后，就不是非高频访问的商品数据了。
2 首页轮播商品信息展示
首页轮播商品展示最新推荐的5条商品信息，在上一个版本中，也是直接从数据库读取。该数据读取频繁。
优化方案：
1）使用缓存机制，将商品加载到Redis缓存中，提升数据加载速度。
2）缓存更新方案，更新方案：
a）Redis加锁，如果多个请求都检查到需要更新缓存，已优先加锁的更新请求为准，其余更新直接忽略，然后直接读取旧数据进行展示。
b）使用消息队列解耦，检查到需要更新，直接向消息队列中put一个更新消息。然后更新程序消费该消息，执行缓存更新操作。
c）使用job定时检查缓存是否到达更新时间，更新步骤和 a中一样。
如果用b方案，则需要增加消息服务实例，所以综合考虑技术、稳定性和时间成本，使用a方案。
3 商品列表查询
目前商品列表的查询，在上一个版本中，也是直接从数据库读取。但是商品列表是一个比较频繁的数据，也需要优化。
优化方案：
1）Redis缓存方案。
2）Elasticsearch方案
鉴于方案2涉及到的技术比方案1复杂，本次经过权衡时间及技术成本后，选用方案1。
大体方案仍然和 2中的a方案一样。只是列表缓存数据有过期时间，在多个更新请求的检查到锁的情况下，暂时考虑使用自旋锁保证请求能有数据，自旋频率暂定100ms一次。也可寻找成熟的框架方案来解决该问题。
4 前端展示优化
目前页面渲染使用的框架是thymeleaf，在进行上述改造后，将考虑使用前端框架优化页面渲染。减少页面响应白屏时间。