工作的這幾年確實(shí)和賬務(wù)系統(tǒng)的同學(xué)打過一些交道，我是做信貸業(yè)務(wù)的，從信貸業(yè)務(wù)的角度來簡述一下賬務(wù)相關(guān)的事宜吧。
首先介紹一些名詞概念：
用戶余額，是指該用戶還有多少余額可以用，銀行儲蓄卡上的余額數(shù)字。
信貸業(yè)務(wù)還有用戶授信額度，分為用戶的固定額度或者臨時(shí)額度，一般是銀行信用卡上的額度數(shù)字。用戶的可用額度=用戶當(dāng)前擁有的授信額度-可已經(jīng)使用的額度。
當(dāng)我們使用信用卡發(fā)起一筆境內(nèi)消費(fèi)時(shí)，比如我們用信用卡買了100元的菜，那么我們的可用額度就會減少100元，菜飯的商戶余額就會增加100元。這一減一增，要么一起執(zhí)行，要么一起不執(zhí)行。這一般就是用事務(wù)來完成的。
事務(wù)有ACID四個(gè)性質(zhì)，分別是原子性、一致性，隔離性和持久性。
原子性（Atomicity）：一個(gè)事務(wù)（transaction）中的所有操作，或者全部完成，或者全部不完成，不會結(jié)束在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯(cuò)誤，會被回滾（Rollback）到事務(wù)開始前的狀態(tài)，就像這個(gè)事務(wù)從來沒有執(zhí)行過一樣。即，事務(wù)不可分割、不可約簡。[1]
一致性（Consistency）：在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預(yù)設(shè)約束、觸發(fā)器、級聯(lián)回滾等。[1]
事務(wù)隔離（Isolation）：數(shù)據(jù)庫允許多個(gè)并發(fā)事務(wù)同時(shí)對其數(shù)據(jù)進(jìn)行讀寫和修改的能力，隔離性可以防止多個(gè)事務(wù)并發(fā)執(zhí)行時(shí)由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。事務(wù)隔離分為不同級別，包括未提交讀（Read uncommitted）、提交讀（read committed）、可重復(fù)讀（repeatable read）和串行化（Serializable）。[1]
持久性（Durability）：事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失
一般CS專業(yè)的學(xué)生都是在學(xué)習(xí)數(shù)據(jù)庫的是時(shí)候?qū)W習(xí)了事務(wù)。數(shù)據(jù)庫的事務(wù)語句
Begin transaction
SQL1
SQL2
End transaction
既然提到了數(shù)據(jù)庫的事務(wù)，再多提一下數(shù)據(jù)庫事務(wù)的隔離級別，由低到高依次為Read uncommitted 、Read committed、Repeatable read 、Serializable ，RC、RR和序列化逐個(gè)解決臟讀 、不可重復(fù)讀 、幻讀這幾類問題。
事務(wù)隔離級別-學(xué)習(xí)
但是我們的日常工作中，資源都是分布在不同的應(yīng)用系統(tǒng)中的，面對這種需求，我們引入了分布式事務(wù)。分布式事務(wù)常用的解決方案一般是兩階段提交。兩階段提交需要一個(gè)或多個(gè)資源管理器（RM）、一個(gè)事務(wù)管理器（TM，有全局事務(wù)的概念）和一個(gè)應(yīng)用程序（ApplicationProgram）組成。
分布式事務(wù)最經(jīng)典的七種解決方案
第一階段（prepare）：即所有的參與者RM準(zhǔn)備執(zhí)行事務(wù)并鎖住需要的資源。參與者ready時(shí)，向TM報(bào)告已準(zhǔn)備就緒。
第二階段 (commit/rollback)：當(dāng)事務(wù)管理者(TM)確認(rèn)所有參與者(RM)都ready后，向所有參與者發(fā)送commit命令。
所以一個(gè)主事務(wù)或者全局事務(wù)它有多個(gè)子事務(wù)，一個(gè)子事務(wù)會代表一次賬務(wù)的調(diào)用，比如說提現(xiàn)、充值、凍結(jié)、解凍等。在調(diào)用圖中TransIn或者TransOut接口時(shí)，我們會先做一些前置校驗(yàn)，主要是一些參數(shù)與冪等的校驗(yàn)，然后在prepare階段做一些資源的預(yù)留，將本次交易需要的資金資源先“凍”住，避免被其他請求占用。在事物的二階段，我們會提交或者回滾。提交的話，我們會把一階段凍結(jié)住的資源還原回去，干干凈凈地進(jìn)行實(shí)際的余額扣減或者增加，會更新賬戶余額以及增加變更明細(xì)。回滾的話，我們把一階段預(yù)留的資源進(jìn)行釋放并且也會落一個(gè)記錄。
提到賬務(wù)的事務(wù)處理，必然會提到性能問題。比較著名的就是熱點(diǎn)賬戶的問題，為了賬務(wù)數(shù)據(jù)的一致性，我們會經(jīng)常地去鎖住用戶的賬務(wù)數(shù)據(jù)，當(dāng)這個(gè)用戶是大用戶或者是大機(jī)構(gòu)時(shí)，他的賬戶上就會在短時(shí)間內(nèi)有頻繁的TransIn或者TransOut的操作。比如我們做放貸業(yè)務(wù)時(shí)，一些合作的大機(jī)構(gòu)的授信客群特別多或者交易頻率比較高，那么必然會出現(xiàn)熱點(diǎn)賬戶問題。我作為賬務(wù)系統(tǒng)的上游，看到過一、兩次賬務(wù)系統(tǒng)報(bào)錯(cuò)，比如說什么賬號鎖沖突之類的。為了解決熱點(diǎn)賬戶問題，業(yè)界出現(xiàn)了主子賬戶、匯總記賬、緩沖記賬等解決方案。我一般接觸比較多的是緩沖記賬和匯總記賬。
一些業(yè)務(wù)要是允許余額數(shù)據(jù)可以存在一定的不準(zhǔn)確性，但是業(yè)務(wù)不能中斷。我的下游系統(tǒng)主要會采用緩沖或者匯總記賬的方式來解決。
緩沖記賬主要是采用了“削峰填谷”的思路去做。所以我們會采取將實(shí)時(shí)的記賬操作異步化的方式來解決。當(dāng)賬戶的交易量超過實(shí)時(shí)處理閾值時(shí)，賬戶先返回成功標(biāo)識給客戶，把待處理的賬務(wù)請求寫入消息隊(duì)列，待并發(fā)量不大時(shí)再從消息隊(duì)列取記錄做記賬處理。
匯總記賬的話就是先將外部的系統(tǒng)賬務(wù)調(diào)用請求落庫，定時(shí)的將某個(gè)時(shí)間段內(nèi)的交易sum進(jìn)行匯總，再將匯總的金額作用到賬戶余額上，減少與數(shù)據(jù)庫的交互，避免出現(xiàn)數(shù)據(jù)庫處理的瓶頸問題。
其他的一些熱點(diǎn)賬戶節(jié)點(diǎn)方案可以查看
淺談熱點(diǎn)賬戶技術(shù)解決方案
有些業(yè)務(wù)會存在熱點(diǎn)賬戶問題，但是它既要余額做到準(zhǔn)實(shí)時(shí)又要不中斷業(yè)務(wù)，也不能透支。這時(shí)候面對余額更新問題，我們引入了流式計(jì)算（flink）作為解決方案以及對于流出的賬戶設(shè)置一定的buffer水位底線，一旦低于某個(gè)設(shè)定的底線后將不能再流出，這樣既可以做到余額的準(zhǔn)實(shí)時(shí)也可以一定程度上的放透支。
數(shù)據(jù)除了需要保證實(shí)時(shí)性，還需要保證準(zhǔn)確性和穩(wěn)定性，所有還會建立雙鏈路，進(jìn)行核對互備的方式保證準(zhǔn)確性與穩(wěn)定性，其次應(yīng)用層還可再加上緩存提高數(shù)據(jù)使用的穩(wěn)定性。
一般來說，緩沖賬戶的準(zhǔn)實(shí)時(shí)余額=賬戶T日日終的余額+實(shí)時(shí)的流入與流出。日終余額一般都是在賬戶日切之后的余額。
日切，通俗的來說就是更換系統(tǒng)記賬的時(shí)間；系統(tǒng)從當(dāng)前工作日切換到下一工作日，日切過程中交易可以照常提交并正確處理返回。
一般狀態(tài)下，不會在過了日切點(diǎn)之后就日切完成的，賬務(wù)是業(yè)務(wù)系統(tǒng)中相對底層的系統(tǒng)，如果他的上游出現(xiàn)了一些問題后，那么就會導(dǎo)致不能自動日切完成，就會“卡日切”，所以為了留有一些buffer處理的空間，我們會取用T-2日的日終余額+賬戶的實(shí)時(shí)流入與流出。
賬戶的實(shí)時(shí)流入與流出的計(jì)算就采用了flink技術(shù)。這種場景我們一般都是采用lambda架構(gòu)，業(yè)界也有很多的處理方案可以查看。
美團(tuán)外賣實(shí)時(shí)數(shù)倉建設(shè)實(shí)踐
