幾萬年前，孫悟空大鬧地府後刪庫跑路了！那閻王生死簿又該怎麼寫呢？

• 2020 年 2 月 21 日
• 筆記

「

話說幾萬年前，有一隻猴子在大鬧地府刪庫跑路，導致地府幾百年沒緩過勁兒來……

在知乎上冒出這麼一個問題：「孫悟空無姓無名的時候，閻王生死簿是怎麼寫的呢？」

生死薄技術上如何實現？廣大生靈在生死薄中的唯一標記是什麼？陰間數據庫是什麼樣一個數據庫？於是腦洞大開的程序員開始了他們的表演…..

地獄數據庫系統到底是什麼樣的？

來自知乎網友大海的回復：

https://www.zhihu.com/question/29775354/answer/45744415  

這個問題讓我對地獄數據庫系統（Hell-DBMS )進行了幾點小思考，開個腦洞。

首先，地獄必須有數據庫，數據量太大了。

每個生靈都要有記錄，且必須是實時記錄，要進行數據分析。想像一下各種生靈，萬物有靈，大大小小，連螻蟻飛蛾也是命，從單細胞到現代社會的數據應該有多大。

數據庫的話每個生靈就要有唯一標記。實名反對說是名字主鍵的，這是基本知識，名字重名怎麼辦，數據庫原理請重修。

實名反對說是 IP 地址標記的，IPV4 很快就用光的好不好；IPV6 貌似在生物歷史長河中也是不夠的，朝生暮死都是生靈，這麼多年過去了，這數據積累。

把自動生成的唯一 ID 當主鍵相對還靠譜，但位數必須相當長，數據庫得特別設計，如此大數據至少要谷歌技術支持，也許叫地獄歌，SQL-SERVER 之類的技術根本頂不住。

搞 Hell-DBMS 請先看下大技術：

• Hoogle File System
• Hoogle Bigtable
• Hoogle MapReduce

對了，《開源海量數據庫技術在陰間生死管理系統中的研究與實踐》應該獲得天庭科技進步特等獎的。

其次，查詢效率必須高。

查詢效率低的話，閻王還得點支煙等半天結果么，經常有上級官員過來查數據，玉皇啊，如來啊，即使是阿難、迦葉來也是惹不起的人，用戶不滿意，KPI 不行、績效差閻王官位不穩的。

業務量這麼大，每天至少插入數億條新記錄，刪除數億條記錄，所有善惡狀態數據都要實時記錄，想想要接多少善惡傳感器，信道衝突肯定很難解決。

好事壞事用 Wi-Fi 還是 Zigbee 傳的不清楚，說不定某米會推出家庭善惡智能數據處理中心。

生靈死掉之後還要迅速進行大數據分析，判定死人到底應該進幾層地獄。數據分析慢了奈何橋都要排隊，用戶差評有木有！

數據粒度非常非常細，死亡時間三更五更都不能差，下了地獄打多少下鐵棍都要精確計算，況且還會有許多異常發生，有時候要回滾，有可能不小心操作錯了（死而復生應該就是地府回滾，詳細請見《聊齋志異》[1])。

有時候要災難恢復，比如孫猴子搗亂引起的災難性數據損失；比如用戶投訴問題，憑什麼猴子要短命？

這種問題只有孫猴子問得出，不僅問得出還直接上門責問，地府的安保工作真的要加強。

對了，像悟空這種異常用戶，Sa 恨不得一刪了之有木有？（不懂 Sa 的 IT 人士請自行面壁，Admin 也算 Sa）

再次，必須能應對瞬時並發高峰數據。

戰爭來了，成千上萬的人陣亡；瘟疫了，成千上萬人逝去；滅鼠了，幾萬幾十萬老鼠完蛋；飛機撒農藥了，多少修行不夠的小精靈批量完蛋。

有生靈死亡必須要登記並把流程向前推進，這是典型的移動應用，無數的勾魂小鬼在短時間內飛速趕到現場。

管它是掃二維碼還是近場通訊技術 NFC，反正無數小鬼同時用移動客戶端向 Hell-DBMS 系統上傳數據，App 必須友好，後台必須能頂住。

不能學 12307-1 總是掉鏈子，12307-1 掉了鏈子還能罵它：「去死！Go to Hell!」，Hell-DBMS 可怎麼罵才好。

所以呢：關鍵時刻，服務器不能卡住，數據庫性能不能下降，生死薄必須實時更新。

最後，必須有大數據分析和預測技術。

陰間有諦聽，可以通過「聽」，得到過去數據和未來的數據，這明顯是大數據和雲結合的傑作。

為什麼是聽呢？因為陰間數據庫已經把數據語音化了，用定向波束直接送到諦聽耳邊，電磁監聽根本沒有效果，幾乎不可能泄密。定向波束的技術在加大功率後可同時用於在陰間跳廣場舞的某些亡靈們。

那麼孫猴子在陰間里刪除數據，怎麼刪除的？後來如何？

結論 1： 猴子要刪除數據，應該是從界面刪除的，沒什麼高技術，純粹的社會工程而已。

巨型數據庫，大數據數據庫一定是分解得比較細的，刪除的話至少是多表級聯刪除，直接從主表 DELETE 未免要引發異常。

再說孫猴子不是計算機專業的，應該是用金箍棒頂着小鬼的頂梁門，脅迫他用超級用戶進去，選擇界面的刪除功能搞定的。

我猜陰間數據庫刪除要左右各一個小鬼，持閻王發的優盾，同時輸入口令。

孫猴子反正克隆能力強，變出幾個分身分別逼住就能搞定。這個 Bug 系統必須要改進。

所以這是正常刪除，刪除之後，輪迴系統並沒有完全混亂，隻影響了一部分數據。

即使給孫猴子開個 CONSOLE，他也記不住命令，猴急猴急，抓耳撓腮，他最多會點點鼠標。

結論 2：陰間數據庫有強勁的災難恢復功能。

話說，猴子完全低估了程序員們的實力。海量數據庫都有強大的異地容災備份功能，數據應該是備在最安全的雷音寺（第三方），所有操作均有 LOG。

在西方以如來為首的專家團指導下（具體操作應該是負責安全保衛的天王，成就歸於領導），數據迅速恢復，猴子們根本沒有得到永生，在西方如來團隊的支持下數據迅速恢復，猴子家族應該死還是死。

孫猴子自己么，雖然罪過不小，但是他會鬧，能力還強。為了和諧天庭管理層還是為他做了特殊標記，在數據庫里加上一個 TAG，設定為神仙級，計算壽命但不設定界限，有異常情況直接發出系統警報，和 RuLai -SkyNet All-in System 系統聯動，確保一方平安。

參考文獻：

0 、《Big Data Application Platform for Hell》[J] InHell Hell-SCI收錄 1、《論Paxos算法在陰間生死管理系統中的應用與優化》[J] 陰間信息技術 玉帝元年 第7788卷 核刊 2、《論Consistent Hash在陰間生死管理系統雲中的應用》[M]陰間信息技術 玉帝9527年 第125222 核刊 3、 《論超大規模稠密矩陣在陰間生死管理系統中的理論研究》[C] 信息技術陰間應用大會 9528 4、 《論孟婆湯在陰間生死管理系統庫存管理當中的管理流程》 [J] 陰間食品與營養 VOL 2241554 5、《論牛頭馬面陰間勾人大隊的管理電子化》[J] 陰間數字化城管研究 VOL15486488789 6、《論天庭-西天-陰間點對點技術在陰間辦公自動化中的實現》 [J] 陰間實用軟件增刊。

地獄數據庫是如何設計的？

來自知乎網友蘿魏紫的回復：

https://www.zhihu.com/question/29775354/answer/287551487  

關於孫悟空無姓無名的時候，閻王生死簿是怎麼寫的呢？這個問題，當然是 ID 呀，每個東西 New 出來就有個 ID，沒人用 Name 做主鍵的！

根據原文可以得知：

悟空道：「胡說！胡說！常言道：『官差吏差，來人不差。』你快取生死簿子來我看！」十王聞言，即請上殿查看。

悟空執着如意棒，徑登森羅殿上，正中間南面坐上。十王即命掌案的判官取出文簿來查。

那判官不敢怠慢，便到司房裡，捧出五六簿文書並十類簿子，逐一查看。裸蟲、毛蟲、羽蟲、昆蟲、鱗介之屬，俱無他名。

又看到猴屬之類，原來這猴似人相，不入人名；似裸蟲，不居國界；似走獸，不伏麒麟管；似飛禽，不受鳳凰轄。

另有個簿子，悟空親自檢閱，直到那魂字一千三百五十號上，方注着孫悟空名字，乃天產石猴，該壽三百四十二歲，善終。

悟空道：「我也不記壽數幾何，且只消了名字便罷！取筆過來！」那判官慌忙捧筆，飽掭濃墨。悟空拿過簿子，把猴屬之類，但有名者，一概勾之！

閻王們只有硬 Copy，但是在硬 Copy 上更改，也會生效，所以應該是每天晚上跑 Batch 同步。

你看，原文有告訴你數據庫設計了，首先他是分類型的，我估計可能是按照比如生物學那種樹狀分類，所以我們可以認為，生死簿應該是樹狀的 NoSQL 存儲，或者實現了樹狀表，子表的 RMDB。

你仔細看，孫悟空屬於魂字1350 號，這個魂字，一定是 Namespace 了，然後是自增主鍵，主鍵上標有自然信息，名字，類型，年齡，所以，這個主鍵是記錄創建的時候給的，名字確定了，再補而已。

而且，你看孫悟空和其他猴子不在一個猴屬之中，更確定了生死薄是樹狀的存儲結構。

因為主鍵記錄上有死亡時間，看起來是每天晚上跑個 Batch，把當前時間-出生時間=死亡時間的數據篩選出來，送去執行部門幹掉。觸發器太麻煩，跑 Batch 拉個報表給黑白無常就可以了。

這個系統有問題，更新的 Batch 不看數據是否有篡改就直接更新，這說明數據安全性沒有考慮，我給地府推薦 OWASP 項目，用來提高安全性。

我曾和幾個架構師聊天聊到這個問題，大家覺得這個主意很有趣，發起了《我幫閻王設計表》主題活動，來鍛（qiong）煉（ji）設（wu）計（liao）能（xia）力（che）！

我匯總了下 ER 高層設計，如下圖：

主要來說，首先有一個字典表，規定了生物分類（CATE），考慮到每種分類的 UUID 類型應該不同。

比如孫悟空屬於的魂字，看上去東西就不多，很可能就是一個 int id，但是如果是蟲子類，東西可能太多，一個 long 都不一定能裝下，可能需要帶編碼的 vchar。

所以給每個 CATE ID 定義一種自增編碼方式，以兼容將來萬一出現機械人也要死，這樣地府的系統不需要重做。

給予每種 ID 一個表明後綴，這樣可以分表，不用把每種都放在同一個表裡。

對於 Transaction 表，每種屬性都有兩個表，一個是已死表，作為歷史數據備查；一個是存活表，這樣做到了讀寫分離，增強性能。

每天新增的生物，根據其自己的 UID 插入表，主鍵寫入速度有保證，這點上，考慮到地府不負責出生，我們提供一個 AMQP 高性能 Message Q 來給出生部門，可能是送子觀音來寫入，當然也可以提供 Restful API。

同時，每天晚上跑個 Batch，遍歷存活表，將死期是今天的數據篩選出來，放入 Dead 表，同時生成報表，交給索命部門，也就是黑白無常做實際殺死工作。

所以架構圖也出來了：

看到這裡，我不得不說，程序員們是真的皮….難道不怕被閻王喊去面向地獄編程？

真的有程序員做出了完整的地府後台管理系統

這不，前段時間，就有這麼一個段子火了。某位程序員日有所思，夜有所夢，終於有一天夢見自己見閻王爺了。閻王爺還叫他給生死簿做個後台管理系統。

還真有程序員把地府後台管理系統原型做出來了，目前這個項目已經在開發中…

Github圍觀地址為：

https://github.com/canxin0523/thesixsectorTeam  

小編看了下 Demo，功能相當齊全：

http://kzgfmo.axshare.cn  

用戶登錄：為了避免幾百年前被猴子刪庫這樣的悲劇再度重演，有編製的地府工作人員必須使用賬號密碼登錄才能訪問管理系統。

用戶權限：不同等級的員工，所擁有的權限也應該各不相同，各司其職。

數據看板：作為老闆，閻王每天要做的，就是喝喝茶、看看折線圖和數字就行了。

生死簿管理：這也是地府最重要的數據資產——地府職工需要依據生死簿的記載，依次進行勾魂、地獄刑罰、投胎輪迴等等業務流程。就算是被刪除的數據，也都會被記錄在案，以供隨時恢復。

勾魂管理：如果黑白無常和牛頭馬面勾錯了魂，也不是沒有挽救的機會。

審判記錄：被勾來的魂到地府報道後，第一件事就是到閻王殿報道接受審判。

十八層地獄：在設備管理一欄，可以看到各層地獄設備的運行狀態、損耗情況等等。

六道輪迴：輪迴投胎是大事，不能兒戲，本管理系統設計的輪迴盤既簡單又科學。

冥幣管理：無論身在何方，沒錢都是走不通的。那個啥有錢能使鬼推磨！

日誌管理：記錄所有管理員的操作日誌，對地府的工作人員進行績效考核，合理評估是否進行編製擴充以及獎金方案。

你如何看地府後台管理系統這個項目？歡迎底部留言討論。

出處：素材來自知乎問題《孫悟空無姓無名的時候，閻王生死簿是怎麼寫的呢？》及微信公眾號架構真經（ID：gentoo666）《地府系統 Demo》綜合整理。

本文轉載自：「51CTO技術棧」，原文：https://url.cn/5gS2y0E，版權歸原作者所有。歡迎投稿，投稿郵箱: [email protected] 。