由於系統存在乙個押賬功能的需求，（何為押賬，就是形成公司的資金池，類似摩拜單車，ofo單車等等）。目前b2b平台也是採用押賬的這種功能策略。
這裡有個特別說明的押賬方式：就是比如有個賣家張三，他是5月1日跟我們平台簽約開始入住平台賣菜，我們約定好押賬7天，那麼他5月1日的金額會在5月2日存入
他自己的餘額裡面，但是這個錢不能馬上提取出來，需要等乙個星期，也就是5月8日可以提現5月1日的金額，5月9日可以提現5月2日以前的所有金額。
這個演算法的最大好處就是永遠的壓住客戶7天的金額。
這個演算法採用的是spring quartz定時器每天晚上23:00點處理的。
相關核心的**如下：
/**補充說明：1.需要統計每個賣家今天的收入。* 任務工作
* @author wangfucai */@componentpublic class tasksquartzcatch(exception ex)
}
2.並行的需要把訂單的資料存入賬單表。
3.餘額**於賬單表。形成乙個資料的流轉體現。
賬單表的表結構如下：
補充說明：每天定時器會根據賣家的賬期形成賬單，最終更新到用賣家的餘額裡面。
實際運營情況來講是每個賣家的賬期是不一樣的，有的兩天，有的三天，有的一周，有的是乙個月。
相關核心演算法與**如下：
/**業務說明：* 統計10天前的賬單更新賣家餘額和賬單金額 */
@override public void updatemoney() for (mapmap : list) // 獲取提現的金額即最終賬單的金額
bigdecimal realitymoney = (bigdecimal) map.get("realincome"); if (realitymoney == null) // 獲取賣家的餘額
bigdecimal balancemoney = (bigdecimal) map.get("balancemoney"); if (balancemoney == null) // 獲取賣家的賬單金額
bigdecimal billmoney = (bigdecimal) map.get("billmoney"); if (billmoney == null) // 金額相加
bigdecimal resultbalancemoney = realitymoney.add(balancemoney);
bigdecimal resultbillmoney = realitymoney.add(billmoney);
logger.info("當前使用者sellerid:" + sellerid + " 當前的餘額為：balancemoney=" + balancemoney + " 最終金額：resultbalancemoney=" + resultbalancemoney);
logger.info("當前的餘額為：billmoney=" + billmoney + " 最終金額：resultbillmoney=" + resultbillmoney); // 更新賣家餘額和賬單金額
int result = sellerdao.updatemoney(sellerid, resultbalancemoney, resultbillmoney);
logger.info("當前使用者sellerid:" + sellerid + " 更新結果為：" + (result > 0));
} // 更新十天前的所有賬單的狀態
int count = billdao.updatestatus(day);
logger.info(" 更新" + count + "條賬單，狀態變為已結算");
}
1. 無外乎每天需要統計賣家的今日收益情況。
2. 更新賣家的最終餘額。
3. 根據賣家的所設定的賬單週期，形成使用者的賬單金額。
4. 最終根據賬單金額，形成使用者的可提現餘額的過程。
業務有點繞口，但是整體是非常地清晰的，思路就是押使用者所配置的賬期金額。配置10天就壓10天，配置15天就壓15天。
以下是賬單跟賣家的核心關聯表，就是配置所屬的賣家對應的所屬賬期時間。
電商平台 訂單抽成模組的設計與架構
說明 訂單抽成指的是向賣家收取相應的資訊服務費.目前市場上有兩種抽成方式，一種是按照總額的抽成比率，另外一種是按照訂單明細的抽成比率 由於生鮮電商的垂直領域的特殊性質，總額抽成不切合實際，所以按照訂單的明細抽成。1.訂單抽成，是按照乙個區的維度，以及菜品的二級分類類抽點的。舉例說明 比如武漢光谷區，...
電商平台的系統組織架構
參與電商系統開發已有兩年，我一直負責的工作就是跟電商平台對接，起初對接的平台只有 天貓 京東這幾個主流大平台，後來隨著各品牌的業務拓展，後續逐漸對接其他比較有規格的電商平台 目前已對接 唯品會，蘇寧易購，小紅書，寺庫，網易考拉，噹噹，後續還會繼續對接其他渠道 一開始我對於對接這麼多平台並不是很理解，...
分布式電商平台的架構設計要點
分布式電商平台的架構設計要點 電商平台主要分成 應用系統 日誌採集平台 監控平台 三大部分 應用系統是基於微服務架構的分布式架構，由微服務模組 分布式服務的註冊和呼叫平台 快取中介軟體 訊息中介軟體 分布式搜尋中介軟體 資料庫分庫分表中介軟體 組成 日誌採集平台包括日誌的收集 和 儲存 基於大資料平...