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 = "https://www.cnblogs.com/xiaoqigui/archive/2022/11/25/xxx")注解，@ApiModelProperty(value = "https://www.cnblogs.com/xiaoqigui/archive/2022/11/25/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集合中取出不同的訊息，根據不同的訊息內容進行不同的處理；