P2项目答辩总结

1、登录

1.1 登录的时候做vip的判断；

1.2 使用JWT(Java Web token),验证登录，更加安全

2、连续签到

2.1判断是否断签：

通过判断昨天是否登录，可以判断；

2.2判断连续签到多少天：

将每次签到的记录保存在redis中，判断保存的数量，有多少个，就连续签到多少天；

2.3 签到流水：

签到流水如果可以，直接保存在数据库；(考虑使用redis的bitMaps);

《Redis实战》之使用BitMap实现用户签到功能：https://blog.csdn.net/qq_31905135/article/details/124032880

Redis中是利用String类型数据结构实现BitMap，因此最大上限是512M，转换为bit则是2^32个bit位。
bitmap的操作命令有：
setbit：向指定位置offset存入一个0或1
getbit：获取指定位置offset的bit值
bitcount：统计BitMap中值为1的bit位的数量
bitfield: 操作（查询，修改，自增）BitMap中bit数组中的指定位置offset的值
bitfield_ro: 获取BitMap中bit数组，并以十进制形式返回
bittop:  将多个BitMap的结果做位运算（与，或，异或）
bitpos:  查找bit数组中指定范围内第一个0或者1出现的位置

2.4 签到初始化(自我考虑)

每天0点的时候每个用户初始化一条没有登录的信息(例如：status=0)，如果用户登录了就对用户的状态进行修改(status=1);

3、VIP

3.1 vip续约

redis中存用户vip的唯一标识key，设置ttl,并设置用户vip字段为vip；续约直接增加key值得时间；

3.2 判断用户是不是VIP会员状态

一些需要使用到vip的权限的时候，先对vip进行检查，如果vip失效，需要将用户的vip字段设置为普通会员；(主要两个地方判断：1.用户登录；2.用户使用vip权限)；这样可以大大节省时时判断用户vip状态的消耗；

4、关键词匹配

考虑，模糊匹配，近义词，(俗名)，ES分词,IK分词(ElasticSearch+Kibana)

5、热词

5.1 热词库

需要添加热词库，只有在热词库中的词语，命中才算热词；热词的管理权在商家手里；

5.2 添加热词(候选热词库)

通过商品的销量添加对应的热词；
对正常搜索到的词语进行搜索次数的记录，作为候选热词库；如果后期需要添加，可以从候选热词库中挑选；
可以使用老师的关键字的方式进行模仿实现命中；

6 、轮播图

6.1 轮播图的数量

可以根据不同时段进行不同数量的展示，人越多，数量越多；

6.2 多商户下，轮播图的挑选

添加到轮播图需要一定的费用；
可以根据商品的销量和热卖品挑选轮播图；

6.3 轮播图排序

返回的前端的轮播图需要排序好；

6.4 轮播图每个人不一样

每个人的轮播图不一样；

6.5轮播图设计

1.1 ：关于背景色：也可以不用，主要看你的轮播图占多大空间，如果是下图那样占全部空间，因为图片不可能将其全部占据，如果不用背景色，那么，轮播图片的两旁就是白色，会很难看。所以看自己
1.2 商品id：有时候，需要客户点击轮播图，直接跳转到 商品详情页面，所以 商品id 是线索
1.3 商品分类id：有时，点击后，会跳转到某一分类下，不是具体的商品详情页面
1.4 轮播图类型（type）：用于判断，可以根据商品id或者分类进行页面跳转，1：商品 2：分类

6、首页展示

每个人展示的商品不一样，可以从用户收藏，用户购买，添加购物车，用户浏览记录，等等推荐；
用户的行为数据(用户收藏，用户购买，添加购物车，用户浏览记录，等等)不能物理删除，因为这个数据是经过用户的自主赛选后得到的数据，十分宝贵；

7、优惠劵

优惠劵池(优惠劵有不同的分类可以领取)；
优惠劵的领取情况；
智能优惠劵挑选，在使用的时候，给用户展示优惠劵，需要将金额大的放在第一个，用户可以自行挑选；
用户优惠劵挑选过一次，在下订单的时候还需要再次判断优惠劵是否使用过，是否过期(除非可以确定该优惠劵一定可以用)；

8、商品下单及自动签收

商品发货
需要考虑商品的自动签收，用户不主动签收，需要自动签收；考虑使用延时队列，(或者定时+普通消息队列，注意定时对性能消耗比较大)；

9、分享有礼

隐藏分享用户的信息(因为需要对分析的用户进行奖励，但是又不能随便暴露用户的信息)
1. 可以将用户信息MD5加密后在加盐,(内部有永固加盐库，自己人可以知道)
2. 需要动态生成用户相关信息，主要目的就是保护用户信息安全；

10、某个商品比较冷清没有多少评论

将同一个商铺下，类似产品的评论移过来；(个人感觉不是太好)；

11、多负载的时候，防止定时任务重复执行

XXL-Job
分布式的redis加锁，执行完释放;
通过ip指定配置,指定执行定时任务的服务器；

12、做项目中遇到的问题

12.1 日期格式问题

//1.返回给前端的日期格式
//实体参数上添加日期格式化注解
@JsonFormat(pattern="yyyy-MM-dd HH:mm:ss",timezone="GMT+8")
//2.前端传给后端的日期格式
//实体参数上添加日期格式化注解
@DateTimeFormat(pattern="yyyy-MM-dd HH:mm:ss")

12.2 feign远程调用传输时间相差(快了)14个小时

1.先说结论：在feign接口调用时使用表单形式（@RequestParam）传date类型会发生时间精度错乱，在8时区会多14个小时。

2.使用json格式(@RequestBody)传date类型不会发生这种情况。
表单形式我的解决办法是：在对外暴露的feign接口中使用字符串类型。

3.（String date）来接收日期，在真正feign调用的controller服务中使用@DateTimeFormat（pattern=“yyyy-MM-dd”）Date date来转换字符串类型的日期。

4.将接收到的时间减去14小时(强烈不建议，比较麻烦且冗余，多次远程调用可能会再相差时间)。

5.扩展ZonedDateTime

java8 日期 时间 时区:https://blog.csdn.net/z69183787/article/details/87176339
ZonedDateTime时区日期时间类的运用:https://blog.csdn.net/qx020814/article/details/125580729
LocalDateTime、OffsetDateTime、ZonedDateTime互转:https://blog.csdn.net/f641385712/article/details/112732546

12.3 swagger返回参数不显示实体属性注解

需要添加@ApiModel(value = "xxx")注解，@ApiModelProperty(value = "xxx")注解,由于我之前没有怎么使用这个注解，导致忘记了，特此记录一下；

12.4 一个消息队列出列多个业务

12.4.1 发消息

将要处理的消息内容转换成JOSN字符对象，再放入到map集合中，监听到消息后，根据不同的消息内容进行不同的处理；

点击查看代码

//将订单信息封装成map集合，方便发送
Map<String, Object> orderMsgMapToQueue = new HashMap<>();
//父订单
orderMsgMapToQueue.put("ordersForm", JSON.toJSONString(ordersForm));
//子订单
orderMsgMapToQueue.put("orderItemListSize", orderItemListForm.size());
for (int i = 0; i < orderItemListForm.size(); i++) {
    orderMsgMapToQueue.put("orderItem"+i,JSON.toJSONString(orderItemListForm.get(i)));
}
//发送生成抢购订单的消息到消息队列，并在redis中添加此订单的记录
//0 正在生成
if(redisUtils.set("weddingshop:orders:"+ordersForm.getOid(),ordersForm)){
    //发送生成的 订单信息 到 消息队列
    rabbitTemplate.convertAndSend(OrderMQConstant.WEDDINGSHOP_SAVE_ORDER_EXCHANGE,
                                  OrderMQConstant.WEDDINGSHOP_SAVE_ORDER_ROUTING,
                                  orderMsgMapToQueue);
}

12.4.2 接收消息

监听到消息后，从map集合中取出不同的消息，根据不同的消息内容进行不同的处理；