1、登錄 1.1 登錄的時候做vip的判斷; 1.2 使用JWT(Java Web token),驗證登錄,更加安全 2、連續簽到 2.1判斷是否斷簽: 通過判斷昨天是否登錄,可以判斷; 2.2判斷連續簽到多少天: 將每次簽到的記錄保存在redis中,判斷保存的數量,有多少個,就連續簽到多少 ...
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、分享有禮
- 隱藏分享用戶的信息(因為需要對分析的用戶進行獎勵,但是又不能隨便暴露用戶的信息)
- 可以將用戶信息MD5加密後在加鹽,(內部有永固加鹽庫,自己人可以知道)
- 需要動態生成用戶相關信息,主要目的就是保護用戶信息安全;
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集合中取出不同的消息,根據不同的消息內容進行不同的處理;
點擊查看代碼
@Slf4j
@Component
//指定接聽的 消息隊列 名字
@RabbitListener(queues = OrderMQConstant.WEDDINGSHOP_SAVE_ORDER_QUEUE)
public class SeckillOrderSaveListener {
@Autowired
private RedisUtils redisUtils;
@Autowired(required = false)
private OrdersMapper ordersMapper;
@Autowired(required = false)
private OrderItemMapper orderItemMapper;
@Autowired
private OrdersService ordersService;
/**
* @author : huayu
* @date : 1/11/2022
* @param : [directMsgJson]
* @return : void
* @description : Direct 直連模式消費者One,消費信息
*/
//指定消息隊列中的消息,交給對應的方法處理
@RabbitHandler
public void saveSeckillOrder(Map<String,Object> orderMsgMapToQueue){
//子訂單消息
if(orderMsgMapToQueue.get("orderItemListSize") != null){
//插入子訂單
int orderItemListSize = Integer.parseInt(orderMsgMapToQueue.get("orderItemListSize").toString());
for (int i = 0; i < orderItemListSize; i++) {
OrderItem orderItem = JSON.parseObject(orderMsgMapToQueue.get("orderItem" + i).toString(), OrderItem.class);
log.info("***** 秒殺搶購子訂單:{},開始入庫 ******",orderItem);
if(orderItemMapper.insert(orderItem) > 0){
log.info("***** 秒殺搶購子訂單:{},開始入庫 成功 ******",orderItem);
}
}
}
//父訂單消息
if(orderMsgMapToQueue.get("ordersForm")!= null){
Orders ordersForm = JSON.parseObject(orderMsgMapToQueue.get("ordersForm").toString(), Orders.class);
log.info("***** 秒殺搶購父訂單:{},開始入庫 ******",ordersForm);
//TODO 將消息中的訂單實體對象,調入業務介面,插入到資料庫,和redis中
//插入 父訂單
if(ordersMapper.insert(ordersForm)>0){
log.info("***** 秒殺搶購父訂單:{},入庫 成功 ******",ordersForm);
}
}
//父訂單 付款後 ,操作
if(orderMsgMapToQueue.get("ordersPayOid") != null){
// 父訂單付款後 對 父訂單 修改狀態,用戶增加積分 和 子訂單 修改狀態,生成物流單號
String ordersPayOid = orderMsgMapToQueue.get("ordersPayOid").toString();
log.info("------ 父訂單:{},支付成功,對 父訂單 修改狀態,用戶增加積分 和 子訂單 修改狀態,生成物流單號------",ordersPayOid);
if(ordersService.paySuccessOrders(ordersPayOid)){
log.info("------ 父訂單:{},入庫成功,對 父訂單 修改狀態,用戶增加積分 和 子訂單 修改狀態,生成物流單號------",ordersPayOid);
}
}
}
}