系统基础
分布式一致性
一个分布式系统无论在CAP三者之间如何权衡，都无法彻底放弃一致性（Consistency），如果真的放弃一致性，那么就说明这个系统中的数据根本不可信，数据也就没有意义，那么这个系统也就没有任何价值可言。
CAP理论
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
参考：分布式系统的CAP理论
BASE理论
BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。
BASE是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。
基本可用（Basically Available）
基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
软状态（ Soft State）
软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。
最终一致性（ Eventual Consistency）
最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
参考：分布式系统的BASE理论
通常情况下，我们所说的分布式一致性问题通常指的是数据一致性问题。在分布式系统中，数据一致性往往指的是由于数据的复制，不同数据节点中的数据内容是否完整并且相同。
如何能既保证数据一致性，又保证系统的性能，是每一个分布式系统都需要重点考虑和权衡的。一致性模型可以在做这些权衡的时候给我们很多借鉴和思考。
强一致性
当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。但是这种实现对性能影响较大。
弱一致性
系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。但会尽可能保证在某个时间级别（比如秒级别）之后，可以让数据达到一致性状态。
最终一致性
弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS是一个典型的最终一致性系统。
最终一致性模型的变种
因果一致性：如果A进程在更新之后向B进程通知更新的完成，那么B的访问操作将会返回更新的值。如果没有因果关系的C进程将会遵循最终一致性的规则。
读己所写一致性：因果一致性的特定形式。一个进程总可以读到自己更新的数据。
会话一致性：读己所写一致性的特定形式。进程在访问存储系统同一个会话内，系统保证该进程读己之所写。
单调读一致性：如果一个进程已经读取到一个特定值，那么该进程不会读取到该值以前的任何值。
单调写一致性：系统保证对同一个进程的写操作串行化。
参考：关于分布式一致性的探究
响应式编程
响应式扩展Rx
响应式函数编程
响应式命令编程
函数响应式编程
资源调度策略
资源调度是指在一个规模集群内调度管理规模硬件集群的CPU、GPU、内存、磁盘和网络等资源的方案策略。当前主要有三种策略：一体化调度、两级调度和共享状态调度，如下图所示：
CURL
DC/OS系统自带了CURL，而且DC/OS系统内部大量使用了CURL。因此理解CURL的功能和作用是必要的。在访问HTTPS目标地址时，CURL默认会校验服务器证书。DC/OS中CURL使用的证书存放位置位于：
/opt/mesosphere/active/python-requests/lib/python3.5/site-packages/requests/cacert.pem参考：CURL常用命令