背景：
小陳在老王和龍哥的要求下，要重構乙個舊的財務庫存系統。那麼第一件事就是了解財務庫存系統幹啥的。
財務庫存系統，系統主要職能在於處理上游wms（倉儲系統-物理倉儲）推送的庫存指令，對應處理，生成財務庫存資料，作為結算依據。（簡單理解，對比物理倉儲，增加了財務資訊，如公司，稅，**商，po-採購批次，成本計算等）
上下游：
wms(物理倉儲) -> inv（財務庫存） -> ap（財務應付）
小陳繼續研究，先看看舊系統怎麼玩的，能不能複製貼上。
舊系統方案：
採用批處理，單執行緒操作，一批載入一定量資料，因不存在併發，不涉及競爭問題，純邏輯。
定方案前，小陳想起老王/龍哥的指導性要求：效能必須超過舊系統10倍，mysql分庫分表，支援10倍業務資料量。
小陳先理解一下業務：
純業務角度思考，現有量實質上是一張表，維護每個商品當前剩餘數量資訊。
庫存指令下達時，根據指令更新現有量。
比較難搞的幾個點：
幾乎全部庫存指令，都涉及現有量（商品剩餘庫存）的操作，如何兼顧效能和準確性，並符合財務業務邏輯。
對現有量的操作，實質上是乙個競爭，併發安全的問題，如：
指令1扣減商品1庫存，指令2扣減相同商品庫存，當前符合條件的現有量只有1條，兩條指令只能成功一條，失敗一條。
分庫分表：
新系統必然要分庫分表，那第乙個事就是定分庫字段，庫存業務以po驅動，基本關鍵業務表都有po欄位，所以定的是po分庫。（事實上這裡錯失了乙個重要的機會，不採用sku-商品分庫）。那麼，db架構可能是這樣：
乙個基礎庫，儲存不需要分庫的基礎資料
sharding庫n個，儲存資料量比較大的，需要分庫分表的資料。
問題來了，現有量表放哪合適？
小陳繼續細思，如果放base庫，業務表都是用po分庫的，如庫存調整表（儲存上游下發的庫存指令），那麼這些指令處理完成以後，對現有量的操作，最好也是在相同的db裡面完成，這樣才能簡單的由db層面完成事務而不是踩進分布式事務的大坑。
如果放sharding庫，似乎可行，正常現有量都附帶有po，但有些業務場景，現有量的po會發生變化（月結時清空現有量上的po，讓資料過校驗），甚至為空（歷史資料），發生變化時就是乙個多庫事務。
經過一番思索，小陳在領導指導下終於有了v1.0：
1 表儲存： 現有量拆分成兩部分，base庫中維護現有量彙總表，存放已彙總的現有量資料。sharding庫中維護現有量流水表，也採用po分庫。每個指令（如果現有量充足）處理完生成對應的流水記錄，這樣指令的處理會在乙個db中完成。（update指令狀態為success，插入流水，插入業務資料）
2 現有量彙總：流水表的記錄需定時彙總到彙總表，不然過多的流水記錄，會影響查詢效能，這裡要增加乙個游標表，標識當前彙總到**（以時間為例子）。
比方說游標表儲存的時間是2018-10-01，則建立時間在這個時點之前的流水資料，已經彙總到彙總表，在這個時間之後的資料則未彙總。
現有量彙總 = 查詢當前游標時點到目標游標時點的資料，彙總到彙總表並更新游標，彙總表和游標表均在base庫，乙個事務搞定，並不影響sharding庫資料。
3現有量查詢：查詢base庫資料 + 大於游標時點的sharding庫資料
4現有量流水表清理：刪除掉建立時間早於游標表時間的資料，保持流水表乾淨，提高查詢效能
5增加sku鎖，對乙個sku，同一時刻只有乙個執行緒可以修改現有量。
6為了效能，小陳決定再加一層快取。
6.1 現有量查詢時，優先查快取，如果快取為空，查詢後，將結果寫入快取，key是sku，value是現有量+流水
6.2 流水處理後，往快取追加新的流水
6.3 快取裡面key對應的value過大時，重新從db load資料（db層面一直在彙總，重新拉的資料量會大幅減少，如果不處理，value過大會占用網路io）
7 同db資料組批處理
小陳經過分析，感覺似乎湊合，開工擼**，上線，結果來事了。。。
上文的3現有量查詢，其實並不是描述的那麼簡單。
偽**b1 查詢base庫現有量
b2 查詢base庫游標
b3 查詢sharding庫資料
b1，b2中間，如果發生了現有量彙總,則是標準不一致，出錯是正常的。（是否b1，b2乙個查詢sql查出來就可以避免？待分析）
於是有了乙個新的鎖。。。
v1.2
8 增加現有量查詢鎖，現有量彙總時，彙總哪個sku鎖哪個，被鎖的sku無法查詢，自旋等待，超時退出後續重試。
好了，系統上線了，看起來都穩定了。小陳回過頭看看自己懟出來的這個方案，有啥好跟不好呢？
優點：規避了多庫事務；業務處理純單庫事務，組批處理，效能比舊系統提高10倍。
缺點：引入了兩層鎖，業務量到一定程度，是明顯的瓶頸。
yy：如果採用sku分庫，可能一切都不是問題。
反正上線了，小陳懟新的系統去了，那麼大神們，我們應該如何優化呢？
秒殺系統，庫存優化
直接上 1 public class redisshop 89 autowired 10private productservice productservice 11 autowired 12private stringredistemplate stringredistemplate 13 au...
財務系統設計 序
新年伊始，組織團隊小夥伴進行了一次頭腦風暴，暢想了下財務系統2019的願景，自己也思考頗多，決定針對 財務系統設計 做個專欄，落筆為記！一 一次頭腦風暴 頭腦風暴前，除了準備泡麵，花生，礦泉水，還列了幾個比較現實的問題 與我個人而言，期望通過這次頭腦風暴，讓團隊小夥伴們能夠對自己的模組有個規劃，能夠...
好用的財務報銷系統改變財務模式
好用的財務報銷系統改變財務模式 在網際網路時代，各類應用軟體的普及促進了企業資訊化的發展。在提高效率的同時，也有助於規範公司的業務流程。但在財務報銷系統方面，由於缺乏經驗和資金投入，許多企業對是否選擇使用雲報銷軟體系統而猶豫不決。還有乙個，很多企業不了解雲報銷軟體，不知道哪些財務報銷系統好用。我就給...