[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"similar-dyweb--papers-notebook":3,"tool-dyweb--papers-notebook":65},[4,23,32,40,49,57],{"id":5,"name":6,"github_repo":7,"description_zh":8,"stars":9,"difficulty_score":10,"last_commit_at":11,"category_tags":12,"status":22},2268,"ML-For-Beginners","microsoft\u002FML-For-Beginners","ML-For-Beginners 是由微软推出的一套系统化机器学习入门课程，旨在帮助零基础用户轻松掌握经典机器学习知识。这套课程将学习路径规划为 12 周，包含 26 节精炼课程和 52 道配套测验，内容涵盖从基础概念到实际应用的完整流程，有效解决了初学者面对庞大知识体系时无从下手、缺乏结构化指导的痛点。\n\n无论是希望转型的开发者、需要补充算法背景的研究人员，还是对人工智能充满好奇的普通爱好者，都能从中受益。课程不仅提供了清晰的理论讲解，还强调动手实践，让用户在循序渐进中建立扎实的技能基础。其独特的亮点在于强大的多语言支持，通过自动化机制提供了包括简体中文在内的 50 多种语言版本，极大地降低了全球不同背景用户的学习门槛。此外，项目采用开源协作模式，社区活跃且内容持续更新，确保学习者能获取前沿且准确的技术资讯。如果你正寻找一条清晰、友好且专业的机器学习入门之路，ML-For-Beginners 将是理想的起点。",85267,2,"2026-04-18T11:00:28",[13,14,15,16,17,18,19,20,21],"图像","数据工具","视频","插件","Agent","其他","语言模型","开发框架","音频","ready",{"id":24,"name":25,"github_repo":26,"description_zh":27,"stars":28,"difficulty_score":29,"last_commit_at":30,"category_tags":31,"status":22},5784,"funNLP","fighting41love\u002FfunNLP","funNLP 是一个专为中文自然语言处理（NLP）打造的超级资源库，被誉为\"NLP 民工的乐园”。它并非单一的软件工具，而是一个汇集了海量开源项目、数据集、预训练模型和实用代码的综合性平台。\n\n面对中文 NLP 领域资源分散、入门门槛高以及特定场景数据匮乏的痛点，funNLP 提供了“一站式”解决方案。这里不仅涵盖了分词、命名实体识别、情感分析、文本摘要等基础任务的标准工具，还独特地收录了丰富的垂直领域资源，如法律、医疗、金融行业的专用词库与数据集，甚至包含古诗词生成、歌词创作等趣味应用。其核心亮点在于极高的全面性与实用性，从基础的字典词典到前沿的 BERT、GPT-2 模型代码，再到高质量的标注数据和竞赛方案，应有尽有。\n\n无论是刚刚踏入 NLP 领域的学生、需要快速验证想法的算法工程师，还是从事人工智能研究的学者，都能在这里找到急需的“武器弹药”。对于开发者而言，它能大幅减少寻找数据和复现模型的时间；对于研究者，它提供了丰富的基准测试资源和前沿技术参考。funNLP 以开放共享的精神，极大地降低了中文自然语言处理的开发与研究成本，是中文 AI 社区不可或缺的宝藏仓库。",79857,1,"2026-04-08T20:11:31",[19,14,18],{"id":33,"name":34,"github_repo":35,"description_zh":36,"stars":37,"difficulty_score":29,"last_commit_at":38,"category_tags":39,"status":22},5773,"cs-video-courses","Developer-Y\u002Fcs-video-courses","cs-video-courses 是一个精心整理的计算机科学视频课程清单，旨在为自学者提供系统化的学习路径。它汇集了全球知名高校（如加州大学伯克利分校、新南威尔士大学等）的完整课程录像，涵盖从编程基础、数据结构与算法，到操作系统、分布式系统、数据库等核心领域，并深入延伸至人工智能、机器学习、量子计算及区块链等前沿方向。\n\n面对网络上零散且质量参差不齐的教学资源，cs-video-courses 解决了学习者难以找到成体系、高难度大学级别课程的痛点。该项目严格筛选内容，仅收录真正的大学层级课程，排除了碎片化的简短教程或商业广告，确保用户能接触到严谨的学术内容。\n\n这份清单特别适合希望夯实计算机基础的开发者、需要补充特定领域知识的研究人员，以及渴望像在校生一样系统学习计算机科学的自学者。其独特的技术亮点在于分类极其详尽，不仅包含传统的软件工程与网络安全，还细分了生成式 AI、大语言模型、计算生物学等新兴学科，并直接链接至官方视频播放列表，让用户能一站式获取高质量的教育资源，免费享受世界顶尖大学的课堂体验。",79792,"2026-04-08T22:03:59",[18,13,14,20],{"id":41,"name":42,"github_repo":43,"description_zh":44,"stars":45,"difficulty_score":46,"last_commit_at":47,"category_tags":48,"status":22},3128,"ragflow","infiniflow\u002Fragflow","RAGFlow 是一款领先的开源检索增强生成（RAG）引擎，旨在为大语言模型构建更精准、可靠的上下文层。它巧妙地将前沿的 RAG 技术与智能体（Agent）能力相结合，不仅支持从各类文档中高效提取知识，还能让模型基于这些知识进行逻辑推理和任务执行。\n\n在大模型应用中，幻觉问题和知识滞后是常见痛点。RAGFlow 通过深度解析复杂文档结构（如表格、图表及混合排版），显著提升了信息检索的准确度，从而有效减少模型“胡编乱造”的现象，确保回答既有据可依又具备时效性。其内置的智能体机制更进一步，使系统不仅能回答问题，还能自主规划步骤解决复杂问题。\n\n这款工具特别适合开发者、企业技术团队以及 AI 研究人员使用。无论是希望快速搭建私有知识库问答系统，还是致力于探索大模型在垂直领域落地的创新者，都能从中受益。RAGFlow 提供了可视化的工作流编排界面和灵活的 API 接口，既降低了非算法背景用户的上手门槛，也满足了专业开发者对系统深度定制的需求。作为基于 Apache 2.0 协议开源的项目，它正成为连接通用大模型与行业专有知识之间的重要桥梁。",77062,3,"2026-04-04T04:44:48",[17,13,20,19,18],{"id":50,"name":51,"github_repo":52,"description_zh":53,"stars":54,"difficulty_score":46,"last_commit_at":55,"category_tags":56,"status":22},519,"PaddleOCR","PaddlePaddle\u002FPaddleOCR","PaddleOCR 是一款基于百度飞桨框架开发的高性能开源光学字符识别工具包。它的核心能力是将图片、PDF 等文档中的文字提取出来，转换成计算机可读取的结构化数据，让机器真正“看懂”图文内容。\n\n面对海量纸质或电子文档，PaddleOCR 解决了人工录入效率低、数字化成本高的问题。尤其在人工智能领域，它扮演着连接图像与大型语言模型（LLM）的桥梁角色，能将视觉信息直接转化为文本输入，助力智能问答、文档分析等应用场景落地。\n\nPaddleOCR 适合开发者、算法研究人员以及有文档自动化需求的普通用户。其技术优势十分明显：不仅支持全球 100 多种语言的识别，还能在 Windows、Linux、macOS 等多个系统上运行，并灵活适配 CPU、GPU、NPU 等各类硬件。作为一个轻量级且社区活跃的开源项目，PaddleOCR 既能满足快速集成的需求，也能支撑前沿的视觉语言研究，是处理文字识别任务的理想选择。",75916,"2026-04-19T10:54:02",[19,13,20,18],{"id":58,"name":59,"github_repo":60,"description_zh":61,"stars":62,"difficulty_score":29,"last_commit_at":63,"category_tags":64,"status":22},3215,"awesome-machine-learning","josephmisiti\u002Fawesome-machine-learning","awesome-machine-learning 是一份精心整理的机器学习资源清单，汇集了全球优秀的机器学习框架、库和软件工具。面对机器学习领域技术迭代快、资源分散且难以甄选的痛点，这份清单按编程语言（如 Python、C++、Go 等）和应用场景（如计算机视觉、自然语言处理、深度学习等）进行了系统化分类，帮助使用者快速定位高质量项目。\n\n它特别适合开发者、数据科学家及研究人员使用。无论是初学者寻找入门库，还是资深工程师对比不同语言的技术选型，都能从中获得极具价值的参考。此外，清单还延伸提供了免费书籍、在线课程、行业会议、技术博客及线下聚会等丰富资源，构建了从学习到实践的全链路支持体系。\n\n其独特亮点在于严格的维护标准：明确标记已停止维护或长期未更新的项目，确保推荐内容的时效性与可靠性。作为机器学习领域的“导航图”，awesome-machine-learning 以开源协作的方式持续更新，旨在降低技术探索门槛，让每一位从业者都能高效地站在巨人的肩膀上创新。",72149,"2026-04-03T21:50:24",[20,18],{"id":66,"github_repo":67,"name":68,"description_en":69,"description_zh":70,"ai_summary_zh":70,"readme_en":71,"readme_zh":72,"quickstart_zh":73,"use_case_zh":74,"hero_image_url":75,"owner_login":76,"owner_name":77,"owner_avatar_url":78,"owner_bio":79,"owner_company":80,"owner_location":80,"owner_email":80,"owner_twitter":80,"owner_website":81,"owner_url":82,"languages":80,"stars":83,"forks":84,"last_commit_at":85,"license":86,"difficulty_score":29,"env_os":87,"env_gpu":88,"env_ram":88,"env_deps":89,"category_tags":92,"github_topics":93,"view_count":10,"oss_zip_url":80,"oss_zip_packed_at":80,"status":22,"created_at":98,"updated_at":99,"faqs":100,"releases":139},9734,"dyweb\u002Fpapers-notebook","papers-notebook",":page_facing_up: :cn: :page_with_curl: 论文阅读笔记（分布式系统、虚拟化、机器学习）Papers Notebook (Distributed System, Virtualization, Machine Learning)","papers-notebook 是一个专注于计算机科学领域的论文阅读笔记仓库，主要涵盖分布式系统、虚拟化技术、机器学习及安全等前沿方向。该项目旨在解决科研人员和开发者在阅读海量学术文献时难以系统化梳理核心思想、实现细节及个人评价的痛点。作者将每篇论文的笔记精炼在千字以内，不仅记录了如 Mesos、Borg、Raft 等经典架构的设计思路，还包含了对技术演进的独到见解。\n\n不同于传统的静态文档维护方式，papers-notebook 创新性地利用 GitHub Issue 页面进行内容管理与社区互动，鼓励用户分享值得研读的论文并参与讨论。这种开放协作的模式让知识库得以持续更新和丰富。该工具特别适合计算机专业的研究生、高校研究人员以及从事底层系统开发的工程师使用，既能作为入门特定领域的学习路线图，也能作为资深从业者回顾经典算法与架构的速查手册。通过沉淀高质量的阅读思考，papers-notebook 帮助用户高效构建专业知识体系，激发新的研究灵感。","# 论文笔记\n\n这个 repo 希望能够记录自己阅读论文的过程，其中的论文一部分来自于在上海交通大学软件学院的研究生课上需要阅读的论文，这部分会比较偏安全和虚拟化。还有一部分论文是自己感兴趣，想去了解的，这部分可能比较偏虚拟化和分布式。论文笔记希望能够记录自己在读论文的时候的想法，其中包括但不限于论文的大致 idea，实现方式，以及自己对论文的评价等等。希望能够把每一篇论文的笔记限制在 1000 字以内。\n\n**目前不再以 Markdown 文件的方式维护，转到 [issue 页面](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002Fpapers-notebook\u002Fissues)进行，也欢迎到[这个 issue 中](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002Fpapers-notebook\u002Fissues\u002F1)分享您认为值得一读的 paper**\n\n## 目录(TOC)\n\n* [分布式(Distributed System)](#分布式distributed-system)\n    * [调度器(Scheduler)](#调度器scheduler)\n      * [Mesos](#mesos)\n      * [Omega](#omega)\n      * [Borg](#borg)\n      * [Yarn](#yarn)\n      * [Sparrow](#sparrow)\n      * [Apollo](#apollo)\n      * [Hawk](#hawk)\n      * [Mercury](#mercury)\n      * [Firmament](#firmament)\n      * [ERA](#era)\n      * [Efficient Queue Management for Cluster Scheduling](#efficient-queue-management-for-cluster-scheduling)\n      * [Tarcil](#tarcil)\n      * [Eagle](#eagle)\n      * [Canary](#canary)\n      * [Profiling a warehouse-scale computer](#profiling-a-warehouse-scale-computer)\n    * [Graph Computation](#graph-computation)\n      * [Wukong](#wukong)\n    * [Lock Service](#lock-service)\n      * [Chubby](#chubby)\n    * [一致性(Consensus)](#一致性consensus)\n      * [Raft](#raft)\n      * [Zookeeper](#zookeeper)\n      * [Paxos](#paxos)\n    * [存储(Storage)](#存储storage)\n      * [BigTable](#bigtable)\n      * [Dynamo](#dynamo)\n      * [Spanner](#spanner)\n      * [Distributed Transaction with RDMA and HTM](#distributed-transaction-with-rdma-and-htm)\n      * [Key-Value Store with RDMA](#key-value-store-with-rdma)\n      * [RDF Store with RDMA](#rdf-store-with-rdma)\n      * [Ambry](#ambry)\n* [虚拟化(Virtualization)](#虚拟化virtualization)\n    * [虚拟机管理器(Hypervisor)](#虚拟机管理器hypervisor)\n      * [Xen](#xen)\n      * [kvm](#kvm)\n    * [容器(Container)](#容器container)\n      * [mbox](#mbox)\n      * [Slacker](#slacker)\n* [沙箱(Sandboxing)](#沙箱sandboxing)\n    * [系统调用拦截(System Call Interposition)](#系统调用拦截system-call-interposition)\n      * [Janus](#janus)\n      * [Ostia](#ostia)\n    * [软件故障隔离(Software-based Fault Isolation)](#软件故障隔离software-based-fault-isolation)\n      * [SFI](#sfi)\n      * [Google Native Client](#google-native-client)\n      * [Language-Independent Sandboxing](#language-independent-sandboxing)\n* [系统(System)](#系统system)\n    * [文件系统(File System)](#文件系统file-system)\n      * [RAMCloud](#ramcloud)\n      * [Optimistic Crash Consistency](#optimistic-crash-consistency)\n      * [F2FS](#f2fs)\n      * [PMFS](#pmfs)\n    * [操作系统(Operating System)](#操作系统operating-system)\n      * [Exokernel](#exokernel)\n    * [Memory](#memory)\n      * [Transactional Memory](#transactional-memory)\n    * [CFI](#cfi)\n      * [Control-Flow Integrity](#control-flow-integrity)\n    * [Tail Latency](#tail-latency)\n      * [The Tail at Scale](#the-tail-at-scale)\n    * [Lock](#lock)\n      * [Non-scalable locks are dangerous](#non-scalable-locks-are-dangerous)\n    * [Bug](#bug)\n      * [STACK](#stack)\n* [安全(Security)](#安全security)\n    * [虚拟机安全(Virtulization, Security)](#虚拟机安全virtulization-security)\n      * [CloudVisor](#cloudvisor)\n    * [Taint Tracing](#taint-tracing)\n      * [TaintDroid](#taintdroid)\n    * [ROP](#rop)\n      * [Hacking Blind](#hacking-blind)\n* [大数据](#大数据)\n    * [框架](#框架)\n      * [Hadoop](#hadoop)\n      * [Spark](#spark)\n    * [Data Processing](#data-processing)\n      * [Realtime Data Processing at Facebook](#realtime-data-processing-at-facebook)\n* [网络](#网络)\n    * [Network Function Virtualization(NFV)](#network-function-virtualizationnfv)\n      * [Click](#click)\n\nCreated by [gh-md-toc](https:\u002F\u002Fgithub.com\u002Fekalinin\u002Fgithub-markdown-toc)\n\n\n## 分布式(Distributed System)\n\n### 调度器(Scheduler)\n\n* [Comparison of Container Schedulers](https:\u002F\u002Fmedium.com\u002F@ArmandGrillet\u002Fcomparison-of-container-schedulers-c427f4f7421)\n* [集群调度框架的架构演进之路](http:\u002F\u002Fwww.infoq.com\u002Fcn\u002Farticles\u002Fscheduler-architectures)\n\n在我看来，分布式是研究如何让程序能够在多台机器上运行拥有更好的性能的一个方向。那如果要实现这一点，调度很关键。\n\n目前我读过的与分布式调度器有关的论文有 Mesos, Omega, Yarn 和 Borg。这其中 Mesos 是最早的，它来自伯克利大学。其最亮的地方在于两层调度的框架，使得调度跟框架是松耦合的。目前很多公司都是在用它的，而且有很多基于 Mesos 的创业公司，比如 Mesosphere 等等。Omega 跟 Mesos 的第二作者是一个人。Omega 具体来说也不知道算是谁写的，应该算是大学和谷歌一起做的研究。Omega 发表在 EuroSys'13 上，是在基于 Mesos 的基础上，提出了一种完全并行的调度的解决方案，能够在调度上有更好的性能。不过论文是采取的模拟实验来进行验证的，不知道是否有生产上的使用。Borg 是发表在 EuroSys'15 上的，是谷歌真正一直在使用的集群管理工具。可以说谷歌为什么可以用廉价的机器来达到很高的可用性，有很大一部分是因为 Borg。Borg 和 Omega 是不开源的，而 Mesos 是开源的，不过 Borg 有一个开源的继任者，就是目前大名鼎鼎的 Kubernetes。Kubernetes 下面用 Docker Conatainer，而不是 Linux 内核的那些用来做进程级别的性能隔离的特性来实现的。不过最近 Kubernetes 似乎在跟 Docker 撕逼，因为 Docker 公司的一些强势吧，可能之后不会只支持 Docker Conatiner。Kubernetes 在很长的时间内都不是 production ready 的，只能支持 100 个节点，跟 Borg 的 10K 完全没法比，不知道现在是什么情况。\n\n#### Mesos\n\n* [Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center](https:\u002F\u002Fpeople.eecs.berkeley.edu\u002F~alig\u002Fpapers\u002Fmesos.pdf)\n* [Apache Mesos](https:\u002F\u002Fgithub.com\u002Fapache\u002Fmesos)\n\nMesos 是调度器绕不过去的一篇论文，因为它是目前在工业界应用最广泛的开源系统之一。Mesos 跟 exokernel 的思想很像，分离了管理和保护。之前所有的调度器，都是由自己来决定是否把资源给某个任务的，在 mesos 中是 framework 决定是否接受资源的要约。在容灾上，mesos 是通过 zookeeper 做 leader election 的，而且 master 维护的状态是 soft 的，因此 master 没有单点故障的问题，而对于 node 的故障，会反馈给 framework，让他们来处理。Mesos 就像是一个最小的 kernel，所有的决定都是『用户态』的 framework 来做的。\n\nMesos 是在 node 上给每一个 framework 运行一个 executor 的，使用 Linux Containers 等容器技术来做隔离。最后通过在一个集群上跑多个 framework 的方式来验证 mesos 的可用性。这篇文章整体来说比较简单，也可能是因为听过太多次关于 mesos 的架构了。\n\n#### Omega\n\n[Omega: flexible, scalable schedulers for large compute clusters](http:\u002F\u002Fweb.eecs.umich.edu\u002F~mosharaf\u002FReadings\u002FOmega.pdf)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n#### Borg\n\n[Large-scale cluster management at Google with Borg](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Fpubs\u002Farchive\u002F43438.pdf)\n\nBorg 是谷歌发表在 EuroSys'15 上的一篇文章，讲述了其内部是如何做集群管理的。Borg 是我看过的第一篇关于集群管理的论文。首先介绍下 Borg 的特点，Borg 是一个用来做集群管理的工具，它的目标就是让跑在它上面的应用能够拥有很好的可用性和可靠性的同时，能够提高机器的利用率，而且这些是在一个非常大规模的机器环境下。在 Borg 被设计的时候，还没有对虚拟化的硬件支持，也就是 Intel VT-x 等等那些硬件特性，所以 Borg 是使用了进程级别的隔离手段，也就是 Control Group。\n\nBorg 的架构其实还挺简单的，是比较经典的 Master\u002FSlave 架构，其中在 Master 部分，有两个抽象的进程，一个是 Borg Master，一个是 Borg Scheduler。Borg Master 是有5个备份的，每个都会在内存里维护集群里所有对象的状态。他们5个组成了一个小集群，用 Paxos 算法做一致性的，会选举出一个 leader 来处理请求，这点是之前 Kubernetes 做不到的。\n\n调度器方面的实现比较简单，就是一个队列，根据优先级做 round-robin。这里读起来感觉没什么新意，就不多说了。调度的平均时间大概是 25s，其中 80% 的时间在下载包。谷歌也是实诚，下载安装包的时间都算到调度里面去。\n\n谷歌写的论文一向是简单易懂，特别良心的。所以要是对集群感兴趣，可以去看下这篇论文，花两三个小时就能看完了。\n\n#### Yarn\n\n[Apache Hadoop YARN: Yet Another Resource Negotiator](https:\u002F\u002Fwww.sics.se\u002F~amir\u002Fid2221\u002Fpapers\u002F2013%20-%20Apache%20Hadoop%20YARN%20-%20Yet%20Another%20Resource%20Negotiator%20(SoCC).pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n#### Sparrow\n\n* [Sparrow: Distributed, Low Latency Scheduling](https:\u002F\u002Fpeople.eecs.berkeley.edu\u002F~keo\u002Fpublications\u002Fsosp13-final17.pdf)\n* [Sparrow in GitHub](https:\u002F\u002Fgithub.com\u002Fradlab\u002Fsparrow)\n\nSparrow 是一个与前面的调度器架构都不一样的实现，是去中心化的架构。之前的所有调度器，无论是 monolithic 的还是后面 Mesos 那样两层的架构，都是有一个中心化的调度器在运行，这样的方式会使得调度器的效率不是那么高。 Sparrow 是 AMPLab 的又一力作，发表在 SOSP'13 上，它不是一个 general-purpose 的调度器，而是针对 short job 这一特殊的 workload。其灵感来源于一个负载均衡方面的经典论文，k choices。这篇文章的 idea 是，在 k 台机器里选一个最好的，而不是在 n 里选一个最好的，可以大大降低负载均衡的 overhead，同时也对负载的分配跟最优解差不了多少。\n\nSparrow 核心的思想就是，在分配 task 的时候，随机选择几个 worker，然后选一个最合适的。因为在 Sparrow 的应用场景里，所有的 task 都是很短的，因此只需要考虑任务队列的长度就差不多了。针对多 task 的分配问题，Sparrow 对其进行了批处理来优化，比如 task 为 2 的时候，不是进行两次选择，每次在 k 个 worker 里选择 1 个，而是在 2k 个 worker 里选择 2 个。\n\n这篇论文读起来很轻松，idea 比较简单，但是是跟之前完全不一样的思路。讲道理，其实 idea 很容易想，在读 k choices 的时候就想这样的思想能不能用在调度器上，结果人家早就想到了。\n\n目前 Sparrow 开源在 GitHub 上，但是没听说哪个公司在把它用在生产系统上。它的最大的问题就是 workload 比较单一，只能对 short job 有比较好的效果。\n\n#### Apollo\n\n* [Apollo: Scalable and Coordinated Scheduling for Cloud-Scale Computing](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fosdi14\u002Fosdi14-paper-boutin_0.pdf)\n* [Slides in USENIX](https:\u002F\u002Fwww.usenix.org\u002Fsites\u002Fdefault\u002Ffiles\u002Fconference\u002Fprotected-files\u002Fosdi14_slides_boutin.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n#### Hawk\n\n* [Hawk: Hybrid Datacenter Scheduling](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fatc15\u002Fatc15-paper-delgado.pdf)\n* [Slides in USENIX ATC 2015](https:\u002F\u002Fproject.inria.fr\u002Fepfl-Inria\u002Ffiles\u002F2016\u002F02\u002Ftalk-pameladelgado.pdf)\n\n有一种寻找 idea 的方法，就是在已有的两种极端的思想中做一个你中有我，我中有你的取舍，所有计算机的问题，都是 trade off 嘛，两种极端肯定是为了不同的追求，然后提出一个折中的方案，往往是一种取巧的想 idea 的方式。类似的例子有 monolithic kernel，micro kernel 和 hybrid kernel。这篇文章也是这样，它是把去中心化和中心化的调度器做了一个混合。之前提到，去中心化的实现只适合 short job 的 workload，Hawk 在调度 long job 的时候会使用中心化的调度器，在调度 short job 的时候会使用去中心化的调度器。\n\n除此之外，Hawk 为了两者能够更好地在一起工作还做了一些微小的工作，比如在一个 worker 做完所有的事情后，会偷别的 worker 的 short job 来做，果然资本主义的 worker 都是积极进取的。\n\n哦对了，这篇文章的验证是使用谷歌开放的自己的 tracing 数据集来做的，这个数据集也是开源的，在 [https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcluster-data](https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcluster-data) 可以找到。\n\n#### Mercury\n\n* [Mercury: Hybrid Centralized and Distributed Scheduling in Large Shared Clusters\n](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fatc15\u002Fatc15-paper-karanasos.pdf)\n* [Slides in USENIX ATC 2015](https:\u002F\u002Fwww.usenix.org\u002Fsites\u002Fdefault\u002Ffiles\u002Fconference\u002Fprotected-files\u002Fatc15_slides_karanasos.pdf)\n\nMercury 跟 Hawk 是约等于一模一样的 idea，都是总结了中心化的调度器和去中心化各自的优缺点后，提出了一种 hybrid 的方法。Mercury 是由微软提出的，PPT 做的更好看一些。它在 YARN 上进行了一个实现，Hawk 则是实现在了 Spark 上。说明论文还是有实现有实验才行。\n\n#### Firmament\n\n* [Firmament: Fast, Centralized Cluster Scheduling at Scale](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fosdi16\u002Fosdi16-gog.pdf)\n* [https:\u002F\u002Fgithub.com\u002Fcamsas\u002Ffirmament](https:\u002F\u002Fgithub.com\u002Fcamsas\u002Ffirmament)\n* [Firmament in Kubernetes](https:\u002F\u002Fgithub.com\u002Fcamsas\u002Fposeidon)\n\n这是一篇基于最大流最小割的中心化调度的论文，本文是借鉴了 Quincy 的研究，但是在解最大流最小割的时候，做了一些问题特定的优化，解决了 Quincy 不能解决的效率问题。并且 Firmament 会并行地运行两个 MCMF 的算法，来加快其中的过程。它有在 Kubernetes 上的实现。\n\n#### ERA\n\n* [ERA: A Framework for Economic Resource Allocation for the Cloud](https:\u002F\u002Farxiv.org\u002Fpdf\u002F1702.07311.pdf)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n#### Efficient Queue Management for Cluster Scheduling\n\n* [Efficient Queue Management for Cluster Scheduling](http:\u002F\u002Fdl.acm.org\u002Fcitation.cfm?doid=2901318.2901354)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n#### Tarcil\n\n* [Tarcil: Reconciling Scheduling Speed and Quality in Large Shared Clusters](http:\u002F\u002Fweb.stanford.edu\u002F~cdel\u002F2015.socc.tarcil.pdf)\n* [Tarcil: High Quality and Low Latency Scheduling in Large, Shared Clusters](https:\u002F\u002Fweb.stanford.edu\u002Fgroup\u002Fmast\u002Fcgi-bin\u002Fdrupal\u002Fsystem\u002Ffiles\u002F2014.techreport.tarcil_0.pdf)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n#### Eagle\n\n* [Eagle: A Better Hybrid Data Center Scheduler](https:\u002F\u002Fpdfs.semanticscholar.org\u002F36b3\u002F3a2e5ee77e6b191aa8bfaf4a5aac450d1b57.pdf)\n* [Job-aware Scheduling in Eagle: Divide and Stick to Your Probes](https:\u002F\u002Finfoscience.epfl.ch\u002Frecord\u002F221125\u002Ffiles\u002Fsocc2016-final189.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n#### Canary\n\n* [Canary: A Scheduling Architecture for High Performance Cloud Computing](http:\u002F\u002Fhci.stanford.edu\u002Fcstr\u002Freports\u002F2016-01.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n#### Profiling a warehouse-scale computer\n\n* [Profiling a warehouse-scale computer](http:\u002F\u002Fdelivery.acm.org\u002F10.1145\u002F2760000\u002F2750392\u002Fp158-kanev.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n### Graph Computation\n\n#### Wukong\n\n[Fast and Concurrent RDF Queries with RDMA-based Distributed Graph Exploration](http:\u002F\u002Fipads.se.sjtu.edu.cn\u002Flib\u002Fexe\u002Ffetch.php?media=publications:wukong-osdi16.pdf)\n\nWukong 是去中心化的设计，server 可以独立处理请求，每个 server 有两部分，一部分是 query engine，另一部分是 store。\n\nWukong 一共有两种 index，Type 和 Predicate。\n\n> What are the bottlenecks of existing RDF systems?\n\n一共有两种不同的实现，分别是 Triple store and triple join 和 Graph store and graph exploration。前者是以 triple 的方式来将 RDF 数据存储在关系型数据库中，因此查询有两个步骤，scan 和 join。scan 会分为子查询，最后再借由 hash join 之类的 join 的操作将查询的结果 join 在一起。由此可知如果数据非常大的时候，最后的 join 会是很大的问题。\n\n第二种方式是以图的方式来存储和查询 RDF。这样的方式以 Trinity.RDF 为代表，有一些剪枝的优化。但是最后也会有一个 final join 的过程。\n\n纵观之前的实现，最后的 join 是一个最大的问题。\n\n> What are the differences between Wukong and prior graph-based designs? What are the benefits?\n\n最大的不同在于索引的存储方式。之前的基于图的设计都是用独立的索引数据结构来存索引，但是 Wukong 是把索引同样当做基本的数据结构（点和边）来存储。并且会考虑分区来存储这些索引。\n\n这样做有两个好处，第一点就是在进行图上的遍历或者搜索的时候可以直接从索引的节点开始，不用做额外的操作。第二点是这样使得索引的分布式存储变得非常简单，复用了正常的数据的存储方式。\n\n> What is full-history pruning and what's the difference compared with the prior pruning approach? Why can Wukong adopt full-history pruning?\n\nFull-history 就是说所有的历史记录都会被记录下来。之前是只记录一次的。之所以可以这样做是因为一方面 RDF 的查询都不会有太多步，而且 RDMA 在低于 2K bytes 的时候性能都是差不多的，所以 Wukong 可以这样做。\n\n### Lock Service\n\n#### Chubby\n\n[The Chubby lock service for loosely-coupled distributed systems](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Farchive\u002Fchubby-osdi06.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n### 一致性(Consensus)\n\n#### Raft\n\n* [In Search of an Understandable Consensus Algorithm(Extended Version)](https:\u002F\u002Fraft.github.io\u002Fraft.pdf)\n* [Slides](https:\u002F\u002Fspeakerdeck.com\u002Fbenbjohnson\u002Fraft-the-understandable-distributed-consensus-protocol)\n\n这篇论文是公认的好读，好实现，但是也只是相对于 Paxos 来说的。本身还是具有一定的背景才能读懂的。因为暂时还没正式读过 Paxos，所以不好作比较。但是 Raft 是利用了 State Machine 的思想，将分布式一致性问题分成 Leader 选举和日志同步两个问题，这样的做法很简单粗暴。\n\n我觉得能理解 Raft 是不难的，但是明白听他的正确性是如何保证的才比较难。越是简洁的东西背后的数学证明应该越复杂，并没有了解过。\n\n#### Zookeeper\n\n[ZooKeeper: Wait-free coordination for Internet-scale systems](http:\u002F\u002Fstatic.cs.brown.edu\u002Fcourses\u002Fcsci2270\u002Farchives\u002F2012\u002Fpapers\u002Freplication\u002Fhunt.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n#### Paxos\n\n* [The Byzantine Generals Problem](http:\u002F\u002Fwww.cs.cmu.edu\u002F~15712\u002Fpapers\u002Flamport82.pdf)\n* [The Part-Time Parliament](http:\u002F\u002Fresearch.microsoft.com\u002Fen-us\u002Fum\u002Fpeople\u002Flamport\u002Fpubs\u002Flamport-paxos.pdf)\n* [Revisiting the Paxos Algorithm](http:\u002F\u002Fresearch.microsoft.com\u002Fen-us\u002Fum\u002Fpeople\u002Fblampson\u002F60-PaxosAlgorithm\u002FAcrobat.pdf)\n* [Paxos Made Simple](http:\u002F\u002Fresearch.microsoft.com\u002Fen-us\u002Fum\u002Fpeople\u002Flamport\u002Fpubs\u002Fpaxos-simple.pdf)\n* [Paxos Made Live - An Engineering Perspective](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Farchive\u002Fpaxos_made_live.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n### 存储(Storage)\n\n#### BigTable\n\n[Bigtable: A Distributed Storage System for Structured Data](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fen\u002F\u002Farchive\u002Fbigtable-osdi06.pdf)\n\n> What is the relationship between table , tablet and sstable?\n\nTable 就是用户可见的表，它有 Row，Column，和不同 Version 的 Value。Table 会从逻辑上划分为多个 Tablet 以方便存储。\n\nTablet 是一个存储单元。在 BigTable 的架构中，是由一个 Master Server 和多个 Tablet Server 组成的。而 Tablet 这一层抽象有些类似传统数据库概念中的 sharding，跟在 HBase 中的 Region 是差不多的思想。Tablet 的读写是由 Tablet Server 来处理的。\n\nSSTable 是一种文件的格式，全称是 \"Sorted Strings Table\"，是指按照 Key 的排序在文件中存储 \u003CKey, Value> 对。在逻辑上 SSTable 会包含多个 Block，每个 Block 为了方便寻址会有一个 index，所有的 Block index 会写在 SSTable 文件的最后，每当 SSTable 文件被 open 的时候，会将索引加载到内存里，这样每次 Lookup 的时候只有一次硬盘读取。SSTable 也支持全部读取到内存里，这样在 Lookup 的时候没有任何硬盘的读取。这个跟 HBase 中 HFile 的文件格式实现很相似。\n\n> Describe what will happen when a read operation or write operation arrives.\n\n读取和写入是以 Tablet 作为一个 Unit 进行的。\n\n在进行写操作的时候，Tablet Server 会先做一些检查，保证请求的合法以及权限问题。权限的检查是通过检查一个在 Chubby 中的列表进行的，这个列表会被 Client Library 缓存住。一次被允许的写操作会先进入 Commit Log，在处理 Log 的时候采取了批处理来提高吞吐。在操作被 Commit 后，它的内容会被插入 MemTable 里，当 MemTable 的 size 超过一个阈值的时候，会让当前的 MemTable 进入一个 frozen 的状态，随后创建一个新的 MemTable，Frozen 的 MemTable 就可以以 SSTable 的形式写入 GFS。\n\n在进行读操作的时候，Tablet Server 会在做了一些检查保证合法后，在 MemTable 和 SSTable 的一个 merge 后的 view 中来进行读操作，这样可以保证可以读到最新的值。\n\n> Describe which applications are BigTable suitable for and not suitable for.\n\nBitTable 适合那些对可用性要求比较高的业务场景，同时对于跨行的事务性没有要求的应用。但是正因为没有跨行事务的支持，所以我觉得引用场景很局限。目前在谷歌内部应该也逐渐被 Spanner 和 F1 所取代吧。\n\n#### Dynamo\n\n[Dynamo: Amazon’s Highly Available Key-value Store](http:\u002F\u002Fs3.amazonaws.com\u002FAllThingsDistributed\u002Fsosp\u002Famazon-dynamo-sosp2007.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n#### Spanner\n\n[Spanner: Google’s Globally-Distributed Database](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Farchive\u002Fspanner-osdi2012.pdf)\n\n> What is external consistency? What’s the difference between external consistency and serializability?\n\nExternal consistency 在文中的描述是：如果事务 2 发生在事务 1 提交之后，那事务 2 的时间戳要比事务 1 提交的时间戳要大，也就是 linearizability。\n\nSerializability 是数据库隔离性上的一个级别，这意味着数据库中所有的事务都是可以被序列化来执行的，只有完全没有冲突的事务才可以并发地执行。\n\nExternal consistency 是一致性上的概念，在分布式场景下，external consistency 是更难做到的，因为时序对时间的精度要求很高，在分布式场景下，有可能出现因为不同机器系统时间不一致导致事务 2 拿到一个比事务 1 提交的时间戳更小的时间戳。\n\nSerializability 是隔离性上的概念，如果做到了 external consistency，就一定可以做到 serializability。\n\n> How does Spanner achieve the external consistency?\n\nSpanner 之前的 Percolator 和 Spanner 都是使用全局的时钟来解决 external consistency 的。但是 Spanner 创新地使用了原子钟和 GPS 来作为全局的时钟，以此来实现 external consistency。\n\n在事务的执行中，Spanner 会保证，每个事务的 commit timestamp 都会在其 start 和 commit 之间。Spanner 依赖的底层容器集群系统 Borg 会维护一个 True Time API，这个 API 会返回精度为 ε 的时间区间 `[t - ε, t + ε]`。因此每个事务会在 start 和 commit 的时候分别调用一次 True Time API，拿到两个时间区间 `[t1 - ε,t1 + ε]` 和 `[t2 - ε,t2 + ε]`，因此在区间 `[t1 + ε,t2 - ε]` 之间的时间都是可用的，如果 t1 和 t2 很接近，那最多需要等 2ε。\n\n> What will happen if the TrueTime assumption is violated? How the authors argue that TrueTime assumption should be correct?\n\n这会导致 True Time API 不能再用来保证 external consistency，文章中提到，CPU 造成的问题比时钟问题多六倍，因此跟硬件造成的错误相比，时钟造成的问题不值一提，可以被视为是值得信任的。\n\n#### Distributed Transaction with RDMA and HTM\n\n[Fast In-memory Transaction Processing using RDMA and HTM, Xingda Wei, Jiaxin Shi, Yanzhe Chen, Rong Chen, Haibo Chen SOSP 2015](https:\u002F\u002Fpdfs.semanticscholar.org\u002F408b\u002F8d34b7467c0b25b27fdafa77ee241ce7f4c4.pdf)\n\n>How does DrTM detect conflicts between remote reads and local writes?\n\n在检测事务的冲突上，DrTM 使用了 HTM 和 RDMA 两种技术，HTM 是一个硬件的特性，在硬件级别提供了有限的事务性内存的支持。RDMA 是 Remote Direct Memory Access，提供了远程直接访问内存，不阻塞 CPU 的操作。\n\n在处理事务冲突时，是在 transaction layer 去做的。对于远程的读和本地的写操作引起的冲突，最简单的方法是用 RMDA 锁住一个 remote record，不管是读还是写。但是这样会大大降低并行性，因此文章进行了一些改进，引入了基于租约的锁，来保证读共享。而在读和本地写产生冲突时，读会通过 RDMA abort 本地的 HTM 事务，从而避免冲突。\n\n> Why DrTM has the deadlock issue and how does it avoid the deadlock?\n\n首先，在 DrTM 的 fallback handler 中，不能像传统的实现那样，一个简单的锁就可以解决问题，而是 fallback handler 通过 2PL，对于任何 record 都是以 remote 的形式进行访问。这里就有可能产生死锁。因为涉及到 remote locks 的顺序。\n\n为了避免这个问题，DrTM 声明了一个全局的释放和申请锁的顺序，避免了死锁的问题。\n\n> What’s the limitation of DrTM?\n\n首先，DrTM 没有做到很好的可用性，这是它最大的局限性。还有就是需要硬件特性的支持，导致在很多现有的硬件上没有办法完全复刻 DrTM 的工作，而需要一些适配性的工作。\n\n#### Key-Value Store with RDMA\n\n[Using One-Sided RDMA Reads to Build a Fast, CPU-Efficient Key-Value Store, Christopher Mitchell, Yifeng Geng, Jinyang Li USENIX ATC 2013](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fatc13\u002Fatc13-mitchell.pdf)\n\n> What makes in-memory key-value store systems suitable for RDMA optimization?\n\n因为 In Memory 的 Key-value Store 的大多数请求都是读操作，因此对于 RDMA 来说，这样的特点使得其实现比较简单，只需要对 get 请求做修改就可以了，这样既可以利用 RDMA 的优点，又不需要对系统做过多的修改。\n\n> How does Pilaf ensure the data consistency of 'get' operations? Does it have any problems?\n\n利用了一个『Self verifying』的数据结构，它包括一个 root 和很多 pointer，然后会记录一个 checksum。client 通过检查 checksum 可以检测到读写不一致。当遇到了数据竞争时，client 会自动地进行重试操作。\n\n文中提到有两个应用场景会有问题，一个是在 server 修改 hash table 的时候 client 也在读 hash table，这会导致 client 从不合法的内存地址读取内容。\n\n另外是 client 的指针引用可能非法的。比如当 server 在删除一个 key-value 对的时候，client 自身维护的引用就会已经是失效的。\n\n> Why does Pilaf need two round-trips to perform a 'get' operation? Can we reduce the number of round-trips to one using existing RDMA operations? Why\u002FHow?\n\n因为涉及到两次读操作，一次是读哈希表，一次是读真正的 key-value 的内容。可以考虑合并两个内存块，但是这样应该会使得可以存储的空间变小。\n\n#### RDF Store with RDMA\n\n[Fast and Concurrent RDF Queries with RDMA-based Distributed Graph Exploration, Jiaxin Shi, Youyang Yao, Rong Chen, Haibo Chen, Feifei Li OSDI 2016](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fosdi16\u002Fosdi16-shi.pdf)\n\n> What are the bottlenecks of existing RDF systems?\n\n一共有两种不同的实现，分别是 Triple store and triple join 和 Graph store and graph exploration。前者是以 triple 的方式来将 RDF 数据存储在关系型数据库中，因此查询有两个步骤，scan 和 join。scan 会分为子查询，最后再借由 hash join 之类的 join 的操作将查询的结果 join 在一起。由此可知如果数据非常大的时候，最后的 join 会是很大的问题。\n\n第二种方式是以图的方式来存储和查询 RDF。这样的方式以 Trinity.RDF 为代表，有一些剪枝的优化。但是最后也会有一个 final join 的过程。\n\n纵观之前的实现，最后的 join 是一个最大的问题。\n\n> What are the differences between Wukong and prior graph-based designs? What are the benefits?\n\n最大的不同在于索引的存储方式。之前的基于图的设计都是用独立的索引数据结构来存索引，但是 Wukong 是把索引同样当做基本的数据结构（点和边）来存储。并且会考虑分区来存储这些索引。\n\n这样做有两个好处，第一点就是在进行图上的遍历或者搜索的时候可以直接从索引的节点开始，不用做额外的操作。第二点是这样使得索引的分布式存储变得非常简单，复用了正常的数据的存储方式。\n\n> What is full-history pruning and what's the difference compared with the prior pruning approach? Why can Wukong adopt full-history pruning?\n\nFull-history 就是说所有的历史记录都会被记录下来。之前是只记录一次的。之所以可以这样做是因为一方面 RDF 的查询都不会有太多步，而且 RDMA 在低于 2K bytes 的时候性能都是差不多的，所以 Wukong 可以这样做。\n\n#### Ambry\n\n* [Ambry: LinkedIn’s Scalable Geo-Distributed Object Store](http:\u002F\u002Fdprg.cs.uiuc.edu\u002Fdocs\u002FSIGMOD2016-a\u002Fambry.pdf)\n* [LinkedIn 开源其分布式对象存储系统 Ambry](http:\u002F\u002Fwww.infoq.com\u002Fcn\u002Fnews\u002F2016\u002F06\u002FLinkedIn-Ambry)\n* [Slides by me](https:\u002F\u002Fdocs.google.com\u002Fpresentation\u002Fd\u002F1o1lkn_QmsDvnHfETHmPUgb-nG3hoRXiXqtn09jAV1XI\u002Fedit?usp=sharing)\n\nAmbry 是一个针对 Media 的分布式对象存储系统，是 LinkedIn 做的一项工作。LinkedIn 作为一个社交产品，会有很多媒体数据需要处理，在之前是采取了文件系统存数据，Oracle 存元数据的方法。随着规模的扩大发现不行，于是就有了这个系统。\n\nAmbry 是一个比较中规中矩的分布式系统，比较让人印象深刻的只有一些 threshold。因为社交数据有一个特性：越是冷的数据会越冷，因此 Ambry 针对这个观察做了一些优化，同时在负载均衡上用了 threshold + round-robin 的方式，很 simple 但是效果不错。除此之外在数据存储上有分层的概念在里面，索引是逐层进行的。最上面是 bloom filter，然后是顺序的 segment，最下面是 partition 里真实的数据。\n\n文章很简单，算是很多工程上的点拼在了一起写的论文，有点像最近读的 F2FS，此外 Ambry 感觉也参考了很多文件系统的设计，有一些共性在里面。比如 log structured update 和 journal 等等。\n\n## 虚拟化(Virtualization)\n\n### 虚拟机管理器(Hypervisor)\n\n#### Xen\n\n* [Xen and the Art of Virtualization](http:\u002F\u002Fwww.cl.cam.ac.uk\u002Fresearch\u002Fsrg\u002Fnetos\u002Fpapers\u002F2003-xensosp.pdf)\n* [CSP 课堂笔记之 Hypervisor](http:\u002F\u002Fgaocegege.com\u002FBlog\u002Fcsp\u002Fxen-kvm)\n\nXen 是非常著名的 Hypervisor，它提出了 para-virtualization 的想法。之前实现虚拟机，都是通过 full-virtualization 的方式，但是那个时候的 X86 其实并不能很好地支持 full-virtualization。举个例子，有些指令原本是应该在 VMM 中被执行的，但是有时会因为指令在不同 ring 有不同的表现，因此并不能成功地 trap 到 VMM 中。为了更加优雅地解决这样的问题，Xen 引入了 hypercall，修改了 Guest 的 OS。通过另外的方式来解决这个问题。\n\n虚拟化最主要的资源是 CPU，Memory 和 IO，Xen 对于三者都有一些比较有趣的地方。其中我觉得最有趣的是对于设备的支持，引入了 Domain 0，前后端驱动的设计让人觉得很自然，而且也避免了把驱动放在 VMM 里，会因为驱动 bug 把 VMM 弄崩的可能。\n\n#### kvm\n\n* [kvm: the Linux Virtual Machine Monitor](https:\u002F\u002Fwww.kernel.org\u002Fdoc\u002Fols\u002F2007\u002Fols2007v1-pages-225-230.pdf)\n* [CSP 课堂笔记之 Hypervisor](http:\u002F\u002Fgaocegege.com\u002FBlog\u002Fcsp\u002Fxen-kvm)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n### 容器(Container)\n\n#### mbox\n\n* [Practical and effective sandboxing for non-root users](https:\u002F\u002Fpeople.csail.mit.edu\u002Fnickolai\u002Fpapers\u002Fkim-mbox.pdf)\n* [Open source in GitHub](https:\u002F\u002Fgithub.com\u002Ftsgates\u002Fmbox)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n#### Slacker\n\n* [Slacker: Fast Distribution with Lazy Docker Containers](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Ffast16\u002Ffast16-papers-harter.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n## 沙箱(Sandboxing)\n\n[Sandboxing in Linux: From Smartphone to Cloud](http:\u002F\u002Fwww.ijcaonline.org\u002Farchives\u002Fvolume148\u002Fnumber8\u002Fborate-2016-ijca-911256.pdf)\n\n沙箱跟容器其实是有点血缘关系的，要做容器肯定要实现隔离，而沙箱就是专门做隔离的。之所以把他们两个分开介绍是因为沙箱本身是一个很复杂的方向，有很多的种类，而容器只是使用了沙箱技术中的某几种。\n\n沙箱技术大致可以被分为两类，其中第一类是基于隔离的沙箱，该类型的沙箱将应用的执行环境从操作系统中隔离出来，形成一个独立的执行环境。第二类是基于规则的沙箱，该类型的沙箱并不是完全关注于对于应用程序的隔离上，而是用规则的方式控制每个应用的权限，基于规则的沙箱之间可以分享操作系统的逻辑资源。\n\n我读的论文主要都是第一类的沙箱，其中主要的技术是 capabilities, system call interposition, software-based fault isolation 等。\n\n上面的链接是一个综述性质的文章，主要阐述了 Linux 平台上可以用来实现沙箱的内核 feature。它对沙箱的定义和功能介绍的比较简单易懂，不妨一读。\n\n###  系统调用拦截(System Call Interposition)\n\nSystem Call Interposition，顾名思义，就是拦截和过滤系统调用的技术。在沙箱的实现过程中，系统调用是一个很关键的部分。如何能够保证应用只能进行被授权的系统调用，是这个方向的研究做的事情。\n\n#### Janus\n\n* [A Secure Environment for Untrusted Helper Applications(Confining the Wily Hacker)](https:\u002F\u002Fwww.usenix.org\u002Flegacy\u002Fpublications\u002Flibrary\u002Fproceedings\u002Fsec96\u002Ffull_papers\u002Fgoldberg\u002Fgoldberg.pdf)\n* [Janus: an Approach for Confinement of Untrusted Applications](http:\u002F\u002Fwww2.eecs.berkeley.edu\u002FPubs\u002FTechRpts\u002F1999\u002FCSD-99-1056.pdf)\n* [Traps and Pitfalls: Practical Problems in System Call Interposition Based Security Tools](http:\u002F\u002Fwww.isoc.org\u002Fisoc\u002Fconferences\u002Fndss\u002F03\u002Fproceedings\u002Fpapers\u002F11.pdf)\n\n链接中的第一篇论文是 1996 年发表的，是 system call interposition 方向上最经典的论文，它提出了一个系统，Janus。这个工具可以根据用户定义的 policy 来对应用的请求调用进行过滤，后面的两篇都是后续的关于 Janus 的论文。\n\n在那个时候，互联网很流行，在互联网上获得的内容，可以直接用本地的 helper application 打开。因为内容本身是不可信的，所以这样的一种模式连带着 helper application 也是不可信的，因此 Janus 希望对这样的应用进行限制和隔离，使得应用具有最小的特权，当其被恶意程序攻击后，不会影响整个操作系统。\n\nJanus 的目标有三点，第一个是安全不多说，第二个是灵活，就是要求对系统调用的限制可以达到参数级别，比如 open 在某些参数时可以被调用，其他就不可以，还有就是可配置，允许为不同应用配置不同的策略。\n\n它的实现比较简单，是借助了内核中的 ptrace，然后实现了一个 kernel module 以及一个用户态的 engine。在开始的时候，Janus 会先读取 policy 文件，然后会 fork 子进程，然后父进程会 select 关于子进程的各种事件。子进程会执行 helper app 的逻辑，当有了一个系统调用，会先给 Janus 的内核模块处理，内核模块会跟用户态的 engine 交互，确定请求是不是合法的，合法会交由内核去处理，否则会 deny 掉请求。\n\n下面的两篇论文中提到了一些关于 Janus 的缺点，包括 ptrace 和 Janus 本身的缺点，主要是涉及一些 system call 的监控问题，以及 deny 的方式问题，就不再说了，已经很长了。\n\n#### Ostia\n\n[Ostia: A Delegating Architecture for Secure System Call Interposition](http:\u002F\u002Fbenpfaff.org\u002Fpapers\u002Fostia.pdf)\n\nOstia 是在 Janus 等等那一溜论文后面发表的，因此引用了 Janus 中提到的那三篇论文。它最大的贡献，在于提出了一种新的架构，然后解决了之前的基于 filter 的架构不能解决的问题。\n\n它跟 Janus 其实是一挂的工具，都是要在内核态修改一些东西来做的。但是两者的不同在于实现的架构，Janus 是在内核中要有一个负责 tracing 的模块，比如 ptrace。然后在用户态有一个 policy engine，两者会交互，其中是否 deny 请求的逻辑在 policy engine 中，而内核中的模块主要是做 process monitor 的。\n\nOstia 的实现在我看来参考了虚拟化的一些思想，当一个系统调用到内核的时候，会回调在调用者用户态内存空间中的一个 handler，然后会转发给 agent，然后 agent 会负责校验权限和访问。具体的实现还在看。\n\n### 软件故障隔离(Software-based Fault Isolation)\n\n#### SFI\n\n[Efficient Software-Based Fault Isolation](https:\u002F\u002Fcrypto.stanford.edu\u002Fcs155\u002Fpapers\u002Fsfi.pdf)\n\n这篇文章是在 1993 年发表的，也正是这篇文章最早提出了 \"sandboxing\" 一词。这篇文章主要是介绍了用软件方式来实现隔离的方法。传统的隔离是在操作系统这一层来做的，以前进程之间可以通过 RPC 的方式进行，而隔离是通过虚拟内存来实现的。但是这样做的 overhead 特别大，因此这篇文章想实现在同一内存空间内的错误隔离。SFI 的实现，使用了处理器的段寄存器。段寄存器最初是为了解决 Intel 8086 处理器体系架构中数据总线与地址总线的宽度不一致而引入的，因为不一致导致寻址不能在单个指令周期内完成，因此 Intel 引入了段寄存器，将整个内存空间分为了4个段，段寄存器存放每个段的前 N 位的地址，使用段内偏移量，而不是全部的物理地址来描述内存地址，解决了这一问题。在目前处理器的架构中，不再存在地址宽度不统一的问题，因此内存分段成为了可选的特性。而 SFI 通过对段寄存器的访问限制，将程序的控制流严格地限制在一个 Fault Domain 的代码段中。在进行控制的跳转时，会强制使用段寄存器进行检测，如果访问的地址的前 N 位与段基地址不一致，则会触发异常，说明应用程序正在尝试逃出自己的 Fault Domain。\n\n#### Google Native Client\n\n* [Native Client: A Sandbox for Portable, Untrusted x86 Native Code](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Fpubs\u002Farchive\u002F34913.pdf)\n* [论文笔记 in GitHub](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002FNaCl-note)\n\n这篇论文是在 CSP 课上读的， 因为需要做分享，所以读的相比于其他论文要仔细一些，之前在阅读的时候就写了一些阅读笔记，比较冗长，这里写一些这篇论文的大概 idea 的介绍，以及一些自己的评论。\n\nGoogle Native Client(NaCl)，简单来说是一个在浏览器里跑 Native 代码的技术。类比技术是微软\u003Cdel>臭名昭著\u003C\u002Fdel>的 ActiveX。相比于 ActiveX 那种毫无安全性可言的实现，NaCl 使用了一些自己改良过的 Software Fault Isolation(SFI) 的技术，结合了 ptrace 这样的 System Call Interception 的工具，来实现了在浏览器里安全运行 Native 代码的功能。从实现角度来看，是先对代码进行静态检查，保证代码符合 NaCl 制定的一些规则，然后再把程序运行在一个沙箱内，Native 代码所有跟外界的通讯，包括系统调用，都会被封装或者拦截，使用这样的方式来实现了对 Native 代码的安全隔离。在 2009 年的时候，Google 组织了一个 Native Client Security Contest，鼓励开发者寻找 NaCl 的漏洞，最终发现了 20 多个漏洞但是没有一个可以从根本上破坏 NaCl 的保护。目前 Google Chrome 浏览器仍然支持以这样的方式来运行 Native 代码，只不过好像没有多少人在用的样子。Demo 很容易运行，感兴趣可以试一下，很简单就可以实现从 CPP 代码到 Javascript 代码的通信。\n\n为了提高浏览器段代码运行的效率，还有另外一个流派的做法，那就是 [asm.js](http:\u002F\u002Fasmjs.org\u002F)，它的实现思路跟 NaCl 完全不一样，并不会在浏览器里执行 Native 代码，因此不会有这么多安全方面的问题需要考虑，而是通过修改 LLVM 的那一套工具链，把 Native 代码编译成 Javascript 的一个子集，运行这个子集的 Javascript 代码。这样的实现最高可以只比 Native 应用慢一倍，虽然不如 NaCl 媲美原生应用，但是也可以接受了。这是 Firefox 浏览器的路子。\n\n目前业界有了相对统一的思路，WebAssembly。WebAssembly 跟 asm.js 是相同的路子，得到了各种公司的支持。WebAssembly 由 asm.js 的团队和 NaCl 的团队一起开发，NaCl 的团队更多关注在安全上，这也是他们的特长。因此可以说，Native Client 这个 feature 大概是被抛弃了，但是一些安全的实现，还是由原班人马在为 WebAssembly 做贡献。其实这篇论文的主题也不是说 Native Client 的实现有多好，而是强调它是怎么做到安全的，讲道理这样的实现方式，我觉得是 asm.js 那个流派比较好，因为侵入性小一点。\n\n#### Language-Independent Sandboxing\n\n[Language-Independent Sandboxing of Just-In-Time Compilation and Self-Modifying Code](http:\u002F\u002Fciteseerx.ist.psu.edu\u002Fviewdoc\u002Fdownload?doi=10.1.1.207.6665&rep=rep1&type=pdf)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n## 系统(System)\n\n### 文件系统(File System)\n\n#### RAMCloud\n\n[Fast Crash Recovery in RAMCloud](http:\u002F\u002Fweb.stanford.edu\u002F~ouster\u002Fcgi-bin\u002Fpapers\u002Framcloud-recovery.pdf)\n\n>Why RAMCloud uses a log-structured strategy for data in DRAM?\n\nRAMCloud 在备份上，没有完全使用内存做备份，而是在内存中有一个备份，在硬盘上也有一个备份。这样的备份策略省了内存，但是造成了两个问题：\n\n* 备份相对慢速，可能会影响系统的正常操作\n* 系统 crash 后恢复要从硬盘中开始，会比较慢\n\nLog-Structured Strategy 就是为了解决第一个问题而采用的。请求到了内存里是以日志的形式记录，随后会将 entry 分发给各个备份，各个备份在收到后会直接返回，然后再处理，约等于实现了异步的操作。因此备份时的 overhead 被 hide 了，但是这样引入了新的问题，可能导致系统 crash 后没有把 buffer flush 到真正的存储中。软件不行硬件来凑，文中提到了两种方法来保证 entry 到了 buffer 中就是持久化的，一种是 DIMM + super-capacitor，一种是加电池。\n\n综上，日志主要是为了解决同步备份的时候因为 hierarchy 产生的性能问题。\n\n>Which policy does RAMCloud use to place segment replicas and how to find the segment replicas during recovery?\n\n以往的实现是中心化的 coordinator，这样会造成性能瓶颈。所以 RAMCloud 采纳了去中心化的思想，利用了随机化和微调的方式，来分散备份。有些类似 k choises 的选择，RAMCloud 会先随机选择一些，然后再从中选出最合适的，并且加入了 reject 的机制来保证在乐观并发的情况下不会产生竞争的问题。同时为了保证尽可能贴近最优解，RAMCloud 考虑了硬盘速度以及硬盘上已经有的 segment 的数量来进行微调，保证尽可能的均匀。\n\nrecovery 的时候以往的实现是在 coordinator 里维护一个中心化的表，这样的做法向上面提到的一样会造成瓶颈，因此 RAMCloud 在 recovery 的时候会问所有的备份，备份会返回一个它存储的副本列表，整个过程是并行的而且 RAMCloud 用了自称 fast 的 RPC，因此整个过程不会特别慢。\n\n>Does RAMCloud support random access? If so, please explain how.\n\n支持不支持，支持。\n\nRAMCloud 在每个 master 上都维护有一个哈希表，结构为 `\u003Ctable identifier, object identifier>`，通过哈希表，可以进行随机的访问。\n\n#### Optimistic Crash Consistency\n\n[Optimistic Crash Consistency](http:\u002F\u002Fresearch.cs.wisc.edu\u002Fadsl\u002FPublications\u002Foptfs-sosp13.pdf)\n\n这是一篇发表在 SOSP'13 上的论文，主要的工作是在 Ext 4 这样的基于 Journal 来做 Crash Recovery 的文件系统的基础上实现了一种 Optimistic 的 Crash Recovery 的方法，这样的方法能够在保证 Crash Consistency 的同时，大幅度提高性能。但是计算机所有的提高都是 tradeoff 的结果，Optimistic Crash Consistency 是牺牲了数据的 Freshness，也就是新鲜度。\n\nCrash Consistency，就是指文件系统在 Crash 之后，其中的数据还是不是一致的。这里的一致指的是 metadata 和 data 等等数据之间的一致。如果不一致的情况发生了，往往意味着硬盘丢了数据，或者文件系统找不到硬盘上的数据。\n\n在基于 Journal 的文件系统中，一次写入磁盘的操作，要写入的数据有 data，以及在 Journal 中的一份 metadata 的冗余，还有 Journal 中的 commit block，以及最后的 metadata。这四个数据要保证写入顺序才能确保 Crash Consistency。因此要保证数据写入的顺序，就要借助磁盘的 flush 操作，来强制地把数据从磁盘的 cache 刷到真正的磁盘中才行。但是这样会导致很大的性能问题，这篇论文提出了使用 checksums，asynchronous durability notifications，delayed writes 等技术来使得文件系统不需要强制的 flush 操作。但是这样的实现，就会牺牲掉数据的 Freshness，在之前 Ext 4 的实现中，Crash 之后最多丢一个 transaction 的数据，现在可能丢 k 个。但是在性能上比带 flush 的 ext 4 提高了 4-10 倍。\n\n#### F2FS\n\n[F2FS: A New File System for Flash Storage](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Ffast15\u002Ffast15-paper-lee.pdf)\n\n随着 NAND Flash 的发展，现在很多持久存储都渐渐地变成了 SSD。之前的文件系统都是针对 HDD 来设计的，因此并没有针对 FLash 存储的一些硬件特性进行优化，而本文则是提出了一个为了 Flash 存储设计的文件系统，现在以及被并入了 Linux Kernel。整篇论文是很多比较偏工程的点拼接起来的，因此读起来不像是其他文件系统的论文那么晦涩。\n\nFlash 存储在读上面的速度众所周知非常快，而且它并不是像 HDD 那样的机械结构，用磁头来进行读写，而是电子的，因此像内存一样拥有一定的并行性。与此同时，在写数据时，Flash 存储并不是 in place 的写入，而是需要写入一个新的地方，然后修改地址使其生效。这一点非常重要，它导致了 “Wandering Tree“ 的问题，这是 Log structured fs 在 SSD 上存在的一个问题：因为 Flash 存储的写是 out of place 的，因此每次写操作都会使得数据块的地址发生变化，所以需要递归地修改 direct block, indirect block 等等一系列块的内容。为了解决这个问题，F2FS 引入了一个新的表：Node Address Table(NAT)。Indirect block 是指向 NAT 的，这样每当一个 data block 被污染的时候，会更新 direct block 和 NAT 中的表项，这样就防止了在 indirect node block 中的传播。\n\n同时为了利用 Flash 存储的并行性，F2FS 采取了 multi-head logging，并不只有一个 log，而是有多个 log，根据数据的更新频率来写 log，这样提高了性能。\n\n#### PMFS\n\n* [System software for persistent memory](http:\u002F\u002Fesos.hanyang.ac.kr\u002Ffiles\u002Fcourseware\u002Fgraduate\u002FSystem_software\u002Fa15-dulloor.pdf)\n* [Slides](http:\u002F\u002Fembedded.dankook.ac.kr\u002F~choijm\u002Fcourse\u002F201501TOS\u002F0519_PMFS.pdf)\n\n现在有一种新的概念，Non-volatile Memory（非易失性内存）。它是指通过给内存加电容等等方式来实现内存持久性的一种方式。而也有很多研究是基于此来设计文件系统，这篇文章就是这样的一个文件系统。\n\n很惭愧，这篇文章没怎么听课，也没怎么好好读，不过可以讲讲大致的实现。它最让人印象深刻的地方是在保证 Consistency 的时候，使用了 Hybrid 的方式，综合使用了 COW，Journaling 等等方式。还有就是引入了一个新的硬件 primitive，读的不深就不瞎说了。\n\n### 操作系统(Operating System)\n\n#### Exokernel\n\n[Exokernel: An Operating System Architecture for Application-Level Resource Management](https:\u002F\u002Fpdos.csail.mit.edu\u002F6.828\u002F2008\u002Freadings\u002Fengler95exokernel.pdf)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n### Memory\n\n#### Transactional Memory\n\n* [Transactional memory: architectural support for lock-free data structures](http:\u002F\u002Fwww.cs.utexas.edu\u002F~pingali\u002FCS395T\u002F2009fa\u002Flectures\u002Fherlihy93transactional.pdf)\n\n事务性内存已经不是一个新鲜的概念了，从大二以来就一直听说这个词，但一直没有了解过相关的内容。这篇论文是 93 年的，应该是比较老的一篇关于硬件支持事务性内存的论文。而现在在 Intel Haswell 的 CPU 架构中已经有了对事务性内存的支持，但是大家还是有些相关性的。\n\n```c\n\u002F\u002F Critical Section\nx=VALIDATE;\nif (x) {\n      COMMIT;\n} else {\n      ABORT;\n}\n```\n\n上面的代码是事务性内存的一个编程范式，原本是使用锁来进行同步，现在所有的操作可以被理解为是一个事务，只有在事务提交的时候才会生效，而如果遇到了冲突则会被 Abort，所有修改完全被 Discard。\n\n本文是基于嗅探的缓存一致性协议修改来的，文章中在硬件上实现这一点的时候加入了一个新的 L1 Cache，叫做 Tx Cache。因此非事务修改走 regular cache，事务走 Tx Cache。\n\n事务缓存有四个标签，Normal, XCommit, XAbort, Empty。事务提交的时候 XCommit -> Empty, XAbort -> Normal。事务 Abort 的时候，XAbort -> Empty, XCommit -> Normal。\n\n它其实是利用了现存的缓存一致性协议，对于冲突的判断，都是用它来完成的。要理解这篇论文就必须对缓存一致性有比较清楚的认识。而因为实现利用了 Cache，所以在发生 Context Switch 等需要 Flush Cache 的情况下时，事务是一定会被 Abort 的，所以这篇文章的实现主要面向的场景是 short critical section，同时没有 IO 读写。\n\n不过，实现因为是完全基于现有的实现（缓存一致性），因此可以跟非事务性内存的同步操作一起进行，因为其他不在事务中的操作是一样会触发缓存操作的。这算是一个这样实现带来的好处，很关键。\n\n### CFI\n\n#### Control-Flow Integrity\n\n[Control-Flow Integrity. Principles, Implementations, and Applications](https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fwp-content\u002Fuploads\u002F2005\u002F11\u002Fccs05.pdf)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n### Tail Latency\n\n#### The Tail at Scale\n\n[Dean, Jeffrey, and Luiz André Barroso. \"The tail at scale.\" Communications of the ACM 56.2 (2013): 74-80.](https:\u002F\u002Fcacm.acm.org\u002Fmagazines\u002F2013\u002F2\u002F160173-the-tail-at-scale\u002Fabstract)\n\n> Why latency variability is amplified by scale?\n\n这是受到系统的特性影响的。在文中给出的例子，是假如一个用户访问一个服务器，99% 的请求是在 10ms 内被处理完的，而有 1% 的请求是在 1s 内被处理的。在这种情况下，针对一个服务器的请求还是可以接受的。但是现在绝大多数应用都是需要多个服务共同服务最后才返回给终端用户的，因此在这样的情况下，用户感知到的延迟是所需要的服务中延迟最大的值。因此，在这样的情况下，用户感知到的延迟是随着系统规模的增大而提高的。这里的 scale 指的是系统的规模。\n\nPlease briefly outline some effective tail-tolerant techniques.\n\n比如最简单的，使用多台服务器，处理完全相同的逻辑，用 replica 的方式降低延迟。用户的请求会发送给所有的服务器，当任何一个服务器处理完请求，就返回。这样的方式要求应用要自己处理幂等请求，逻辑也会变得复杂一些。在之上可以做一些优化，比如在一个服务器处理完请求后，通知其他服务器终止对幂等请求的处理等等，不过这样也更加增加了实现的难度。\n\n还有一些减少 daemon 进程的方法比如使用 unikernel 等等更加精简的内核，但是这样的做法成本就更高了。\n\nWhy tolerating latency variability for write operations is easier?\n\n因为一般写都是异步的，而且可以容忍一定的不一致。以及在一致性的写上一般都会使用 Paxos, ZAB, raft 之类的算法。而这些算法本身就是 tail tolerant 的。\n\n### Lock\n\n#### Non-scalable locks are dangerous\n\n[Non-scalable locks are dangerous, Silas Boyd-Wickizer, M. Frans Kaashoek, Robert Morris, and Nickolai Zeldovich Proceedings of the Linux Symposium. 2012.](https:\u002F\u002Fwww.kernel.org\u002Fdoc\u002Fols\u002F2012\u002Fols2012-zeldovich.pdf)\n\n>Why does the performance of ticket lock collapse with a small number of cores? (Hint: cache coherence protocol)\n\n在 ticket lock 的实现中，是维护两个 ticket 变量，当前 ticket 和 next ticket。在 unlock 操作中是将当前 ticket 自增从而使得下一个拿到了 ticket 的 core 获取到了锁。\n\n凡是遵循文章中提出的硬件缓存一致性模型的系统，都会遇到 ticket lock 的 rapid collapse。文章提出的硬件缓存一致性模型用目录的方式类比了 CPU 中的缓存，并且用马尔可夫链模型，对 ticket lock 的问题进行了分析。其中每一个节点代表有几个 core 在等的状态，Arrival and Service Rates 分别代表了在不同状态下锁的获得和释放。其中到达率跟在没有在等的 core 的数量 (n - k) 成正比，服务率和在等的 core 的数量 (k) 成反比。所以随着 k 的增大，服务率是减小的。这使得模型得到了一个数学上的结论，锁的获取时间和正在等待锁的 core 的数量是成正比的。\n\n因此随着 core 的增加，在 serial section 很小的时候，Sk = 1\u002F(s + ck\u002F2) 中 k 对 Sk 的贡献越大，因此越容易受到 k 的影响。这也就是为什么，在 serial section 很小的时候，只是多了很少一些在等待锁的 cores，就出现了性能的雪崩。\n\n>Why does MCS lock have better scalability than ticket lock?\n\n在 ticket lock 中，所有的 core 都去依靠同一个变量来获得锁，而在 MCS lock 中，前一个 core 在 release 的时候会修改下一个 core 的 locked 变量，通知下一个 core 来获得锁。这样每个锁都只依靠属于自己的一个变量，这样的实现是缓存一致性无关的，有着更好的 scalability。\n\n### Bug\n\n#### STACK\n\n[Towards Optimization-Safe Systems: Analyzing the Impact of Undefined Behavior](https:\u002F\u002Fpdos.csail.mit.edu\u002Fpapers\u002Fstack:sosp13.pdf)\n\nUndefined behavior 是编程语言规范对某段代码可能产生的某些执行结果未定义。Unstable code 就是在程序实际的执行过程中，由于涉及到undefined behavior，从而无法被编译器翻译（直接略过）的代码段。\n\nSTACK会在Assumption Δ被允许和不允许的情况下分别模拟编译。\n\n* 先模拟假设不成立的情况进行一次编译；\n* 模拟假设成立的情况进行一次编译；\n* 查看前两步的执行结果有没有区别，有区别的地方就是 unstable code。\n\n如果执行第二步时得不到准确的结果，那么会漏报一些unstable code；如果执行第一步时得不到准确的结果，就会产生误报(false warning \u002F false positive)。目前stack给出的Undefined behavior pattern 可能不齐全。\n\n对于程序员来说，通过fix bug或者去掉一些会被编译器当做是undefined behavior的代码；对于编译器来说，可以集成一些现有的bug-finding的工具，或者利用STACK的方式来判定unstable code；完善编程语言的specification，定义更多的代码执行规则，减少undefined behavior的产生。\n\nSTACK为了使可扩展性更高，在计算Δ = ∀e:Reach(e) → ¬Undef(e)的时候做了一些近似运算，使最后得到的结果可能会漏掉一些unstable code。STACK为了简化和滤过某些查询用到的constraint solver如果发生了timeout，也会出现漏报的情况。因此，STACK为了更好的扩展性，牺牲了一定的可靠性（精度）。\n\n## 安全(Security)\n\n### 虚拟机安全(Virtulization, Security)\n\n#### CloudVisor\n\n[CloudVisor: Retrofitting Protection of Virtual Machines in Multi-tenant Cloud with Nested Virtualization](https:\u002F\u002Fwww.sigops.org\u002Fsosp\u002Fsosp11\u002Fcurrent\u002F2011-Cascais\u002Fprintable\u002F15-zhang.pdf)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n### Taint Tracing\n\n#### TaintDroid\n\n* [TaintDroid: An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones](http:\u002F\u002Fwww.appanalysis.org\u002Ftdroid10.pdf)\n* [Realtime Privacy Monitoring on Smartphones](http:\u002F\u002Fwww.appanalysis.org\u002F)\n\nTaint 分析，就是指把一些敏感数据标注出来，在程序执行的过程中确保这些被标注的敏感数据不会被泄露出去的技术。TaintDroid 是一个在 Andriod 做 Taint 分析的工具，之前的 Taint 分析工具，overhead 非常大，而 TaintDroid 通过分层的思想，在不同层做不同粒度的 Taint 跟踪，大大降低了运行时的 overhead。\n\n论文有一个配套的 demo，是可以运行的，感兴趣的话可以自己试试看，这里也有一个 [Demo 视频](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=qnLujX1Dw4Y)。很有趣的是这篇论文是 Intel Labs 有参与的，不是很懂他们怎么会想到做这样的事情。\n\n### ROP\n\n#### Hacking Blind\n\n* [Hacking Blind](www.scs.stanford.edu\u002F~sorbo\u002Fbrop\u002Fbittau-brop.pdf)\n* [【转载】Blind Return Oriented Programming (BROP) Attack - 攻击原理](http:\u002F\u002Fytliu.info\u002Fblog\u002F2014\u002F09\u002F28\u002Fblind-return-oriented-programming-brop-attack-gong-ji-yuan-li\u002F)\n\n这篇论文看上去就很酷，实现很让人亮眼。最简单的 ROP，就是寻找一个个的 gadget，然后把 gadget 连接起来。然后让控制流走到这些 gadget 里，就 OK 了。但是这篇论文是如何在远程来劫持控制流，来实现 ROP 攻击。攻击者不了解远程的系统，因此首先系统要有一个已知的 stack overflow 的漏洞，然后要求攻击的进程在死了后会重启，而且 ASLR 后的地址不变。\n\n其实条件是很苛刻的，而且也不懂为什么一个攻击者可以在不了解远程系统的同时知道系统的 stack overflow 漏洞。整体攻击的过程，是先 Dump 服务器的内存，然后再进行常规的 ROP，其中 Dump 内存的操作非常精巧，感觉只有 ROP 高级玩家才能想出这样的做法，具体可以看看上面链接的论文，是我们学院 IPADS 实验室的一个学长写的，很清楚。\n\n## 大数据\n\n### 框架\n\n#### Hadoop\n\n* [MapReduce: Simplified Data Processing on Large Clusters](https:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Farchive\u002Fmapreduce-osdi04.pdf)\n* [The Hadoop Distributed File System](http:\u002F\u002Fpages.cs.wisc.edu\u002F~akella\u002FCS838\u002FF15\u002F838-CloudPapers\u002Fhdfs.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n#### Spark\n\n* [Spark: Cluster Computing with Working Sets](https:\u002F\u002Fpeople.csail.mit.edu\u002Fmatei\u002Fpapers\u002F2010\u002Fhotcloud_spark.pdf)\n* [Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fnsdi12\u002Fnsdi12-final138.pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n### Data Processing\n\n#### Realtime Data Processing at Facebook\n\n* [Realtime Data Processing at Facebook](http:\u002F\u002Fdblp.org\u002Frec\u002Fhtml\u002Fconf\u002Fsigmod\u002FChenWIJLSWWWY16)\n\n## 网络\n\n### Network Function Virtualization(NFV)\n\n#### Click\n\n[The Click modular router, Robert Morris, Eddie Kohler, John Jannotti, M. Frans Kaashoek SOSP 1999](https:\u002F\u002Fpdos.csail.mit.edu\u002Fpapers\u002Fclick:tocs00\u002Fpaper.pdf)\n\n> Why must Click provide both push' andpull' methods? Can we eliminate one of the two operations? How\u002FWhy?\n\nPush 和 Pull 是两种连接方式。 Push 是从源 Element 到下游的元素。在 Push 连接方式里，上游的元素会提交一个包到下游的元素。Pull 是从目的地元素到上游元素。在 Pull 的连接方式里，是下游的元素发送包请求到上游的元素。Push 和 Pull的共同使用可以使包转发连接的适当终止，可以很好地解决路由器控制流问题。例如包调度的决定——选择哪个队列去请求一个包对于组合的 Pull 元素来说是非常容易实现的。另外，系统不应该向繁忙的转发接口发送包，否则，这个接口就必须存储包，并且路由器会失去处理这些包的能力（丢弃，修改优先级等）。这个约束可以由简单的给转发接口一个 Pull 输入实现。然后这个接口就可以控制包转发，并且可以在它准备好的时候请求包。\n\n> One limitation of Click is the difficulty of scheduling CPU time among pull and push paths. Why is it difficult? What would you do to improve it?\n\nClick 的调度器就是一个 Pull Element，它有多个输出，而只有一个输入。至于 CPU 时间调度的问题， 是说 Click 没办法处理多个设备同时接收或者发送数据的情况。目前的处理方法是 linux 处理大部分这样的调度，剩下的交由 Click 来做。最终所有这些都应该由一个单一的机制来控制。关于 improve 可以把 linux 里相关的逻辑作为一个 Element 引入，不知是否可行。\n\n> How can batch processing be applied to Click? Be specific and consider the impact on latency and throughput.\n\nAPSys 2012 上有一篇论文『The Power of Batching in the Click Modular Router』，它尝试了 psio，netmap，PF_ring 等等开源的 IO batching 的工具，最后选择了 psio。同时为了实现计算的 batching，它修改了现有的 Click。\n\n这样做提高了 throughput，但是加大了 latency。这也跟 batching 的程度有关，理论上来说是可以控制的。\n","# 论文笔记\n\n这个 repo 希望能够记录自己阅读论文的过程，其中的论文一部分来自于在上海交通大学软件学院的研究生课上需要阅读的论文，这部分会比较偏安全和虚拟化。还有一部分论文是自己感兴趣，想去了解的，这部分可能比较偏虚拟化和分布式。论文笔记希望能够记录自己在读论文的时候的想法，其中包括但不限于论文的大致 idea，实现方式，以及自己对论文的评价等等。希望能够把每一篇论文的笔记限制在 1000 字以内。\n\n**目前不再以 Markdown 文件的方式维护，转到 [issue 页面](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002Fpapers-notebook\u002Fissues)进行，也欢迎到[这个 issue 中](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002Fpapers-notebook\u002Fissues\u002F1)分享您认为值得一读的 paper**\n\n## 目录(TOC)\n\n* [分布式(Distributed System)](#分布式distributed-system)\n    * [调度器(Scheduler)](#调度器scheduler)\n      * [Mesos](#mesos)\n      * [Omega](#omega)\n      * [Borg](#borg)\n      * [Yarn](#yarn)\n      * [Sparrow](#sparrow)\n      * [Apollo](#apollo)\n      * [Hawk](#hawk)\n      * [Mercury](#mercury)\n      * [Firmament](#firmament)\n      * [ERA](#era)\n      * [Efficient Queue Management for Cluster Scheduling](#efficient-queue-management-for-cluster-scheduling)\n      * [Tarcil](#tarcil)\n      * [Eagle](#eagle)\n      * [Canary](#canary)\n      * [Profiling a warehouse-scale computer](#profiling-a-warehouse-scale-computer)\n    * [Graph Computation](#graph-computation)\n      * [Wukong](#wukong)\n    * [Lock Service](#lock-service)\n      * [Chubby](#chubby)\n    * [一致性(Consensus)](#一致性consensus)\n      * [Raft](#raft)\n      * [Zookeeper](#zookeeper)\n      * [Paxos](#paxos)\n    * [存储(Storage)](#存储storage)\n      * [BigTable](#bigtable)\n      * [Dynamo](#dynamo)\n      * [Spanner](#spanner)\n      * [Distributed Transaction with RDMA and HTM](#distributed-transaction-with-rdma-and-htm)\n      * [Key-Value Store with RDMA](#key-value-store-with-rdma)\n      * [RDF Store with RDMA](#rdf-store-with-rdma)\n      * [Ambry](#ambry)\n* [虚拟化(Virtualization)](#虚拟化virtualization)\n    * [虚拟机管理器(Hypervisor)](#虚拟机管理器hypervisor)\n      * [Xen](#xen)\n      * [kvm](#kvm)\n    * [容器(Container)](#容器container)\n      * [mbox](#mbox)\n      * [Slacker](#slacker)\n* [沙箱(Sandboxing)](#沙箱sandboxing)\n    * [系统调用拦截(System Call Interposition)](#系统调用拦截system-call-interposition)\n      * [Janus](#janus)\n      * [Ostia](#ostia)\n    * [软件故障隔离(Software-based Fault Isolation)](#软件故障隔离software-based-fault-isolation)\n      * [SFI](#sfi)\n      * [Google Native Client](#google-native-client)\n      * [Language-Independent Sandboxing](#language-independent-sandboxing)\n* [系统(System)](#系统system)\n    * [文件系统(File System)](#文件系统file-system)\n      * [RAMCloud](#ramcloud)\n      * [Optimistic Crash Consistency](#optimistic-crash-consistency)\n      * [F2FS](#f2fs)\n      * [PMFS](#pmfs)\n    * [操作系统(Operating System)](#操作系统operating-system)\n      * [Exokernel](#exokernel)\n    * [Memory](#memory)\n      * [Transactional Memory](#transactional-memory)\n    * [CFI](#cfi)\n      * [Control-Flow Integrity](#control-flow-integrity)\n    * [Tail Latency](#tail-latency)\n      * [The Tail at Scale](#the-tail-at-scale)\n    * [Lock](#lock)\n      * [Non-scalable locks are dangerous](#non-scalable-locks-are-dangerous)\n    * [Bug](#bug)\n      * [STACK](#stack)\n* [安全(Security)](#安全security)\n    * [虚拟机安全(Virtulization, Security)](#虚拟机安全virtulization-security)\n      * [CloudVisor](#cloudvisor)\n    * [Taint Tracing](#taint-tracing)\n      * [TaintDroid](#taintdroid)\n    * [ROP](#rop)\n      * [Hacking Blind](#hacking-blind)\n* [大数据](#大数据)\n    * [框架](#框架)\n      * [Hadoop](#hadoop)\n      * [Spark](#spark)\n    * [Data Processing](#data-processing)\n      * [Realtime Data Processing at Facebook](#realtime-data-processing-at-facebook)\n* [网络](#网络)\n    * [Network Function Virtualization(NFV)](#network-function-virtualizationnfv)\n      * [Click](#click)\n\nCreated by [gh-md-toc](https:\u002F\u002Fgithub.com\u002Fekalinin\u002Fgithub-markdown-toc)\n\n\n## 分布式(Distributed System)\n\n### 调度器(Scheduler)\n\n* [Comparison of Container Schedulers](https:\u002F\u002Fmedium.com\u002F@ArmandGrillet\u002Fcomparison-of-container-schedulers-c427f4f7421)\n* [集群调度框架的架构演进之路](http:\u002F\u002Fwww.infoq.com\u002Fcn\u002Farticles\u002Fscheduler-architectures)\n\n在我看来，分布式是研究如何让程序能够在多台机器上运行拥有更好的性能的一个方向。那如果要实现这一点，调度很关键。\n\n目前我读过的与分布式调度器有关的论文有 Mesos, Omega, Yarn 和 Borg。这其中 Mesos 是最早的，它来自伯克利大学。其最亮的地方在于两层调度的框架，使得调度跟框架是松耦合的。目前很多公司都是在用它的，而且有很多基于 Mesos 的创业公司，比如 Mesosphere 等等。Omega 跟 Mesos 的第二作者是一个人。Omega 具体来说也不知道算是谁写的，应该算是大学和谷歌一起做的研究。Omega 发表在 EuroSys'13 上，是在基于 Mesos 的基础上，提出了一种完全并行的调度的解决方案，能够在调度上有更好的性能。不过论文是采取的模拟实验来进行验证的，不知道是否有生产上的使用。Borg 是发表在 EuroSys'15 上的，是谷歌真正一直在使用的集群管理工具。可以说谷歌为什么可以用廉价的机器来达到很高的可用性，有很大一部分是因为 Borg。Borg 和 Omega 是不开源的，而 Mesos 是开源的，不过 Borg 有一个开源的继任者，就是目前大名鼎鼎的 Kubernetes。Kubernetes 下面用 Docker Conatainer，而不是 Linux 内核的那些用来做进程级别的性能隔离的特性来实现的。不过最近 Kubernetes 似乎在跟 Docker 撤逼，因为 Docker 公司的一些强势吧，可能之后不会只支持 Docker Conatainer。Kubernetes 在很长的时间内都不是 production ready 的，只能支持 100 个节点，跟 Borg 的 10K 完全没法比，不知道现在是什么情况。\n\n#### Mesos\n\n* [Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center](https:\u002F\u002Fpeople.eecs.berkeley.edu\u002F~alig\u002Fpapers\u002Fmesos.pdf)\n* [Apache Mesos](https:\u002F\u002Fgithub.com\u002Fapache\u002Fmesos)\n\nMesos 是调度器绕不过去的一篇论文，因为它是目前在工业界应用最广泛的开源系统之一。Mesos 跟 exokernel 的思想很像，分离了管理和保护。之前所有的调度器，都是由自己来决定是否把资源给某个任务的，在 mesos 中是 framework 决定是否接受资源的要约。在容灾上，mesos 是通过 zookeeper 做 leader election 的，而且 master 维护的状态是 soft 的，因此 master 没有单点故障的问题，而对于 node 的故障，会反馈给 framework，让他们来处理。Mesos 就像是一个最小的 kernel，所有的决定都是『用户态』的 framework 来做的。\n\nMesos 是在 node 上给每一个 framework 运行一个 executor 的，使用 Linux Containers 等容器技术来做隔离。最后通过在一个集群上跑多个 framework 的方式来验证 mesos 的可用性。这篇文章整体来说比较简单，也可能是因为听过太多次关于 mesos 的架构了。\n\n#### Omega\n\n[Omega: flexible, scalable schedulers for large compute clusters](http:\u002F\u002Fweb.eecs.umich.edu\u002F~mosharaf\u002FReadings\u002FOmega.pdf)\n\n```\n\u002F\u002F TODO Add the notes\n```\n\n#### Borg\n\n[Large-scale cluster management at Google with Borg](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Fpubs\u002Farchive\u002F43438.pdf)\n\nBorg 是谷歌发表在 EuroSys'15 上的一篇文章，讲述了其内部是如何做集群管理的。Borg 是我看过的第一篇关于集群管理的论文。首先介绍下 Borg 的特点，Borg 是一个用来做集群管理的工具，它的目标就是让跑在它上面的应用能够拥有很好的可用性和可靠性的同时，能够提高机器的利用率，而且这些是在一个非常大规模的机器环境下。在 Borg 被设计的时候，还没有对虚拟化的硬件支持，也就是 Intel VT-x 等等那些硬件特性，所以 Borg 是使用了进程级别的隔离手段，也就是 Control Group。\n\nBorg 的架构其实还挺简单的，是比较经典的 Master\u002FSlave 架构，其中在 Master 部分，有两个抽象的进程，一个是 Borg Master，一个是 Borg Scheduler。Borg Master 是有5个备份的，每个都会在内存里维护集群里所有对象的状态。他们5个组成了一个小集群，用 Paxos 算法做一致性的，会选举出一个 leader 来处理请求，这点是之前 Kubernetes 做不到的。\n\n调度器方面的实现比较简单，就是一个队列，根据优先级做 round-robin。这里读起来感觉没什么新意，就不多说了。调度的平均时间大概是 25s，其中 80% 的时间在下载包。谷歌也是实诚，下载安装包的时间都算到调度里面去。\n\n谷歌写的论文一向是简单易懂，特别良心的。所以要是对集群感兴趣，可以去看下这篇论文，花两三个小时就能看完了。\n\n#### Yarn\n\n[Apache Hadoop YARN: Yet Another Resource Negotiator](https:\u002F\u002Fwww.sics.se\u002F~amir\u002Fid2221\u002Fpapers\u002F2013%20-%20Apache%20Hadoop%20YARN%20-%20Yet%20Another%20Resource%20Negotiator%20(SoCC).pdf)\n\n```\n\u002F\u002F TODO Wait to read\n```\n\n#### Sparrow\n\n* [Sparrow: Distributed, Low Latency Scheduling](https:\u002F\u002Fpeople.eecs.berkeley.edu\u002F~keo\u002Fpublications\u002Fsosp13-final17.pdf)\n* [Sparrow in GitHub](https:\u002F\u002Fgithub.com\u002Fradlab\u002Fsparrow)\n\nSparrow 是一个与前面的调度器架构都不一样的实现，是去中心化的架构。之前的所有调度器，无论是 monolithic 的还是后面 Mesos 那样两层的架构，都是有一个中心化的调度器在运行，这样的方式会使得调度器的效率不是那么高。 Sparrow 是 AMPLab 的又一力作，发表在 SOSP'13 上，它不是一个 general-purpose 的调度器，而是针对 short job 这一特殊的 workload。其灵感来源于一个负载均衡方面的经典论文，k choices。这篇文章的 idea 是，在 k 台机器里选一个最好的，而不是在 n 里选一个最好的，可以大大降低负载均衡的 overhead，同时也对负载的分配跟最优解差不了多少。\n\nSparrow 的核心思想是：在分配任务时，随机选择几个工作节点，然后从中挑选出最合适的一个。这是因为 Sparrow 的应用场景中，所有任务都非常短小，因此只需考虑任务队列的长度即可。针对多个任务的分配问题，Sparrow 采用了批处理的方式来优化。例如，当有 2 个任务需要分配时，它不会分别进行两次选择，每次从 k 个工作节点中选出 1 个，而是直接从 2k 个工作节点中一次性选出 2 个。\n\n这篇论文读起来非常轻松，其思路也相对简单，但却与以往的方法完全不同。其实这种想法并不难想到——在阅读“k 选 1”的相关文献时，我就曾思考过是否可以将其应用到调度器中，结果发现这一思路早已被提出。\n\n目前，Sparrow 已在 GitHub 上开源，但尚未听说有公司将其应用于生产环境。它的主要局限性在于对工作负载的适应性较弱，仅对短任务场景表现良好。\n\n#### Apollo\n\n* [Apollo: 面向云规模计算的可扩展且协调一致的调度](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fosdi14\u002Fosdi14-paper-boutin_0.pdf)\n* [USENIX 大会幻灯片](https:\u002F\u002Fwww.usenix.org\u002Fsites\u002Fdefault\u002Ffiles\u002Fconference\u002Fprotected-files\u002Fosdi14_slides_boutin.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n#### Hawk\n\n* [Hawk: 混合型数据中心调度](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fatc15\u002Fatc15-paper-delgado.pdf)\n* [USENIX ATC 2015 大会幻灯片](https:\u002F\u002Fproject.inria.fr\u002Fepfl-Inria\u002Ffiles\u002F2016\u002F02\u002Ftalk-pameladelgado.pdf)\n\n寻找新思路的一种方法，就是在两种极端方案之间找到折中点，实现你中有我、我中有你的结合。毕竟计算机领域的几乎所有问题都涉及权衡。两种极端方案往往是为了满足不同的需求而设计的，而折中方案则常常是一种巧妙的创新方式。类似的例子包括单内核、微内核和混合内核。本文也是如此，它将去中心化和中心化调度相结合。前面提到，去中心化的调度方式只适用于短任务的工作负载；而在 Hawk 中，长任务由中心化调度器处理，短任务则由去中心化调度器负责。\n\n此外，为了使这两种调度方式更好地协同工作，Hawk 还做了一些细节上的优化。例如，当某个工作节点完成手头的所有任务后，会主动“抢”其他节点上的短任务来执行。看来资本主义下的工作节点确实都很积极进取。\n\n值得一提的是，这篇论文的验证使用了谷歌公开的追踪数据集，该数据集同样开源，可在 [https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcluster-data](https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fcluster-data) 找到。\n\n#### Mercury\n\n* [Mercury: 大型共享集群中的混合式集中与分布式调度](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fatc15\u002Fatc15-paper-karanasos.pdf)\n* [USENIX ATC 2015 大会幻灯片](https:\u002F\u002Fwww.usenix.org\u002Fsites\u002Fdefault\u002Ffiles\u002Fconference\u002Fprotected-files\u002Fatc15_slides_karanasos.pdf)\n\nMercury 与 Hawk 提出的思路几乎完全相同，都是在总结集中式和分布式调度各自的优缺点后，提出了一种混合方案。Mercury 由微软提出，其演示文稿制作得更为精美。它基于 YARN 实现，而 Hawk 则是在 Spark 上实现的。这说明，一篇论文若要真正具有说服力，必须要有具体的实现和实验验证。\n\n#### Firmament\n\n* [Firmament: 大规模下快速、集中式的集群调度](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fosdi16\u002Fosdi16-gog.pdf)\n* [GitHub 项目页面](https:\u002F\u002Fgithub.com\u002Fcamsas\u002Ffirmament)\n* [Firmament 在 Kubernetes 中的应用](https:\u002F\u002Fgithub.com\u002Fcamsas\u002Fposeidon)\n\n这是一篇基于最大流最小割算法的集中式调度论文。本文借鉴了 Quincy 的研究，但在求解最大流最小割问题时，进行了特定于问题的优化，从而解决了 Quincy 无法克服的效率瓶颈。此外，Firmament 还并行运行两个 MCMF 算法，以进一步加速调度过程。该项目已在 Kubernetes 中实现了部署。\n\n#### ERA\n\n* [ERA: 用于云计算的经济型资源分配框架](https:\u002F\u002Farxiv.org\u002Fpdf\u002F1702.07311.pdf)\n\n```\n\u002F\u002F TODO 添加笔记\n```\n\n#### 集群调度中的高效队列管理\n\n* [集群调度中的高效队列管理](http:\u002F\u002Fdl.acm.org\u002Fcitation.cfm?doid=2901318.2901354)\n\n```\n\u002F\u002F TODO 添加笔记\n```\n\n#### Tarcil\n\n* [Tarcil: 在大型共享集群中兼顾调度速度与质量](http:\u002F\u002Fweb.stanford.edu\u002F~cdel\u002F2015.socc.tarcil.pdf)\n* [Tarcil: 大型共享集群中的高质量、低延迟调度](https:\u002F\u002Fweb.stanford.edu\u002Fgroup\u002Fmast\u002Fcgi-bin\u002Fdrupal\u002Fsystem\u002Ffiles\u002F2014.techreport.tarcil_0.pdf)\n\n```\n\u002F\u002F TODO 添加笔记\n```\n\n#### Eagle\n\n* [Eagle: 更好的混合型数据中心调度器](https:\u002F\u002Fpdfs.semanticscholar.org\u002F36b3\u002F3a2e5ee77e6b191aa8bfaf4a5aac450d1b57.pdf)\n* [Eagle 中的作业感知调度：分而治之，坚守探测机制](https:\u002F\u002Finfoscience.epfl.ch\u002Frecord\u002F221125\u002Ffiles\u002Fsocc2016-final189.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n#### Canary\n\n* [Canary: 高性能云计算的调度架构](http:\u002F\u002Fhci.stanford.edu\u002Fcstr\u002Freports\u002F2016-01.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n#### 仓库级计算机的性能剖析\n\n* [仓库级计算机的性能剖析](http:\u002F\u002Fdelivery.acm.org\u002F10.1145\u002F2760000\u002F2750392\u002Fp158-kanev.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n\n\n### 图计算\n\n#### Wukong\n\n[基于 RDMA 的分布式图遍历实现快速并发的 RDF 查询](http:\u002F\u002Fipads.se.sjtu.edu.cn\u002Flib\u002Fexe\u002Ffetch.php?media=publications:wukong-osdi16.pdf)\n\nWukong 采用去中心化的设计，每个服务器都可以独立处理请求。每个服务器分为两部分：查询引擎和存储模块。\n\nWukong 共有两种索引类型：Type 和 Predicate。\n\n> 现有的 RDF 系统存在哪些瓶颈？\n\n现有实现主要有两种：Triple store and triple join 以及 Graph store and graph exploration。前者将 RDF 数据以三元组的形式存储在关系数据库中，查询过程分为扫描和连接两个步骤。扫描会分解为多个子查询，最后再通过哈希连接等操作将结果合并在一起。由此可见，当数据量非常大时，最终的连接操作将成为一大难题。\n\n第二种方式则是以图结构存储和查询 RDF 数据，典型的代表是 Trinity.RDF，它引入了一些剪枝优化技术。然而，最终仍然需要进行一次完整的连接操作。\n\n综上所述，现有的实现中，最终的连接操作是最主要的瓶颈。\n\n> Wukong 与之前的基于图的设计相比有哪些不同？有何优势？\n\n最大的区别在于索引的存储方式。以往的基于图的设计通常使用独立的索引数据结构来存储索引，而 Wukong 则将索引本身视为基本的数据结构（即节点和边）来存储，并且还考虑了分区存储的方式。\n\n这样做有两个好处：首先，在进行图遍历或搜索时，可以直接从索引节点开始，无需额外的操作；其次，这种方式使得索引的分布式存储变得非常简单，直接复用了常规数据的存储方法。\n\n> 什么是全历史剪枝？与之前的剪枝方法相比有何不同？为什么 Wukong 可以采用全历史剪枝？\n\n所谓“全历史”，就是指会记录下所有的历史信息。而以往的做法只是记录一次。之所以能够这样做，一方面是因为 RDF 查询的步骤通常不多，另一方面，RDMA 在处理小于 2KB 的数据时性能几乎不变，因此 Wukong 可以采用这种方法。\n\n### 锁服务\n\n#### Chubby\n\n[Chubby 锁服务：面向松耦合分布式系统的锁服务](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Farchive\u002Fchubby-osdi06.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n### 一致性(Consensus)\n\n#### Raft\n\n* [探寻易于理解的一致性算法（扩展版）](https:\u002F\u002Fraft.github.io\u002Fraft.pdf)\n* [幻灯片](https:\u002F\u002Fspeakerdeck.com\u002Fbenbjohnson\u002Fraft-the-understandable-distributed-consensus-protocol)\n\n这篇论文以其易读性和易实现性而广受认可，但这只是相对于 Paxos 而言的。实际上，要想真正读懂它，仍需具备一定的背景知识。由于我尚未正式研读过 Paxos，因此难以对其进行比较。不过，Raft 借鉴了状态机的思想，将分布式一致性问题拆分为领导者选举和日志同步两个子问题，这种做法简洁明了。\n\n我认为理解 Raft 并不困难，但要弄清楚其正确性是如何得到保证的，则相对复杂。越是简洁的系统，其背后的数学证明往往越复杂，而这一点我目前还不甚了解。\n\n#### Zookeeper\n\n[ZooKeeper: 面向互联网规模系统的无阻塞协调服务](http:\u002F\u002Fstatic.cs.brown.edu\u002Fcourses\u002Fcsci2270\u002Farchives\u002F2012\u002Fpapers\u002Freplication\u002Fhunt.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n#### Paxos\n\n* [拜占庭将军问题](http:\u002F\u002Fwww.cs.cmu.edu\u002F~15712\u002Fpapers\u002Flamport82.pdf)\n* [Part-Time 议会](http:\u002F\u002Fresearch.microsoft.com\u002Fen-us\u002Fum\u002Fpeople\u002Flamport\u002Fpubs\u002Flamport-paxos.pdf)\n* [重温 Paxos 算法](http:\u002F\u002Fresearch.microsoft.com\u002Fen-us\u002Fum\u002Fpeople\u002Fblampson\u002F60-PaxosAlgorithm\u002FAcrobat.pdf)\n* [Paxos 简易版](http:\u002F\u002Fresearch.microsoft.com\u002Fen-us\u002Fum\u002Fpeople\u002Flamport\u002Fpubs\u002Fpaxos-simple.pdf)\n* [Paxos 实战：工程视角](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Farchive\u002Fpaxos_made_live.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n### 存储(Storage)\n\n#### BigTable\n\n[BigTable: 面向结构化数据的分布式存储系统](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fen\u002F\u002Farchive\u002Fbigtable-osdi06.pdf)\n\n> 表、表格和 SSTable 之间是什么关系？\n\n表是用户可见的数据表，包含行、列以及不同版本的值。为了便于存储，表在逻辑上被划分为多个表格。\n\n表格是一个存储单元。在 BigTable 的架构中，由一个主服务器和多个表格服务器组成。表格这一抽象概念类似于传统数据库中的分片思想，与 HBase 中的区域概念相似。表格的读写操作由表格服务器负责。\n\nSSTable 是一种文件的格式，全称是 \"Sorted Strings Table\"，是指按照 Key 的排序在文件中存储 \u003CKey, Value> 对。在逻辑上 SSTable 会包含多个 Block，每个 Block 为了方便寻址会有一个 index，所有的 Block index 会写在 SSTable 文件的最后，每当 SSTable 文件被 open 的时候，会将索引加载到内存里，这样每次 Lookup 的时候只有一次硬盘读取。SSTable 也支持全部读取到内存里，这样在 Lookup 的时候没有任何硬盘的读取。这个跟 HBase 中 HFile 的文件格式实现很相似。\n\n> 描述当读操作或写操作到达时会发生什么。\n\n读取和写入是以 Tablet 作为一个 Unit 进行的。\n\n在进行写操作的时候，Tablet Server 会先做一些检查，保证请求的合法以及权限问题。权限的检查是通过检查一个在 Chubby 中的列表进行的，这个列表会被 Client Library 缓存住。一次被允许的写操作会先进入 Commit Log，在处理 Log 的时候采取了批处理来提高吞吐。在操作被 Commit 后，它的内容会被插入 MemTable 里，当 MemTable 的 size 超过一个阈值的时候，会让当前的 MemTable 进入一个 frozen 的状态，随后创建一个新的 MemTable，Frozen 的 MemTable 就可以以 SSTable 的形式写入 GFS。\n\n在进行读操作的时候，Tablet Server 会在做了一些检查保证合法后，在 MemTable 和 SSTable 的一个 merge 后的 view 中来进行读操作，这样可以保证可以读到最新的值。\n\n> 描述 BigTable 适合哪些应用，而不适合哪些应用。\n\nBitTable 适合那些对可用性要求比较高的业务场景，同时对于跨行的事务性没有要求的应用。但是正因为没有跨行事务的支持，所以我觉得引用场景很局限。目前在谷歌内部应该也逐渐被 Spanner 和 F1 所取代吧。\n\n#### Dynamo\n\n[Dynamo: Amazon’s Highly Available Key-value Store](http:\u002F\u002Fs3.amazonaws.com\u002FAllThingsDistributed\u002Fsosp\u002Famazon-dynamo-sosp2007.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n#### Spanner\n\n[Spanner: Google’s Globally-Distributed Database](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Farchive\u002Fspanner-osdi2012.pdf)\n\n> 什么是外部一致性？外部一致性与可串行化有什么区别？\n\n文中对外部一致性的描述是：如果事务 2 发生在事务 1 提交之后，那么事务 2 的时间戳要比事务 1 提交的时间戳要大，也就是线性一致性。\n\n可串行化是数据库隔离性的一个级别，这意味着数据库中所有的事务都是可以被序列化来执行的，只有完全没有冲突的事务才可以并发地执行。\n\n外部一致性是一个关于一致性的概念，在分布式场景下，外部一致性更难实现，因为时序对时间的精度要求很高，在分布式场景下，有可能出现因为不同机器系统时间不一致导致事务 2 拿到一个比事务 1 提交的时间戳更小的时间戳。\n\n可串行化是隔离性上的概念，如果做到了外部一致性，就一定可以做到可串行化。\n\n> Spanner 是如何实现外部一致性的？\n\nSpanner 之前的 Percolator 和 Spanner 都是使用全局的时钟来解决外部一致性的问题。但是 Spanner 创新地使用了原子钟和 GPS 来作为全局的时钟，以此来实现外部一致性。\n\n在事务的执行中，Spanner 会保证，每个事务的 commit timestamp 都会在其 start 和 commit 之间。Spanner 依赖的底层容器集群系统 Borg 会维护一个 True Time API，这个 API 会返回精度为 ε 的时间区间 `[t - ε, t + ε]`。因此每个事务会在 start 和 commit 的时候分别调用一次 True Time API，拿到两个时间区间 `[t1 - ε,t1 + ε]` 和 `[t2 - ε,t2 + ε]`，因此在区间 `[t1 + ε,t2 - ε]` 之间的时间都是可用的，如果 t1 和 t2 很接近，那最多需要等 2ε。\n\n> 如果 TrueTime 假设被违反，会发生什么？作者如何论证 TrueTime 假设应该是正确的？\n\n这会导致 True Time API 不能再用来保证外部一致性，文章中提到，CPU 造成的错误比时钟问题多六倍，因此与时钟造成的错误相比，硬件造成的错误微不足道，可以被视为是值得信任的。\n\n#### 分布式事务与 RDMA 和 HTM\n\n[Fast In-memory Transaction Processing using RDMA and HTM, Xingda Wei, Jiaxin Shi, Yanzhe Chen, Rong Chen, Haibo Chen SOSP 2015](https:\u002F\u002Fpdfs.semanticscholar.org\u002F408b\u002F8d34b7467c0b25b27fdafa77ee241ce7f4c4.pdf)\n\n> DrTM 如何检测远程读取和本地写入之间的冲突？\n\n在检测事务的冲突上，DrTM 使用了 HTM 和 RDMA 两种技术，HTM 是一个硬件的特性，在硬件级别提供了有限的事务性内存的支持。RDMA 是 Remote Direct Memory Access，提供了远程直接访问内存，不阻塞 CPU 的操作。\n\n在处理事务冲突时，是在 transaction layer 做的。对于远程的读和本地的写操作引起的冲突，最简单的方法是用 RMDA 锁住一个 remote record，不管是读还是写。但是这样会大大降低并行性，因此文章进行了一些改进，引入了基于租约的锁，来保证读共享。而在读和本地写产生冲突时，读会通过 RDMA 抑制本地的 HTM 事务，从而避免冲突。\n\n> 为什么 DrTM 会出现死锁问题，它是如何避免死锁的？\n\n首先，在 DrTM 的 fallback 处理程序中，不能像传统的实现那样，一个简单的锁就可以解决问题，而是 fallback 处理程序通过 2PL，对于任何 record 都是以远程的形式进行访问。这里就有可能产生死锁，因为涉及到远程锁的顺序。\n\n为了避免这个问题，DrTM 声明了一个全局的释放和申请锁的顺序，避免了死锁的问题。\n\n> DrTM 的局限性是什么？\n\n首先，DrTM 没有做到很好的可用性，这是它最大的局限性。还有就是需要硬件特性的支持，导致在很多现有的硬件上没有办法完全复刻 DrTM 的工作，而需要一些适配性的工作。\n\n#### 基于 RDMA 的键值存储\n\n[Using One-Sided RDMA Reads to Build a Fast, CPU-Efficient Key-Value Store, Christopher Mitchell, Yifeng Geng, Jinyang Li USENIX ATC 2013](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fatc13\u002Fatc13-mitchell.pdf)\n\n> 什么使得内存中的键值存储系统适合进行 RDMA 优化？\n\n因为内存中的键值存储系统的大多数请求都是读操作，因此对于 RDMA 来说，这样的特点使得其实现比较简单，只需要对 get 请求做修改就可以了，这样既可以利用 RDMA 的优点，又不需要对系统做过多的修改。\n\n> Pilaf 是如何确保 ‘get’ 操作的数据一致性的？它是否存在任何问题？\n\nPilaf 利用了『自校验』的数据结构，它包括一个 root 和很多 pointer，然后会记录一个 checksum。client 通过检查 checksum 可以检测到读写不一致。当遇到了数据竞争时，client 会自动地进行重试操作。\n\n文中提到有两个应用场景会有问题，一个是服务器修改 hash table 的时候客户端也在读 hash table，这会导致客户端从不合法的内存地址读取内容。\n\n另外是客户端的指针引用可能非法的。比如当服务器在删除一个 key-value 对的时候，客户端自己维护的引用就会已经是失效的。\n\n> 为什么 Pilaf 需要两次往返才能完成一个 ‘get’ 操作？我们能否利用现有的 RDMA 操作将往返次数减少到一次？为什么\u002F如何？\n\n这是因为涉及两次读操作，一次是读哈希表，一次是读真正的 key-value 的内容。可以考虑合并两个内存块，但是这样应该会使得可以存储的空间变小。\n\n#### 基于 RDMA 的 RDF 存储\n\n[Fast and Concurrent RDF Queries with RDMA-based Distributed Graph Exploration, Jiaxin Shi, Youyang Yao, Rong Chen, Haibo Chen, Feifei Li OSDI 2016](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fosdi16\u002Fosdi16-shi.pdf)\n\n> 现有的 RDF 系统有哪些瓶颈？\n\n现有主要有两种不同的实现方式，分别是 Triple store and triple join 和 Graph store and graph exploration。前者是以 triple 的方式来将 RDF 数据存储在关系型数据库中，因此查询有两个步骤，scan 和 join。scan 会分为子查询，最后再借由 hash join 之类的 join 的操作将查询的结果 join 在一起。由此可知如果数据非常大的时候，最后的 join 会是很大的问题。\n\n第二种方式是以图的方式来存储和查询 RDF。这样的方式以 Trinity.RDF 为代表，有一些剪枝的优化。但是最后也会有一个 final join 的过程。\n\n纵观之前的实现，最后的 join 是一个最大的问题。\n\n> Wukong 与之前的基于图的设计相比有哪些不同？有哪些好处？\n\n最大的不同在于索引的存储方式。之前的基于图的设计都是用独立的索引数据结构来存索引，但是 Wukong 是把索引同样当做基本的数据结构（点和边）来存储。并且会考虑分区来存储这些索引。\n\n这样做有两个好处，第一点就是在进行图上的遍历或者搜索的时候可以直接从索引的节点开始，不用做额外的操作。第二点是这样使得索引的分布式存储变得非常简单，复用了正常的数据的存储方式。\n\n> 什么是全历史剪枝，它与之前的剪枝方法有什么区别？为什么 Wukong 可以采用全历史剪枝？\n\n全历史剪枝就是说所有的历史记录都会被记录下来。之前是只记录一次的。之所以可以这样做是因为一方面 RDF 的查询都不会有太多步，而且 RDMA 在低于 2K bytes 的时候性能都是差不多的，所以 Wukong 可以这样做。\n\n#### Ambry\n\n* [Ambry: LinkedIn’s Scalable Geo-Distributed Object Store](http:\u002F\u002Fdprg.cs.uiuc.edu\u002Fdocs\u002FSIGMOD2016-a\u002Fambry.pdf)\n* [LinkedIn 开源其分布式对象存储系统 Ambry](http:\u002F\u002Fwww.infoq.com\u002Fcn\u002Fnews\u002F2016\u002F06\u002FLinkedIn-Ambry)\n* [我的幻灯片](https:\u002F\u002Fdocs.google.com\u002Fpresentation\u002Fd\u002F1o1lkn_QmsDvnHfETHmPUgb-nG3hoRXiXqtn09jAV1XI\u002Fedit?usp=sharing)\n\nAmbry 是一个针对 Media 的分布式对象存储系统，是 LinkedIn 做的一项工作。LinkedIn 作为一个社交产品，会有很多媒体数据需要处理，在之前是采取了文件系统存数据，Oracle 存元数据的方法。随着规模的扩大发现不行，于是就有了这个系统。\n\nAmbry 是一个比较中规中矩的分布式系统，比较让人印象深刻的只有一些 threshold。因为社交数据有一个特性：越是冷的数据会越冷，因此 Ambry 针对这个观察做了一些优化，同时在负载均衡上用了 threshold + round-robin 的方式，很 simple 但是效果不错。除此之外在数据存储上有分层的概念在里面，索引是逐层进行的。最上面是 bloom filter，然后是顺序的 segment，最下面是 partition 里真实的数据。\n\n文章很简单，算是很多工程上的点拼在了一起写的论文，有点像最近读的 F2FS，此外 Ambry 感觉也参考了很多文件系统的设计，有一些共性在里面。比如 log structured update 和 journal 等等。\n\n\n\n## 虚拟化(Virtualization)\n\n### 虚拟机管理器(Hypervisor)\n\n#### Xen\n\n* [Xen与虚拟化艺术](http:\u002F\u002Fwww.cl.cam.ac.uk\u002Fresearch\u002Fsrg\u002Fnetos\u002Fpapers\u002F2003-xensosp.pdf)\n* [CSP课堂笔记之Hypervisor](http:\u002F\u002Fgaocegege.com\u002FBlog\u002Fcsp\u002Fxen-kvm)\n\nXen是一个非常著名的Hypervisor，它提出了半虚拟化(para-virtualization)的思想。在此之前，虚拟机的实现主要采用全虚拟化(full-virtualization)的方式，但当时的x86架构并不完全支持这种模式。例如，某些指令本应在VMM中执行，但由于不同ring权限级别的行为差异，这些指令有时无法被成功截获并传递到VMM中。为了解决这一问题，Xen引入了hypercall机制，并对Guest操作系统进行了修改，从而更优雅地处理这类情况。\n\n虚拟化的核心资源包括CPU、内存和I\u002FO，而Xen在这三个方面都有其独特之处。其中最引人注目的是它对设备的支持：通过引入Domain 0以及前后端驱动的设计，不仅使设备管理更加自然，还避免了将驱动直接置于VMM中可能引发的稳定性问题。\n\n#### kvm\n\n* [kvm：Linux虚拟机监视器](https:\u002F\u002Fwww.kernel.org\u002Fdoc\u002Fols\u002F2007\u002Fols2007v1-pages-225-230.pdf)\n* [CSP课堂笔记之Hypervisor](http:\u002F\u002Fgaocegege.com\u002FBlog\u002Fcsp\u002Fxen-kvm)\n\n```\n\u002F\u002F TODO 添加笔记\n```\n\n### 容器(Container)\n\n#### mbox\n\n* [面向非root用户的实用且有效的沙箱技术](https:\u002F\u002Fpeople.csail.mit.edu\u002Fnickolai\u002Fpapers\u002Fkim-mbox.pdf)\n* [GitHub上的开源项目](https:\u002F\u002Fgithub.com\u002Ftsgates\u002Fmbox)\n\n```\n\u002F\u002F TODO 添加笔记\n```\n\n#### Slacker\n\n* [Slacker：基于延迟加载Docker容器的快速分发](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Ffast16\u002Ffast16-papers-harter.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n## 沙箱(Sandboxing)\n\n[Linux中的沙箱技术：从智能手机到云端](http:\u002F\u002Fwww.ijcaonline.org\u002Farchives\u002Fvolume148\u002Fnumber8\u002Fborate-2016-ijca-911256.pdf)\n\n沙箱与容器之间有着密切的联系。要实现容器，就必须具备隔离能力，而沙箱正是专门用于实现隔离的技术。之所以将两者分开介绍，是因为沙箱本身是一个非常复杂的研究方向，包含多种不同的类型，而容器只是利用了沙箱技术中的部分方法。\n\n沙箱技术大致可以分为两类：第一类是基于隔离的沙箱，它将应用程序的执行环境与操作系统隔离开来，形成一个独立的运行环境；第二类则是基于规则的沙箱，这类沙箱并不完全依赖于严格的隔离，而是通过设定规则来控制每个应用的权限，允许不同沙箱之间共享操作系统的逻辑资源。\n\n我所阅读的论文大多属于第一类沙箱，其中涉及的主要技术包括capabilities、系统调用拦截（system call interposition）以及基于软件的故障隔离（software-based fault isolation）等。\n\n上述链接是一篇综述性质的文章，主要介绍了在Linux平台上可用于实现沙箱的内核特性。文章对沙箱的定义和功能进行了简单易懂的阐述，值得一读。\n\n### 系统调用拦截(System Call Interposition)\n\n顾名思义，系统调用拦截是指对系统调用进行拦截和过滤的技术。在沙箱的实现过程中，系统调用扮演着至关重要的角色。如何确保应用程序只能执行被授权的系统调用，正是这一研究方向的核心任务。\n\n#### Janus\n\n* [不受信任辅助程序的安全环境（限制狡猾的黑客）](https:\u002F\u002Fwww.usenix.org\u002Flegacy\u002Fpublications\u002Flibrary\u002Fproceedings\u002Fsec96\u002Ffull_papers\u002Fgoldberg\u002Fgoldberg.pdf)\n* [Janus：一种限制不受信任应用程序的方法](http:\u002F\u002Fwww2.eecs.berkeley.edu\u002FPubs\u002FTechRpts\u002F1999\u002FCSD-99-1056.pdf)\n* [陷阱与误区：基于系统调用拦截的安全工具的实际问题](http:\u002F\u002Fwww.isoc.org\u002Fisoc\u002Fconferences\u002Fndss\u002F03\u002Fproceedings\u002Fpapers\u002F11.pdf)\n\n其中第一篇论文发表于1996年，是系统调用拦截领域最具经典意义的文献之一。该论文提出了一种名为Janus的系统，能够根据用户定义的策略对应用程序的系统调用请求进行过滤。后两篇则是后续关于Janus的补充研究。\n\n当时互联网刚刚兴起，用户可以直接使用本地的辅助应用程序打开网络上获取的内容。由于这些内容本身不可信，因此辅助应用程序也存在潜在的安全风险。为此，Janus旨在对这类应用程序进行限制和隔离，使其仅拥有最小的权限，从而在遭受恶意攻击时不会影响整个操作系统。\n\nJanus的目标主要有三点：首先是安全性，其次是灵活性，即要求能够对系统调用的限制精确到参数级别——例如，某些特定参数下的open调用可以允许，而其他参数则不行；最后是可配置性，允许为不同应用程序设置不同的策略。\n\nJanus的实现相对简单，主要借助内核中的ptrace功能，开发了一个内核模块和一个用户态引擎。启动时，Janus会先读取策略文件，然后创建子进程，父进程则负责监控子进程的各种事件。子进程会执行辅助应用程序的逻辑，当遇到系统调用时，首先由Janus的内核模块进行处理，内核模块会与用户态引擎交互，判断请求是否合法。如果合法，则交由内核继续处理；否则，请求将被拒绝。\n\n后两篇论文指出了Janus的一些缺点，包括ptrace机制本身的局限性，以及在系统调用监控和请求拒绝方式上的不足。鉴于篇幅较长，此处不再赘述。\n\n#### Ostia\n\n[Ostia：一种用于安全系统调用拦截的委托式架构](http:\u002F\u002Fbenpfaff.org\u002Fpapers\u002Fostia.pdf)\n\nOstia是在Janus等相关论文之后发表的，因此引用了Janus论文中提到的三篇文献。它的最大贡献在于提出了一种全新的架构，解决了此前基于过滤器的架构难以克服的问题。\n\nOstia与Janus在实现原理上相似，都需要在内核态进行一些修改。然而，两者的区别在于架构设计：Janus需要在内核中有一个负责跟踪的模块，如ptrace，同时在用户态配备一个策略引擎，二者协同工作，其中是否拒绝请求的逻辑由用户态引擎决定，而内核模块则主要负责进程监控。\n\n在我看来，Ostia的实现借鉴了虚拟化的一些思想。当系统调用到达内核时，会回调到调用者用户态内存空间中的一个处理器，再由该处理器转发给代理，最终由代理负责权限和访问的验证。具体的实现细节仍在研究中。\n\n### 基于软件的故障隔离(Software-based Fault Isolation)\n\n#### SFI\n\n[高效的基于软件的故障隔离](https:\u002F\u002Fcrypto.stanford.edu\u002Fcs155\u002Fpapers\u002Fsfi.pdf)\n\n这篇文章发表于1993年，也是首次提出“sandboxing”一词的文献。文中主要介绍了一种通过软件手段实现隔离的方法。传统的隔离通常在操作系统层面进行，过去进程间可以通过RPC通信，而隔离则依靠虚拟内存来实现。然而，这种方式的开销极大，因此本文提出在同一个内存空间内实现错误隔离。SFI的实现利用了处理器的段寄存器。段寄存器最初是为了应对Intel 8086处理器中数据总线与地址总线宽度不一致的问题而引入的。由于这种不匹配导致寻址无法在单个指令周期内完成，Intel便引入了段寄存器，将整个内存空间划分为四个段，段寄存器存储每个段的前N位地址，通过段内偏移量而非完整的物理地址来描述内存地址，从而解决了这一问题。如今，现代处理器的架构已不再存在地址宽度不统一的问题，因此内存分段已成为可选特性。而SFI则通过对段寄存器访问的限制，将程序的控制流严格限定在一个Fault Domain的代码段内。当进行控制转移时，系统会强制检查段寄存器，若访问地址的前N位与段基地址不符，则会触发异常，表明应用程序正试图逃离其所属的Fault Domain。\n\n#### Google Native Client\n\n* [Native Client：一个用于运行可移植、不受信任的x86原生代码的沙箱](http:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Fpubs\u002Farchive\u002F34913.pdf)\n* [GitHub上的论文笔记](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002FNaCl-note)\n\n这篇论文是在CSP课程上阅读的，因为需要做分享，所以相比其他论文读得更为仔细。之前阅读时已经写了一些笔记，内容较为冗长。这里仅简要介绍论文的大致思路及个人的一些看法。\n\nGoogle Native Client（NaCl）简单来说是一种在浏览器中运行原生代码的技术。其技术原型类似于微软\u003Cdel>臭名昭著\u003C\u002Fdel>的ActiveX。与ActiveX那种毫无安全性的实现不同，NaCl采用了经过改进的基于软件的故障隔离（SFI）技术，并结合了ptrace等系统调用拦截工具，从而实现了在浏览器中安全运行原生代码的功能。从实现角度来看，首先会对代码进行静态检查，确保其符合NaCl制定的一些规则，随后将程序运行在一个沙箱中。原生代码与外界的所有通信，包括系统调用，都会被封装或拦截，以此来实现对原生代码的安全隔离。2009年，Google组织了一场Native Client安全竞赛，鼓励开发者寻找NaCl的漏洞。最终发现了20多个漏洞，但没有一个能够从根本上破坏NaCl的保护机制。目前，Google Chrome浏览器仍然支持以这种方式运行原生代码，不过似乎使用的人并不多。演示非常容易运行，感兴趣的话可以尝试一下，只需简单的步骤即可实现从CPP代码到Javascript代码的通信。\n\n为了提高浏览器中代码运行的效率，还有另一种做法，即[asm.js](http:\u002F\u002Fasmjs.org\u002F)。它的实现思路与NaCl完全不同，asm.js并不在浏览器中执行原生代码，因此无需考虑那么多安全问题，而是通过修改LLVM工具链，将原生代码编译成Javascript的一个子集，然后运行这个子集的Javascript代码。这种方法的性能最高只比原生应用慢一倍，虽然不如NaCl那样接近原生体验，但也可以接受。这正是Firefox浏览器所采用的路线。\n\n目前业界已经形成了相对统一的方案，即WebAssembly。WebAssembly与asm.js出自同一团队，得到了多家公司的支持。WebAssembly由asm.js团队和NaCl团队共同开发，其中NaCl团队更专注于安全方面，这也是他们的专长。因此可以说，Native Client这一功能可能已经被逐渐淘汰，但其安全相关的实现仍由原班人马为WebAssembly贡献力量。实际上，这篇论文的主题并非强调Native Client的实现有多好，而是着重说明它是如何做到安全的。依我看，asm.js的做法更为合理，因为它对系统的侵入性更小。\n\n#### 语言无关的沙箱(Language-Independent Sandboxing)\n\n[即时编译与自修改代码的语言无关沙箱](http:\u002F\u002Fciteseerx.ist.psu.edu\u002Fviewdoc\u002Fdownload?doi=10.1.1.207.6665&rep=rep1&type=pdf)\n\n```\n\u002F\u002F TODO 添加笔记\n```\n\n## 系统(System)\n\n### 文件系统\n\n#### RAMCloud\n\n[RAMCloud 中的快速崩溃恢复](http:\u002F\u002Fweb.stanford.edu\u002F~ouster\u002Fcgi-bin\u002Fpapers\u002Framcloud-recovery.pdf)\n\n> 为什么 RAMCloud 在 DRAM 中的数据采用日志结构化策略？\n\nRAMCloud 的备份机制并未完全依赖内存，而是同时在内存和硬盘上各保留一份备份。这种策略虽然节省了内存资源，但也带来了两个问题：\n\n* 备份速度较慢，可能影响系统的正常运行；\n* 系统崩溃后，恢复过程需要从硬盘读取数据，耗时较长。\n\n为了解决第一个问题，RAMCloud 采用了日志结构化策略。当请求到达内存时，会以日志形式记录，随后将日志条目分发到各个备份节点。各备份节点接收到条目后立即返回确认，再异步处理这些条目，从而实现了近似异步的操作。这样可以隐藏备份操作带来的开销。然而，这种方法也引入了新的风险：系统崩溃时，缓冲区中的数据可能尚未刷新到持久存储中。为弥补这一不足，文中提出了两种方案来确保数据一旦进入缓冲区即被持久化：一种是使用 DIMM 加超级电容器，另一种则是配备电池。\n\n综上所述，日志结构化的主要目的是解决同步备份过程中因存储层次结构带来的性能瓶颈问题。\n\n> RAMCloud 使用何种策略来放置段副本？恢复时如何定位这些段副本？\n\n传统的实现通常依赖中心化的协调器，这会导致性能瓶颈。因此，RAMCloud 采用了去中心化的思想，通过随机化和微调的方式分散备份。其做法类似于 k 选一的过程：首先随机选择若干个候选位置，再从中选出最优的一个，并引入拒绝机制以避免在乐观并发场景下产生竞争。此外，为了尽可能接近最优解，RAMCloud 还会考虑硬盘的访问速度以及当前硬盘上已有的段数量进行微调，从而实现更均匀的分布。\n\n在恢复阶段，传统方法同样依赖中心化的协调器维护一张全局表，这显然会成为性能瓶颈。为此，RAMCloud 在恢复时会向所有备份节点查询，每个备份节点会返回其所存储的副本列表。整个查询过程是并行的，且 RAMCloud 使用了自认为高效的 RPC 通信方式，因此恢复过程并不会特别缓慢。\n\n> RAMCloud 是否支持随机访问？如果支持，请说明其实现方式。\n\n支持。RAMCloud 在每个主节点上维护了一个哈希表，其结构为 `\u003C表标识符, 对象标识符>`，通过该哈希表可以实现高效的随机访问。\n\n#### 乐观崩溃一致性\n\n[乐观崩溃一致性](http:\u002F\u002Fresearch.cs.wisc.edu\u002Fadsl\u002FPublications\u002Foptfs-sosp13.pdf)\n\n这篇论文发表于 SOSP'13，主要工作是在基于日志的 Ext4 文件系统基础上，提出了一种乐观崩溃恢复方法。该方法能够在保证崩溃一致性的同时大幅提升性能。然而，计算机领域的任何性能提升都伴随着权衡：乐观崩溃一致性牺牲了数据的新鲜度。\n\n所谓崩溃一致性，是指文件系统在崩溃后，其内部数据是否仍然保持一致，尤其是元数据与实际数据之间的一致性。如果不一致，通常意味着硬盘丢失了部分数据，或者文件系统无法正确识别硬盘上的数据。\n\n在基于日志的文件系统中，一次写入磁盘的操作涉及四个部分：实际数据、日志中的元数据冗余、日志中的提交块以及最终的元数据更新。这四部分必须按顺序写入才能保证崩溃一致性。而要确保写入顺序，就需要借助磁盘的刷新操作，将数据从缓存强制写入物理磁盘。然而，这种强制刷新操作会显著降低性能。本文提出使用校验和、异步持久化通知和延迟写等技术，使文件系统无需强制刷新即可完成写入操作。不过，这种优化会牺牲数据的新鲜度：在 Ext4 中，崩溃后最多可能丢失一个事务的数据，而在本文提出的方案中，可能会丢失多个事务的数据。尽管如此，该方法的性能相比需要刷新的 Ext4 提升了 4 到 10 倍。\n\n#### F2FS\n\n[F2FS：面向闪存存储的新文件系统](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Ffast15\u002Ffast15-paper-lee.pdf)\n\n随着 NAND 闪存技术的发展，越来越多的持久化存储设备开始转向 SSD。然而，传统的文件系统大多针对 HDD 设计，未能充分利用闪存存储的硬件特性。本文提出了一种专为闪存设计的文件系统，目前已集成到 Linux 内核中。整篇论文内容偏工程化，阅读起来并不像其他文件系统论文那样晦涩。\n\n众所周知，闪存存储的读取速度非常快，且其工作原理与 HDD 不同——它并非依靠机械结构和磁头进行读写，而是基于电子方式，因此具有一定的并行性。与此同时，闪存存储的写入操作并不是原地修改，而是需要先写入新位置，再更新指针指向新位置。这一特性导致了“游走树”问题，这是日志结构化文件系统在 SSD 上常见的问题：由于闪存的写入是非原地操作，每次写入都会改变数据块的地址，从而需要递归地更新直接块、间接块等一系列数据结构。为了解决这个问题，F2FS 引入了一个新的表：节点地址表（NAT）。间接块指向 NAT，这样一来，当某个数据块被修改时，只需更新直接块和 NAT 中的条目，即可避免传播到间接块中。\n\n此外，为了充分利用闪存的并行性，F2FS 采用了多头日志机制，不再只使用一个日志，而是根据数据更新频率创建多个日志，从而提升了性能。\n\n#### PMFS\n\n* [面向持久性内存的系统软件](http:\u002F\u002Fesos.hanyang.ac.kr\u002Ffiles\u002Fcourseware\u002Fgraduate\u002FSystem_software\u002Fa15-dulloor.pdf)\n* [幻灯片](http:\u002F\u002Fembedded.dankook.ac.kr\u002F~choijm\u002Fcourse\u002F201501TOS\u002F0519_PMFS.pdf)\n\n目前出现了一种新型概念——非易失性内存（NVM），它是通过在内存中加入电容等方式实现持久性的技术。许多研究也在这一基础上设计文件系统，本文正是这样一种文件系统。\n\n惭愧的是，我对这篇文章的理解较为浅显，但可以简要介绍其大致实现。最令人印象深刻的是，该文件系统在保证一致性时采用了混合方式，结合了 COW、日志等多种技术。此外，它还引入了一种新的硬件原语，但由于理解不够深入，此处不便详述。\n\n### 操作系统\n\n#### Exokernel\n\n[Exokernel：面向应用级资源管理的操作系统架构](https:\u002F\u002Fpdos.csail.mit.edu\u002F6.828\u002F2008\u002Freadings\u002Fengler95exokernel.pdf)\n\n```\n\u002F\u002F TODO 添加笔记\n```\n\n### 内存\n\n#### 事务性内存\n\n* [事务性内存：无锁数据结构的架构支持](http:\u002F\u002Fwww.cs.utexas.edu\u002F~pingali\u002FCS395T\u002F2009fa\u002Flectures\u002Fherlihy93transactional.pdf)\n\n事务性内存并不是一个新概念，我从大二起就经常听到这个词，但一直未深入了解相关内容。这篇论文发表于 1993 年，是比较早期的关于硬件支持事务性内存的研究之一。如今，Intel Haswell 架构的 CPU 已经支持事务性内存，但相关应用仍相对较少。\n\n```c\n\u002F\u002F 临界区\nx=VALIDATE;\nif (x) {\n      COMMIT;\n} else {\n      ABORT;\n}\n```\n\n上述代码展示了事务性内存的一种编程范式：原本需要使用锁来实现同步的操作，现在都可以被视为一个事务，只有在事务提交时才会生效；若发生冲突，则事务会被中止，所有修改将被丢弃。\n\n本文基于嗅探型缓存一致性协议进行了改进，在硬件层面增加了一个名为 Tx Cache 的 L1 缓存。非事务性操作走常规缓存，而事务性操作则走 Tx Cache。\n\n事务缓存有四种状态：Normal、XCommit、XAbort 和 Empty。事务提交时，XCommit 变为 Empty，XAbort 变为 Normal；事务中止时，XAbort 变为 Empty，XCommit 变为 Normal。\n\n实际上，该实现利用了现有的缓存一致性协议来进行冲突检测。要理解这篇论文，必须对缓存一致性有较为清晰的认识。由于实现依赖于缓存，因此在发生上下文切换等需要刷新缓存的情况下，事务必然会被中止。因此，该实现主要适用于短临界区场景，且不涉及 I\u002FO 操作。\n\n不过，由于实现完全基于现有技术（缓存一致性），它可以与非事务性内存的同步操作并行执行，因为其他非事务性的操作同样会触发缓存操作。这也是该实现的一大优势，非常重要。\n\n### CFI\n\n#### 控制流完整性\n\n[控制流完整性：原理、实现与应用](https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fresearch\u002Fwp-content\u002Fuploads\u002F2005\u002F11\u002Fccs05.pdf)\n\n```\n\u002F\u002F TODO 添加笔记\n```\n\n### 尾部延迟\n\n#### 规模下的尾部延迟\n\n[Dean, Jeffrey, and Luiz André Barroso. \"The tail at scale.\" Communications of the ACM 56.2 (2013): 74-80.](https:\u002F\u002Fcacm.acm.org\u002Fmagazines\u002F2013\u002F2\u002F160173-the-tail-at-scale\u002Fabstract)\n\n> 为什么延迟的变异性会随规模扩大而加剧？\n\n这主要是由系统的特性决定的。文中举例说明：假设用户访问一台服务器，99% 的请求能在 10 毫秒内完成，而 1% 的请求则需要 1 秒。在这种情况下，单台服务器的延迟尚可接受。然而，如今大多数应用都需要多个服务协同工作，最终才将结果返回给用户。因此，用户感知到的延迟实际上是所有参与服务中延迟最长的那个值。由此可见，用户感知的延迟会随着系统规模的增大而升高。这里的“规模”指的是系统的复杂程度。\n\n请简要概述一些有效的尾部延迟容忍技术。\n\n例如，最简单的方法是使用多台服务器，每台服务器处理完全相同的逻辑，通过副本机制来降低延迟。用户的请求会被发送到所有服务器，任意一台服务器完成处理后即返回结果。这种方式要求应用程序能够处理幂等请求，同时也使得逻辑变得更加复杂。在此基础上还可以进一步优化，比如在某台服务器完成请求后，通知其他服务器停止处理相同的幂等请求等，但这无疑会增加实现难度。\n\n此外，还可以通过减少守护进程的方式来降低延迟，例如使用精简的内核如 unikernel 等，但这种方法的成本更高。\n\n为什么写操作更容易容忍延迟的变异性？\n\n这是因为写操作通常是异步的，且可以容忍一定程度的不一致。此外，在保证一致性的写操作中，通常会使用 Paxos、ZAB、Raft 等算法，而这些算法本身就具备尾部延迟容忍特性。\n\n### 锁\n\n#### 非可扩展的锁是危险的\n\n[非可扩展的锁是危险的，西拉斯·博伊德-维基泽、M·弗兰斯·卡什霍克、罗伯特·莫里斯和尼古拉伊·泽尔多维奇，《Linux研讨会论文集》。2012年。](https:\u002F\u002Fwww.kernel.org\u002Fdoc\u002Fols\u002F2012\u002Fols2012-zeldovich.pdf)\n\n>为什么票锁的性能会在核心数较少时急剧下降？（提示：缓存一致性协议）\n\n在票锁的实现中，维护着两个票变量：当前票和下一个票。在解锁操作中，会将当前票自增，从而使拿到下一个票的核心获得锁。\n\n凡是遵循文章中提出的硬件缓存一致性模型的系统，都会遇到票锁的快速崩溃问题。文章提出的硬件缓存一致性模型用目录的方式类比了CPU中的缓存，并且用马尔可夫链模型对票锁的问题进行了分析。其中每一个节点代表有几个核心处于等待状态，到达率和服务率分别代表了在不同状态下锁的获取和释放。其中到达率与未处于等待状态的核心数量(n - k)成正比，服务率则与处于等待状态的核心数量(k)成反比。因此，随着k的增大，服务率会逐渐降低。这使得模型得出了一个数学结论：锁的获取时间与正在等待锁的核心数量成正比。\n\n因此，随着核心数量的增加，在串行部分很小时，Sk = 1\u002F(s + ck\u002F2) 中k对Sk的贡献会越来越大，从而更容易受到k的影响。这就是为什么在串行部分很小的时候，仅仅多出几个等待锁的核心，就会导致性能的雪崩。\n\n>为什么MCS锁比票锁具有更好的可扩展性？\n\n在票锁中，所有核心都依赖同一个变量来获取锁；而在MCS锁中，前一个核心在释放锁时会修改下一个核心的locked变量，通知下一个核心来获取锁。这样每个锁都只依赖于属于自己的一个变量，这种实现方式与缓存一致性无关，因此具有更好的可扩展性。\n\n### Bug\n\n#### STACK\n\n[迈向优化安全的系统：分析未定义行为的影响](https:\u002F\u002Fpdos.csail.mit.edu\u002Fpapers\u002Fstack:sosp13.pdf)\n\n未定义行为是指编程语言规范对某段代码可能产生的某些执行结果未予定义。不稳定代码则是指在程序实际执行过程中，由于涉及未定义行为，从而无法被编译器翻译（直接略过）的代码段。\n\nSTACK会在假设Δ被允许和不允许的情况下分别模拟编译。\n\n* 先模拟假设不成立的情况进行一次编译；\n* 模拟假设成立的情况进行一次编译；\n* 查看前两步的执行结果有没有区别，有区别的地方就是不稳定代码。\n\n如果执行第二步时得不到准确的结果，那么会漏报一些不稳定代码；如果执行第一步时得不到准确的结果，就会产生误报（false warning \u002F false positive）。目前STACK给出的未定义行为模式可能并不齐全。\n\n对于程序员来说，可以通过修复bug或者去掉一些会被编译器视为未定义行为的代码；对于编译器来说，可以集成一些现有的bug-finding工具，或者利用STACK的方式来判定不稳定代码；同时完善编程语言的specification，定义更多的代码执行规则，减少未定义行为的产生。\n\nSTACK为了使可扩展性更高，在计算Δ = ∀e:Reach(e) → ¬Undef(e)的时候做了一些近似运算，使最后得到的结果可能会漏掉一些不稳定代码。STACK为了简化和滤过某些查询用到的constraint solver如果发生了timeout，也会出现漏报的情况。因此，STACK为了更好的扩展性，牺牲了一定的可靠性（精度）。\n\n## 安全(Security)\n\n### 虚拟机安全(Virtulization, Security)\n\n#### CloudVisor\n\n[CloudVisor：通过嵌套虚拟化为多租户云中的虚拟机提供保护](https:\u002F\u002Fwww.sigops.org\u002Fsosp\u002Fsosp11\u002Fcurrent\u002F2011-Cascais\u002Fprintable\u002F15-zhang.pdf)\n\n```\n\u002F\u002F TODO 添加注释\n```\n\n### Taint Tracing\n\n#### TaintDroid\n\n* [TaintDroid：用于智能手机实时隐私监控的信息流跟踪系统](http:\u002F\u002Fwww.appanalysis.org\u002Ftdroid10.pdf)\n* [智能手机上的实时隐私监控](http:\u002F\u002Fwww.appanalysis.org\u002F)\n\nTaint分析是指将一些敏感数据标注出来，在程序执行的过程中确保这些被标注的敏感数据不会被泄露出去的技术。TaintDroid是一个在Android上进行Taint分析的工具。之前的Taint分析工具开销非常大，而TaintDroid通过分层的思想，在不同层做不同粒度的Taint跟踪，大大降低了运行时的开销。\n\n论文有一个配套的demo，是可以运行的，感兴趣的话可以自己试试看，这里也有一个[Demo视频](https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=qnLujX1Dw4Y)。很有趣的是这篇论文是Intel Labs参与的，不是很懂他们怎么会想到做这样的事情。\n\n### ROP\n\n#### Hacking Blind\n\n* [Hacking Blind](www.scs.stanford.edu\u002F~sorbo\u002Fbrop\u002Fbittau-brop.pdf)\n* [【转载】盲式返回导向编程(BROP)攻击——攻击原理](http:\u002F\u002Fytliu.info\u002Fblog\u002F2014\u002F09\u002F28\u002Fblind-return-oriented-programming-brop-attack-gong-ji-yuan-li\u002F)\n\n这篇论文看上去就很酷，实现很让人亮眼。最简单的ROP，就是寻找一个个的gadget，然后把gadget连接起来。然后让控制流走到这些gadget里，就OK了。但是这篇论文是如何在远程来劫持控制流，来实现ROP攻击。攻击者不了解远程的系统，因此首先系统要有一个已知的stack overflow漏洞，然后要求攻击的进程在死了后会重启，而且ASLR后的地址不变。\n\n其实条件是很苛刻的，而且也不懂为什么一个攻击者可以在不了解远程系统的同时知道系统的stack overflow漏洞。整体攻击的过程，是先Dump服务器的内存，然后再进行常规的ROP，其中Dump内存的操作非常精巧，感觉只有ROP高级玩家才能想出这样的做法，具体可以看看上面链接的论文，是我们学院IPADS实验室的一个学长写的，很清楚。\n\n## 大数据\n\n### 框架\n\n#### Hadoop\n\n* [MapReduce：大型集群上的简化数据处理](https:\u002F\u002Fstatic.googleusercontent.com\u002Fmedia\u002Fresearch.google.com\u002Fzh-CN\u002F\u002Farchive\u002Fmapreduce-osdi04.pdf)\n* [Hadoop分布式文件系统](http:\u002F\u002Fpages.cs.wisc.edu\u002F~akella\u002FCS838\u002FF15\u002F838-CloudPapers\u002Fhdfs.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n#### Spark\n\n* [Spark：基于工作集的集群计算](https:\u002F\u002Fpeople.csail.mit.edu\u002Fmatei\u002Fpapers\u002F2010\u002Fhotcloud_spark.pdf)\n* [弹性分布式数据集：一种面向内存的集群计算容错抽象](https:\u002F\u002Fwww.usenix.org\u002Fsystem\u002Ffiles\u002Fconference\u002Fnsdi12\u002Fnsdi12-final138.pdf)\n\n```\n\u002F\u002F TODO 等待阅读\n```\n\n### 数据处理\n\n#### Facebook的实时数据处理\n\n* [Facebook的实时数据处理](http:\u002F\u002Fdblp.org\u002Frec\u002Fhtml\u002Fconf\u002Fsigmod\u002FChenWIJLSWWWY16)\n\n## 网络\n\n### 网络功能虚拟化(NFV)\n\n#### Click\n\n[Click模块化路由器，罗伯特·莫里斯、埃迪·科勒、约翰·詹诺蒂、M·弗兰斯·卡什霍克，SOSP 1999](https:\u002F\u002Fpdos.csail.mit.edu\u002Fpapers\u002Fclick:tocs00\u002Fpaper.pdf)\n\n>为什么Click必须同时提供push'和pull'两种方法？我们能否消除其中一种操作？如何\u002F为什么？\n\nPush和Pull是两种连接方式。Push是从源Element到下游的元素。在Push连接方式里，上游的元素会提交一个包给下游的元素。Pull是从目的地元素到上游元素。在Pull的连接方式里，是下游的元素发送包请求到上游的元素。Push和Pull的共同使用可以使包转发连接的适当终止，可以很好地解决路由器控制流问题。例如包调度的决定——选择哪个队列去请求一个包对于组合的Pull元素来说是非常容易实现的。另外，系统不应该向繁忙的转发接口发送包，否则，这个接口就必须存储包，并且路由器会失去处理这些包的能力（丢弃，修改优先级等）。这个约束可以由简单的给转发接口一个Pull输入实现。然后这个接口就可以控制包转发，并且可以在它准备好的时候请求包。\n\n>Click的一个局限性是难以在pull和push路径之间调度CPU时间。为什么这么困难？你会如何改进它？\n\nClick的调度器就是一个Pull Element，它有多个输出，而只有一个输入。至于CPU时间调度的问题，就是说Click没办法处理多个设备同时接收或发送数据的情况。目前的处理方法是linux处理大部分这样的调度，剩下的交由Click来做。最终所有这些都应该由一个单一的机制来控制。关于改进，可以将linux里相关的逻辑作为一个Element引入，不知是否可行。\n\n>如何将批处理应用到Click中？请具体说明，并考虑对延迟和吞吐量的影响。\n\nAPSys 2012上有一篇论文《Click模块化路由器中的批处理力量》，它尝试了psio、netmap、PF_ring等开源的IO batching工具，最后选择了psio。同时为了实现计算的批处理，它修改了现有的Click。\n\n这样做提高了吞吐量，但增加了延迟。这也跟批处理的程度有关，理论上来说是可以控制的。","# papers-notebook 快速上手指南\n\n`papers-notebook` 并非一个需要编译或安装的二进制软件工具，而是一个基于 GitHub 的**开源论文笔记知识库**。它主要记录了分布式系统、虚拟化、安全等领域的经典论文解读。\n\n开发者使用该项目的主要方式是：**阅读在线笔记**、**克隆仓库本地查阅**或**参与贡献（提交 Issue）**。以下是快速上手步骤。\n\n## 环境准备\n\n本项目无特殊系统依赖，只需具备基础的开发环境即可浏览源码或参与维护。\n\n*   **操作系统**：Windows \u002F macOS \u002F Linux 均可\n*   **前置依赖**：\n    *   [Git](https:\u002F\u002Fgit-scm.com\u002F)：用于克隆仓库\n    *   GitHub 账号：用于在 Issue 页面查看讨论或分享论文推荐\n    *   Markdown 阅读器（可选）：如 VS Code、Typora 或 GitHub 网页版，用于更好地渲染笔记内容\n\n> **国内加速建议**：\n> 如果访问 GitHub 速度较慢，建议使用国内镜像站克隆，或配置 Git 代理。\n> *   镜像源示例（以 Gitee 为例，若作者有同步）：`https:\u002F\u002Fgitee.com\u002Fmirror\u002Fpapers-notebook` (需确认作者是否同步)\n> *   通用加速：配置 `http.proxy` 或使用 [FastGit](https:\u002F\u002Ffastgit.org\u002F) 服务替换域名。\n\n## 安装步骤（获取项目）\n\n由于项目已不再通过 Markdown 文件维护核心笔记（转为 GitHub Issues），但仓库中仍保留了目录结构和部分历史内容。推荐直接克隆仓库到本地。\n\n### 1. 克隆仓库\n\n打开终端，执行以下命令：\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fgaocegege\u002Fpapers-notebook.git\n```\n\n**国内用户加速克隆方案**：\n如果直接克隆失败，可使用 FastGit 服务加速：\n\n```bash\ngit clone https:\u002F\u002Fhub.fastgit.org\u002Fgaocegege\u002Fpapers-notebook.git\n```\n\n### 2. 进入目录\n\n```bash\ncd papers-notebook\n```\n\n## 基本使用\n\n### 方式一：在线阅读与检索（推荐）\n\n项目核心内容已迁移至 GitHub Issues，这是获取高质量论文笔记的最快途径。\n\n1.  **浏览目录**：访问仓库首页的 `README.md`，查看按领域分类的目录（如分布式调度、虚拟化、存储等）。\n2.  **查看笔记**：点击目录中的链接，或直接访问 [Issues 列表](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002Fpapers-notebook\u002Fissues)。\n    *   每个 Issue 通常对应一篇论文的笔记（限制在 1000 字以内），包含核心 Idea、实现方式及评价。\n3.  **搜索论文**：利用 GitHub 顶部的搜索框，输入关键词（如 `Borg`, `Raft`, `RDMA`）快速定位相关笔记。\n\n### 方式二：本地查阅\n\n如果你希望离线阅读或整理自己的笔记：\n\n1.  使用支持 Markdown 的编辑器（如 VS Code）打开克隆后的目录。\n2.  阅读 `README.md` 获取整体知识图谱。\n3.  虽然最新笔记在 Issues 中，但你可以通过本地文件了解项目的分类逻辑，并基于此结构建立自己的笔记库。\n\n### 方式三：参与贡献（分享论文）\n\n作者欢迎社区分享值得一读的论文：\n\n1.  访问 [主讨论帖 (Issue #1)](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002Fpapers-notebook\u002Fissues\u002F1)。\n2.  在评论区留言，推荐你认为值得阅读的 Paper，格式可参考现有笔记风格（Idea + 实现 + 评价）。\n3.  或者针对特定论文新建 Issue 进行详细讨论（需遵循项目当前的维护规范）。\n\n---\n\n**核心资源直达**：\n*   📂 [GitHub 仓库主页](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002Fpapers-notebook)\n*   📝 [论文笔记列表 (Issues)](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002Fpapers-notebook\u002Fissues)\n*   💬 [论文推荐交流区](https:\u002F\u002Fgithub.com\u002Fgaocegege\u002Fpapers-notebook\u002Fissues\u002F1)","一位专注于分布式系统优化的研究生，正在为设计新型集群调度器而密集研读 Mesos、Omega 及 Borg 等经典论文。\n\n### 没有 papers-notebook 时\n- **知识碎片化严重**：阅读过的论文想法零散分布在本地不同的 Markdown 文件或纸质笔记中，缺乏统一索引，难以快速回顾如“两层调度”等核心架构演进。\n- **深度思考缺失**：往往只记录了论文的大致摘要，忽略了实现细节与个人批判性评价，导致在复现或对比算法时无法调用当时的灵感。\n- **交流协作困难**：面对庞大的文献列表，无法高效地向导师或同门分享值得精读的篇目，也难以在特定议题（如锁服务或一致性协议）上形成结构化的讨论基础。\n- **篇幅控制失控**：笔记容易写成冗长的翻译稿，缺乏\"1000 字以内”的精炼约束，导致复习成本极高，抓不住重点。\n\n### 使用 papers-notebook 后\n- **体系化知识沉淀**：利用其按分布式、虚拟化及安全等领域分类的目录结构，将 Mesos 到 Firmament 等调度器笔记有序归档，一键定位架构演变脉络。\n- **洞察即时固化**：遵循项目规范，在记录 Idea 的同时强制写入实现方式与个人评价，确保每一篇笔记都包含独特的技术洞察而非单纯复述。\n- **社区化协同增效**：通过 GitHub Issue 页面管理笔记并分享推荐清单，轻松与社区互动，快速获取他人对特定论文（如 TaintDroid 或 Raft）的深度解读。\n- **高效精炼输出**：受限于千字篇幅要求，迫使研究者提炼核心逻辑，生成的笔记既适合快速复习，也便于作为技术博客的素材库。\n\npapers-notebook 将孤立的论文阅读转化为结构化、可协作的知识资产，极大提升了从理论研读到系统设计的转化效率。","https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fdyweb_papers-notebook_4c65fae4.png","dyweb","Dongyue Studio","https:\u002F\u002Foss.gittoolsai.com\u002Favatars\u002Fdyweb_008ce16b.png","上海交通大学东岳网络工作室 Shanghai Jiao Tong University Dongyue Web Studio",null,"https:\u002F\u002Fdyweb.org","https:\u002F\u002Fgithub.com\u002Fdyweb",2201,253,"2026-04-13T12:30:39","Apache-2.0","","未说明",{"notes":90,"python":88,"dependencies":91},"该工具并非可执行的软件程序，而是一个用于记录论文阅读笔记的 GitHub 仓库。目前不再使用 Markdown 文件维护内容，而是迁移至 GitHub Issues 页面进行记录和分享。因此，该工具没有操作系统、GPU、内存、Python 版本或依赖库等运行环境需求，仅需拥有访问 GitHub 的网络环境即可。",[],[18],[94,95,96,97],"paper","notes","computer-system","operating-system","2026-03-27T02:49:30.150509","2026-04-20T04:05:15.581523",[101,106,110,115,120,125,130,134],{"id":102,"question_zh":103,"answer_zh":104,"source_url":105},43714,"MLSys 会议主要涵盖哪些主题，对从业者有什么价值？","MLSys 是机器学习与系统领域的顶级会议，涵盖面向 ML 的硬件系统、软件系统以及超越预测准确性的优化指标。该会议吸引了学术界和工业界（如 Google、Microsoft）的广泛关注，适合 Kubeflow 等项目的贡献者学习。论文指出的关键研究方向包括：1. 软件层面：简化 ML 程序编写、性能度量、部署\u002F监控\u002F调试\u002F维护；2. 硬件层面：精度与稳定性的权衡、支持训练\u002F服务的分布式系统、专用异构硬件；3. 其他指标：各类约束条件下的优化。","https:\u002F\u002Fgithub.com\u002Fdyweb\u002Fpapers-notebook\u002Fissues\u002F209",{"id":107,"question_zh":108,"answer_zh":109,"source_url":105},43715,"为什么某些论文链接显示需要权限或无法访问？","部分分享的论文链接可能指向私人仓库或受限制的存储库，导致普通用户无法直接访问或添加标签。如果遇到这种情况，通常是因为资源设置为私有，建议直接在学术搜索引擎或会议官网（如 USENIX, ArXiv）搜索论文标题获取公开版本。",{"id":111,"question_zh":112,"answer_zh":113,"source_url":114},43716,"如何高效组织仓库中的论文笔记，避免 README 文件过于庞大？","推荐使用 GitHub Issues 作为主要的组织方式。Issues 支持标签（Tag）分类和在线编辑，无需维护复杂的目录结构。可以采用“旧内容保留在 README，新内容通过 Issue 管理”的过渡策略，利用 Issue 的搜索和筛选功能提高检索效率。","https:\u002F\u002Fgithub.com\u002Fdyweb\u002Fpapers-notebook\u002Fissues\u002F7",{"id":116,"question_zh":117,"answer_zh":118,"source_url":119},43717,"提交新论文 Issue 前需要注意什么以避免重复？","在创建新 Issue 前，务必先搜索现有的 Issue 列表。数据显示大量关于 GPU 集群调度（如 Nexus, Multi-tenant GPU Clusters）、数据中心调度（如 Kairos, Learning Scheduling Algorithms）以及存储系统（如 Facebook Photo Storage）的论文已被多次提交。如果发现重复，应直接在原有 Issue 下讨论，而不是新建条目。","https:\u002F\u002Fgithub.com\u002Fdyweb\u002Fpapers-notebook\u002Fissues\u002F258",{"id":121,"question_zh":122,"answer_zh":123,"source_url":124},43718,"有哪些关于大规模 GPU 集群调度和深度学习的经典论文推荐？","该领域有多篇高价值论文被讨论，包括：1. 'Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads' (ArXiv:1901.05758)；2. 'Multi-tenant GPU Clusters for Deep Learning Workloads: Analysis and Implications' (Microsoft Research)；3. 'Learning Scheduling Algorithms for Data Processing Clusters' (ArXiv:1810.01963)。这些论文深入分析了多租户环境下的 GPU 资源分配与调度算法。","https:\u002F\u002Fgithub.com\u002Fdyweb\u002Fpapers-notebook\u002Fissues\u002F131",{"id":126,"question_zh":127,"answer_zh":128,"source_url":129},43719,"有没有关于无需运行时估算即可进行抢占式调度的研究？","有的，可以参考论文 'Kairos: Preemptive Data Center Scheduling Without Runtime Estimates'。该研究提出了一种不需要预先知道任务运行时间的抢占式数据中心调度方案，解决了传统调度器依赖不准确运行时估算的问题。注意该议题在仓库中曾有重复提交，请查阅相关合并后的讨论。","https:\u002F\u002Fgithub.com\u002Fdyweb\u002Fpapers-notebook\u002Fissues\u002F90",{"id":131,"question_zh":132,"answer_zh":133,"source_url":119},43720,"Facebook 的海量照片存储系统是如何设计的？","可以参考 OSDI 2010 的经典论文 'Finding a Needle in Haystack: Facebook's Photo Storage'。该文详细介绍了 Facebook 如何通过自定义文件系统（Haystack）来高效存储和检索数十亿张照片，优化了小文件读写性能。这是大规模分布式存储领域的必读文献。",{"id":135,"question_zh":136,"answer_zh":137,"source_url":138},43721,"OSDI 2016 有哪些值得关注的集群调度系统论文？","OSDI 2016 上发表的 'Firmament: Fast, Centralized Cluster Scheduling at Scale' 非常值得关注。该论文介绍了一种快速、集中的大规模集群调度系统，通过流网络模型解决调度问题，在保持高利用率的同时实现了低延迟调度。","https:\u002F\u002Fgithub.com\u002Fdyweb\u002Fpapers-notebook\u002Fissues\u002F4",[]]