這學(xué)期給自己挖了個(gè)坑：由于覺得應(yīng)該幫助學(xué)生了解分布式計(jì)算（現(xiàn)在的大數(shù)據(jù)是分布式計(jì)算在當(dāng)下的典型代表）轧葛，就在負(fù)責(zé)的操作系統(tǒng)中允諾梳理下所謂的 DOS （Distributed Operating System）的內(nèi)容。其中比較費(fèi)精力的就是梳理出計(jì)算機(jī)和操作系統(tǒng)的歷史演變：因?yàn)椴僮飨到y(tǒng)的核心功能就是管控資源（硬件資源自然是主要的部件臣嚣，此外也還有所謂的文件系統(tǒng)亭病、數(shù)據(jù)結(jié)構(gòu)等資源），那么，計(jì)算機(jī)變了，操作系統(tǒng)也就必須隨之改變锋华。
而之所以費(fèi)精力，就是因?yàn)槟切r(shí)間往往隱含在許許多多的網(wǎng)頁箭窜、書籍等資料中毯焕，而且有時(shí)候不同資料中記錄的時(shí)間信息也有沖突（有些體會到清末疑古派所做考據(jù)功夫的艱辛??）。
臨近期末绽快，好賴也就這樣了芥丧，也就有了下面的按照時(shí)間線梳理的相關(guān)事件的圖例紧阔。
*1: 之所以有 Communication一列坊罢，是為了突出它，因?yàn)榉植际较到y(tǒng)的基礎(chǔ)功能就是要支持遠(yuǎn)程進(jìn)程間的相互協(xié)同擅耽，Communication自然是其中的關(guān)鍵活孩；
*2: 查閱很多所謂的 分布式系統(tǒng)的視頻，其實(shí)大量探討的是 "分布式數(shù)據(jù)庫管理系統(tǒng)" 的專題乖仇，所以憾儒，在梳理過程中于 DOS 應(yīng)該包含哪些內(nèi)容就很困惑。后來乃沙，覺得還是以"支持程序的運(yùn)行"這一根本特征起趾，也所以分布式數(shù)據(jù)庫管理系統(tǒng)的內(nèi)容就剔除了出去，如 2PC (2 Phase Commit) 和 3PC (3 Phase Commit)
也有一些有趣的體悟：
當(dāng)下OS課程的專題警儒，可概括為 "在von Neumann 架構(gòu)(有限的資源 - 1個(gè)CPU和2個(gè)線性地址空間 [內(nèi)存和硬盤])的計(jì)算機(jī)上支持多個(gè)程序的并發(fā)運(yùn)行"训裆；類似的眶根，DOS的專題可概括為"在分布式系統(tǒng)或并行計(jì)算機(jī)上支持多個(gè)程序的并發(fā)運(yùn)行"
分布式環(huán)境下，操作系統(tǒng)的角色更多地對應(yīng)Local OS + Job Scheduler 的方式 - 對于 Local OS边琉，現(xiàn)在Linux 是主流 （從SuperComputer Top 500 中可窺一斑）属百；而 Job Scheduler，早期有 UNIX集群上的 PBS变姨，后來 Linux計(jì)算上的 LSF族扰、SLURM，以及面向大數(shù)據(jù)環(huán)境的 Borg定欧、K8S渔呵。國內(nèi)華為的 Donau算是混合集群的調(diào)度器。
-
在 "操作系統(tǒng)的角色更多地對應(yīng)Local OS + Job Scheduler 的方式" 的環(huán)境下忧额，分散的 CPUs厘肮、內(nèi)存和 分布式文件系統(tǒng)、分布式Naming睦番、分布式事務(wù)管理等类茂，也就只是起到了 被"Local OS + Job Scheduler"管控的"資源"
- 按照 Communication，TeleCommunication --> TCP/IP --> RPC (RMI等) --> 專門的 通信接口 (PVM和 MPI等) --> Middleware (CORBA, DCOM等) --> Web Service Middleware (Globus, SOA) --> Clouding
- 微內(nèi)核其實(shí)是失敗了的 - 不管是 Ameoba, MINIX, 還是Chorus托嚣。主要的原因是因?yàn)樾阅芴罟欤?UNIX 以及后來的 Linux很不錯(cuò)
- 而 Job 往往是 "MPI +" 的編程方式來實(shí)現(xiàn)的，如 "MPI + OpenMP"示启、"MPI + CUDA" 兢哭、"MPI + Deep Learning"等
-
保障集群節(jié)點(diǎn)的狀態(tài)一致，PAXOS 是繞不過去的協(xié)議夫嗓！由 Leslie Lamport 1989年以故事的形式撰文迟螺，但故事性太強(qiáng)不符合工科學(xué)者的思維，后來2003年"PAXOS made simple" 版本才妥協(xié)使用計(jì)算機(jī)術(shù)語來撰寫舍咖。
- 看資料矩父，有學(xué)者認(rèn)為：在 Consensus 問題上，方案就兩種排霉，一種是 PAXOS窍株，另一種是其他
- RAFT是 PAXOS的簡化版本，發(fā)表于2014年
- PAXOS 等和 2PC攻柠、3PC 雖有相似之處球订，但應(yīng)對的場景是不同的：后者的理解可以參考網(wǎng)上訂票 - 涉及出票系統(tǒng)和扣錢系統(tǒng)，它們要遵循"要么都完成瑰钮，要么啥也不能改變" 的事務(wù)的概念冒滩；而前者往往只用于狀態(tài)的記錄(也就多對應(yīng) "分散節(jié)點(diǎn)的日志要保障一致")
雖然相關(guān)概念和技術(shù)(計(jì)算機(jī)和操作系統(tǒng)) 的 "0-->1" 主要是國外完成的，但是浪谴，在"1 --> N" 的環(huán)節(jié)开睡，國人奮起趕上祈搜，如操作系統(tǒng)有 華為的 鴻蒙、歐拉士八，阿里的 龍蜥容燕；在大數(shù)據(jù)領(lǐng)域就更多了，Kylin婚度、OceanDB蘸秘、X-DB、TiDB蝗茁、ShardingSphere醋虏、RoketMQ等等
