本项目主要实现了一个具有一定高并发性能的秒杀商城。
该图描述了本系统的集群架构，从最复杂的操作———订单操作的减库存步骤的角度来进行描述。
由于本图只是示意，与实际情况有以下不符：
- 本系统由于经费限制，仅使用了四台2核8G内存的阿里云服务器。具体部署如下：
- redis,MySQL,nameserver,broker均部署在同一台数据库服务器(DataBase001)。
- 代理服务器和静态资源存储部署在同一台代理服务器(Nginx001)。
- 应用服务器有两台(bargainsdash001,bargainsdash002)，并未区分生产者和消费者的角色，均部署了具有完整功能的JAR包。
- 大多数服务并不涉及频繁的写操作，不存在Redis和MySQL的同步问题，因此不需采用RocketMQ的集群部署。
- 基本功能：用户登录，用户注册，创建商品，商品列表浏览，商品详情浏览，下单。
- 使用Redis作分布式会话管理。
- 使用Nginx完成了项目的动静资源分离，静态资源存储在代理服务器中，动态资源向下游获取。
- 使用Nginx完成了分布式集群部署，负载均衡。
- 对商品详情数据实现了多级缓存。具体为Redis缓存(数据层)/本地缓存(应用层)/Nginx的shared-dict内存缓存(代理层)
- 对减库存步骤使用了Redis缓存。采用RocketMQ作为消息队列，完成库存数据的异步更新。
- 为了保证减库存步骤的数据一致性，采用事务型消息，并根据数据库的交易流水表确保事务消息回滚的准确度。
- 在Redis中设置令牌上限，订单接口只处理拥有令牌的请求，限制了订单接口的并发数。
- 采用线程池作为流量削峰措施，限制了订单接口的同时并发数。
- 采用Guava包下的RaterLimit作为令牌桶的实现策略，限制了订单接口的每秒并发数。
- 前端列表页面并未做分页处理。
- 订单入库和销量增加作为性能要求最高的订单接口的一部分，直接操作数据库，对性能影响很大。
- 缺乏对用户的会话过期问题的处理。
- 商品详情默认采用本地缓存，实现方式为Guava包的Cache，优点缺点都是持久保存，对库存和销量变化很不敏感。