这里讨论一下分布式应用的一些点。

Scale up还是Scale out?

当单机模式无法满足高并发用户量时，这时需要考虑系统扩容，扩容通常有Scale up和Scale out两种做法，两种扩容的方式分别从两个维度来解决系统访问压力。

Scale up就是纵向扩容，通过增加单机的硬件配置来解决访问压力，Up模式实施成本较高，大到一定压力之后，终究会遇到硬件瓶颈，而且有单点问题。

Scale out就是横向扩容，使用一组普通的服务器搭建服务器集群，构建分布式应用架构、分布式数据库等来解决访问压力。Out模式更加经济、更具扩展性、更加可靠。

构建分布式应用

构建高可用的分布式应用通常需要解决几个问题：

各子系统之间的通信方式:

跨语言通信方案:

数据设计与数据库的选择是系统设计的重要一步。数据库从大类上分为关系型数据库(RDBMS)和非关系型数据库(NoSQL)，RDBMS代表产品有Oracle, MySQL, PostgreSQL等，RDBMS遵循ACID原则:

NoSQL数据库泛指非关系型数据库，NoSQL有如下几类:

各种数据库的排名可以参考: https://db-engines.com/en/ranking

在分布式系统里，有可能需要设计分布式数据库，需要考虑数据分片、数据同步、数据一致性、分布式事务等。

主要有三种：

Strong Consistency（强一致性）：新的数据一旦写入，在任意副本任意时刻都能读到新值。比如：文件系统，RDBMS，Azure Table都是强一致性的。
Week Consistency（弱一致性）：不同副本上的值有新有旧，需要应用方做更多的工作获取最新值。比如Dynamo。
Evantual Consistency（最终一致性）：一旦更新成功，各副本的数据最终将达到一致

以及其他一些变体：

Causal Consistency（因果一致性）：如果Process A通知Process B它已经更新了数据，那么Process B的后续读取操作则读取A写入的最新值，而与A没有因果关系的C则可以最终一致性。
Read-your-writes Consistency（读你所写一致性）：如果Process A写入了最新的值，那么 Process A的后续操作都会读取到最新值。但是其它用户可能要过一会才可以看到。
Session Consistency（会话一致性）：一次会话内一旦读到某个值，不会读到更旧的值。
Monotonic Read Consistency（单调一致性）：一个Process 一旦读到某个值，不会读到比这个值更旧的值，其他Process 不一定。
Monotonic Write onsistency（单调写一致性）:来自同一Process 的写操作被顺序地执行

其中最重要的变体是第二条：Read-your-Writes Consistency。特别适用于数据的更新同步，用户的修改马上对自己可见，但是其他用户可以看到他老的版本。Facebook的数据同步就是采用这种原则。

CAP理论: Consistency, Availability, Partition Tolerance, 任何分布式系统在可用性、一致性、分区容错性方面，不能兼得，最多只能得其二
consistent hashing [with virtual node]：一致性哈希，数据分布
vector clock：时钟向量，多版本数据修改
Quorum W+R>N [with vector clock]：抽屉原理，数据一致性的另一种解决方案。时钟向量，多版本数据修改。
Merkle tree [with anti-entropy]：数据复制
MVCC：copy-on-write与snapshot
2PC/3PC：分布式事务
Paxos：强一致性协议, Zookeeper是Fast Paxos算法基础的开源实现
Symmetry and Decentralization：对称性和去中心化。对称性(symmetry)简化了系统的配置和维护。去中心化是对对称性的延伸，可以避免master单点，同时方便集群scale out。
Map-Reduce：分而治之；移动数据不如移动计算。将计算尽量调度到与存储节点在同一台物理机器上的计算节点上进行，这称之为本地化计算。本地化计算是计算调度的一种重要优化。
Gossip协议：节点管理
Lease机制