通過一個面試筆試題目將最近的知識串一下

X_AirDu 發(fā)布于2019-08-16 10:46 / 3320人閱讀

摘要：預算管理要求消耗的物品的數(shù)量能夠按照預算庫存進行消耗，不能超額，盡可能的保障預算的消耗率。描述了用戶執(zhí)行搶購的交易信息訂單號，搶購標的編號，狀態(tài)凍結(jié)失敗成功交易數(shù)量，用戶編號。

題目

背景描述：
在現(xiàn)今電子商務(wù)場景下，預算管理在很多場景下都有廣泛應用，比如營銷獎品，積分、紅包的發(fā)放、商品庫存管理等。預算管理要求消耗的物品的數(shù)量能夠按照預算庫存進行消耗，不能超額，盡可能的保障預算的消耗率。
大規(guī)模請求量以及分布式環(huán)境下，預算管理問題更加突出，如果預算控制不合理，則會出現(xiàn)物品超發(fā)或是預算消耗率不高的情況，超發(fā)會導致直接的資金損失出現(xiàn)；預算消耗率不高則會導致商品無法賣出、獎品無法發(fā)放等問題，從而導致間接的資金損失。

編程要求：

根據(jù)上面的背景，用偽代碼描述如下功能，在分布式集群環(huán)境下，有一批積分需要發(fā)放給用戶，存放在數(shù)據(jù)庫中，實現(xiàn)預算的扣減方法。

//: TODO 可自行定義變量  
/**    
* 扣減預算
* @param consumption 當前需要扣減的消耗量    
* @return 預算的扣減是否成功  
*/
public boolean budgetDeduct(int consumption){
    //: TODO 完成此處的代碼
}

思考

作為新手，可能只會想到加鎖，比如先加上悲觀鎖（先來個select for update，鎖住之后再來個update 加上超發(fā)的where限制等）。所有的事情都在一個服務(wù)方法中完成，即可。好處是實現(xiàn)簡單，壞處呢，比如響應慢，執(zhí)行效率低（悲觀鎖）等。
如果是老手，實現(xiàn)就會比較復雜

表設(shè)計

標的物表 target_tbl(id,name,total_number,available_number,froze_number)
搶購交易表trade_order_tbl(order_id,target_tbl_id,state,trade_number,user_id)
target_tbl描述了搶購的目標物件信息：名字，總數(shù)量，可用數(shù)量，凍結(jié)數(shù)量。
trade_order_tbl描述了用戶執(zhí)行搶購的交易信息：訂單號，搶購標的編號，狀態(tài)（凍結(jié)/失敗/成功）,交易數(shù)量，用戶編號。

程序設(shè)計（偽碼）

public boolean budgetDeduct(int consumption){
    Long tradeOrderId=frozeTarget(userId,targetId,consumption);
    if(tradeOrderId !=null){
        //凍結(jié)成功之后，執(zhí)行業(yè)務(wù)操作，或是檢查
        bool isBusiSucc = doBusiness();
        //業(yè)務(wù)操作成功，則更新交易，并將搶購商品入個人賬
        if(isBusiSucc){
            return updateTrade()
        }else{
            //業(yè)務(wù)操作失敗，則解凍交易
            return undoFrozeTarget();
        }
    }else{
        //凍結(jié)不成功，返回失敗
        return false;
    }
}
/**
* 需要事務(wù)支持，異常回滾
* @param userId 搶購用戶編號
* @param targetId 搶購商品編號
* @param consumption 搶購數(shù)量
* @return
**/
private Long frozeTarget(String userId,String targetId, int consumption){
    int updated=0;
    //通過樂觀鎖的方式進行更新，嘗試5次，5次仍舊失敗，則認為凍結(jié)失敗
    for(int i=0;i<5;i++){
        //update target_tbl 
        //set froze_number = froze_number+consumption ,available_number = available_number-consumptionwhere available_number>=consumption
        updated = executeFroze();
        if(updated != 0)
        {
            break;
        }else{
            continue;
        }
    }
    if(update == 0){//凍結(jié)不成功
        return null;
    }else{
        //凍結(jié)成功，添加搶購交易記錄
        Long tradeOrderId = createOrder();
        return tradeOrderId;
    }
}
/**
*需要事務(wù)支持，異常回滾
*失敗需要重試
*/
private bool updateTrade(){
    //1.更新交易表狀態(tài)為成功
    //2.更新標的表，使標的表的total_number,available_number,froze_number 減去交易表的trade_number
    //3.更新用戶信息
}
/**
*需要事務(wù)支持，異常回滾
*失敗需要重試
*/
private bool undoFrozeTarget(){
    //1.更新交易表狀態(tài)為失敗
    //2.更新標的表，使標的表的available_number+trade_number,froze_number-trade_number
}

另一個思路

一般我們在設(shè)計的時候，流水表和商戶賬戶表是同時更新的，比如用戶充值，沖完之后，用戶賬戶就是更新后的值。但是在一些業(yè)務(wù)場景下，流水表和賬戶表不需要同時更新，賬戶表通過定時任務(wù)來批量更新，或是業(yè)務(wù)上允許賬戶變動能容忍一定的滯后。這帶了的思考是，先將完整業(yè)務(wù)流程細分到更新表的操作，再從業(yè)務(wù)上去梳理，將幾個表的操作組合起來，重新組合為業(yè)務(wù)場景。