缓存菜品

问题说明

用户端小程序展示的菜品数据都是通过查询数据库获得，如果用户端访问量比较大，数据库访问压力随之增大。 结果：系统响应慢、用户体验差

实现思路

通过Redis来缓存菜品数据，减少数据库查询操作。 缓存逻辑分析：

每个分类下的菜品保存一份缓存数据
数据库中菜品数据有变更时清理缓存数据

为了保证数据库和Redis中的数据保持一致，修改管理端接口 DishController 的相关方法，加入清理缓存逻辑。需要改造的方法：

新增菜品
修改菜品
批量删除菜品
起售、停售菜品

代码开发

功能测试

可以通过如下方式进行测试：

查看控制台sql
前后端联调
查看Redis中的缓存数据

以加入缓存、菜品修改两个功能测试为例，通过前后端联调方式，查看控制台sql的打印和Redis中的缓存数据变化。当在后台修改菜品数据时，为了保证Redis缓存中的数据和数据库中的数据时刻保持一致，当修改后，需要清空对应的缓存数据。用户再次访问时，还是先从数据库中查询，同时再把查询的结果存储到Redis中，这样，就能保证缓存和数据库的数据保持一致。

用户再次访问同一个菜品分类时，需要先查询数据库，再把结果同步到Redis中，保证了两者数据一致性。其它功能测试步骤基本一致，自已测试即可。

缓存套餐

和上同理

添加购物车

需求分析和设计

产品原型

用户可以将菜品或者套餐添加到购物车。对于菜品来说，如果设置了口味信息，则需要选择规格后才能加入购物车;对于套餐来说，可以直接点击将当前套餐加入购物车。在购物车中可以修改菜品和套餐的数量，也可以清空购物车。

表设计

用户的购物车数据，也是需要保存在数据库中的，购物车对应的数据表为shopping_cart表，具体表结构如下：

字段名	数据类型	说明	备注
id	bigint	主键	自增
name	varchar(32)	商品名称	冗余字段
image	varchar(255)	商品图片路径	冗余字段
user_id	bigint	用户id	逻辑外键
dish_id	bigint	菜品id	逻辑外键
setmeal_id	bigint	套餐id	逻辑外键
dish_flavor	varchar(50)	菜品口味
number	int	商品数量
amount	decimal(10,2)	商品单价	冗余字段
create_time	datetime	创建时间