齊木楠雄的災(zāi)難
當(dāng)前表
歷史表
清單表
流水表
日志表
控制表
工單表
歷史表
我們?cè)O(shè)計(jì)一個(gè)數(shù)據(jù)表的時(shí)候，常常只設(shè)計(jì)表本身，最多對(duì)請(qǐng)求記錄一條日志。導(dǎo)致實(shí)際生產(chǎn)過(guò)程中出了點(diǎn)什么bug，查數(shù)據(jù)流查到shi，有任何一點(diǎn)問(wèn)題，都要一點(diǎn)點(diǎn)翻代碼，代價(jià)高，效率低。這就是因?yàn)槲覀兾覀冊(cè)谶M(jìn)行數(shù)據(jù)表設(shè)計(jì)的時(shí)候，只在乎實(shí)現(xiàn)功能，對(duì)數(shù)據(jù)不夠重視，對(duì)數(shù)據(jù)的流轉(zhuǎn)過(guò)程并沒(méi)有記錄下來(lái)。這個(gè)時(shí)候就需要我們的--歷史表--閃亮登場(chǎng)了。
舉例：當(dāng)前表 customers
{ "_id": { "type": "string", "comment": "主鍵" }, "key1": { "type": "string", "comment": "" }, "key2": { "type": "integer", "comment": "" }, "operator_id": { "type": "string", "comment": "操作員" }, "operate_type": { "type": "integer", "comment": "操作類(lèi)型, 增:1, 刪:2, 改:3" }, "create_time": { "type": "date", "comment": "創(chuàng)建時(shí)間" }, "update_time": { "type": "date", "comment": "修改時(shí)間" }}
其中_id為主鍵，key1和key2為表的字段，operator_id, operate_type, create_time, update_time為必須要有的字段內(nèi)容，對(duì)于當(dāng)前數(shù)據(jù)的操作員，操作類(lèi)型，創(chuàng)建時(shí)間和修改時(shí)間是當(dāng)前表中重要的內(nèi)容，對(duì)于生產(chǎn)環(huán)境中出的操作問(wèn)題或者是bug可以起到快速追溯的作用。
而一個(gè)正常的當(dāng)前表，必然有歷史表，一般在當(dāng)前表的后綴添加_his（即history的縮寫(xiě)），customers_his，歷史表與當(dāng)前表的字段一模一樣，一旦當(dāng)前表出現(xiàn)增刪改操作，歷史表中增加一條數(shù)據(jù)，并且有對(duì)應(yīng)的操作類(lèi)型（tips: 如果是刪出操作，當(dāng)前表中沒(méi)有，歷史表中有刪出的操作類(lèi)型）。
清單表
當(dāng)某一個(gè)功能，產(chǎn)生重復(fù)相似的數(shù)據(jù)（例如通話記錄），那么我們就需要一個(gè)清單表，將所有可能產(chǎn)生的數(shù)據(jù)作保存，清單表只作增加和轉(zhuǎn)移，不作刪出和修改。
舉例：concact_list
{ "_id": { "type": "string", "comment": "主鍵" }, "key1": { "type": "string", "comment": "" }, "key2": { "type": "string", "comment": "" }, "operator_id": { "type": "string", "comment": "操作員" }, "create_time": { "type": "date", "comment": "創(chuàng)建時(shí)間" }}
清單表中沒(méi)有操作類(lèi)型和更新時(shí)間，因?yàn)榍鍐伪碇蛔髟黾?，沒(méi)有修改操作，也不允許刪除（tips：僅在表格數(shù)據(jù)量壓力過(guò)大時(shí)將數(shù)據(jù)遷移出清單表）
流水表
當(dāng)某一數(shù)據(jù)，經(jīng)常修改，當(dāng)并不是以數(shù)據(jù)列表的形式存在，而是某關(guān)聯(lián)數(shù)據(jù)的某個(gè)狀態(tài)的時(shí)候，這樣的數(shù)據(jù)就不需要采用 當(dāng)前表 + 歷史表 的組合，可以用流水表的形式來(lái)體現(xiàn)。
舉例： qc_srl
{ "_id": { "type": "string", "comment": "主鍵" }, "key1": { "type": "string", "comment": "" }, "key2": { "type": "string", "comment": "" }, "operator_id": { "type": "string", "comment": "操作員" }, "create_time": { "type": "date", "comment": "創(chuàng)建時(shí)間" }}
流水表也不需要操作類(lèi)型和更新時(shí)間，因?yàn)榱魉硪仓蛔髟黾?。獲取狀態(tài)的時(shí)候，只要獲取最近的創(chuàng)建時(shí)間對(duì)應(yīng)的數(shù)據(jù)即可，而且不會(huì)流失操作過(guò)程，具有可查性。
日志表
日志表其實(shí)是清單表的另一種體現(xiàn)形式，記錄的是操作日志，例如前端每發(fā)送一個(gè)請(qǐng)求就記錄一條日志，含入?yún)ⅲ蠖嗣堪l(fā)出一個(gè)返回也記錄一條日志，含出參。像這種可以概括的形式，應(yīng)該封裝成模塊，發(fā)送請(qǐng)求和返回時(shí)直接調(diào)用即可。
除了入?yún)⒑统鰠?，也可以自由地在程序?dāng)中覺(jué)得需要記錄日志的節(jié)點(diǎn)記錄日志。而且日志量可能巨大，因此建議日志系統(tǒng)單獨(dú)做，不與應(yīng)用系統(tǒng)共同存在，這樣可以減少由于日志表過(guò)多的數(shù)據(jù)量拖慢應(yīng)用系統(tǒng)的性能。
正因?yàn)橐陨显?，日志表于清單表又有一些不一樣的字段?/p>
舉例： logs
{ "_id": { "type": "string", "comment": "主鍵" }, "operator_id": { "type": "string", "comment": "操作員" }, "method": { "type": "integer", "comment": "方法：GET：1， POST：2， PATCH：3， DELETE：4， PUT：5" }, "ip": { "type": "string", "comment": "IP" }, "url": { "type": "string", "comment": "url" }, "system": { "type": "string", "comment": "系統(tǒng)" }, "part": { "type": "integer", "comment": "集群化部署時(shí)的機(jī)器" }, "level": { "type": "integer", "comment": "日志等級(jí)，error: 1, warning: 2, info: 3" }, "keyword": { "type": "string", "comment": "關(guān)鍵字" }, "create_time": { "type": "date", "comment": "傳輸過(guò)來(lái)的創(chuàng)建時(shí)間" }, "system_time": { "type": "date", "comment": "本系統(tǒng)的創(chuàng)建時(shí)間" }, "options": { "type": "object", "comment": "日志內(nèi)容，以json形式儲(chǔ)存" }}
system字段表示系統(tǒng)，因?yàn)楣究赡苡卸鄠€(gè)系統(tǒng)，但是公用一套日志系統(tǒng)，因此采用system字段標(biāo)識(shí)系統(tǒng)。
part機(jī)器名稱(chēng)，用數(shù)字對(duì)應(yīng)機(jī)器名稱(chēng)，采用字典翻譯，一個(gè)有規(guī)模的系統(tǒng)不可能是部署在一臺(tái)機(jī)器上的，基本都是呈多臺(tái)機(jī)器集群化部署，因?yàn)槿罩緝?nèi)容中對(duì)機(jī)器體現(xiàn)也是非常重要的。
level為日志等級(jí)，在不同的情況下記錄不同的等級(jí)，方便查找生產(chǎn)bug對(duì)應(yīng)的日志的時(shí)候篩選。
keyword，在進(jìn)行不定向日志記錄的時(shí)候，有些重要且容易反復(fù)發(fā)生問(wèn)題的日志可以記錄一個(gè)關(guān)鍵字，方便查找問(wèn)題的時(shí)候快速篩選出目標(biāo)日志。
create_time和system_time分別是請(qǐng)求傳輸過(guò)來(lái)帶的時(shí)間和日志系統(tǒng)產(chǎn)生的本地時(shí)間，兩者的差距可以看出網(wǎng)絡(luò)傳輸?shù)乃俣取?/p>
options是最重要的日志的內(nèi)容，以json格式儲(chǔ)存。
控制表
有些時(shí)候，某個(gè)動(dòng)能可以要批量的操作到大量的數(shù)據(jù)，而且有可能多個(gè)帳號(hào)操作同一批數(shù)據(jù)，或同一匹數(shù)據(jù)的關(guān)聯(lián)值，那么當(dāng)一個(gè)操作以不同的操作員同時(shí)發(fā)生的時(shí)候，就有可能會(huì)產(chǎn)生重復(fù)數(shù)據(jù)或者是數(shù)據(jù)流轉(zhuǎn)不準(zhǔn)確的問(wèn)題。這個(gè)時(shí)候，就可以由我們的--控制表--出場(chǎng)了。
控制表，顧名思義，就是對(duì)某個(gè)事件進(jìn)行控制，當(dāng)某個(gè)任務(wù)開(kāi)始執(zhí)行的時(shí)候，在控制表中添加一條數(shù)據(jù)，在任務(wù)進(jìn)行中的時(shí)候，如果再次請(qǐng)求，先查詢(xún)數(shù)據(jù)的狀態(tài)，如果正在進(jìn)行中則返回進(jìn)行中不再次進(jìn)行，當(dāng)任務(wù)結(jié)束，則將控制表數(shù)據(jù)改為運(yùn)行結(jié)束的狀態(tài)。
工單表
當(dāng)一匹數(shù)據(jù)將要被處理的時(shí)候，我們總擔(dān)心，如果其中一條數(shù)據(jù)因?yàn)楦鞣N各樣的原因被處理失敗了怎么辦？是全部失敗直接報(bào)錯(cuò)呢還是部分成功，如果是部分成功，那失敗的數(shù)據(jù)是放置還是再次執(zhí)行，如果執(zhí)行一直失敗會(huì)不會(huì)卡在循環(huán)里搞崩系統(tǒng)，這一系列的問(wèn)題到底要怎么處理比較好呢？
下一個(gè)閃亮登場(chǎng)--工單表。
首先，將要處理的數(shù)據(jù)全部存入指定的表中。
然后安排指定程序每秒鐘掃描指定的表，如果表中有內(nèi)容，則執(zhí)行指定程序。執(zhí)行成功，將數(shù)據(jù)搬入工單成功表，執(zhí)行失敗將數(shù)據(jù)搬入工單失敗表并標(biāo)記失敗次數(shù)。同時(shí)程序也掃描工單失敗表，成功則搬入工單成功表，失敗則更新失敗次數(shù)。失敗到指定次數(shù)之后的數(shù)據(jù)不再繼續(xù)執(zhí)行。
這樣，數(shù)據(jù)便能被安全地、分批次地執(zhí)行完畢，而且不必?fù)?dān)心同功能的多次事件并發(fā)所造成的壓力。最后還可以在頁(yè)面展示失敗數(shù)據(jù)。人為地進(jìn)行核查。
類(lèi)似的實(shí)現(xiàn)方式除了工單表之外，訂閱--消息的方式更加值得推重。下次補(bǔ)充。
更多：阿里云部署 nodejs+mongoDB 傻瓜教程（https://jianshu/p/69f15b812c71）
