应用架构、CAP理论
一、软件架构
1.1 单一应用架构
当网站流量很小，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
1.2 垂直应用架构
当访问量主键增大，单一应用增加机器带来的加速度越来越小，将应用拆分成互不干扰的几个应用，以提升效率。
1.3 分布式服务架构
当垂直应用越来越多，应用之间的交互不可避免，将核心业务抽取出来，作为独立应用，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的需求。
二、分布式系统带来的问题
2.1 分布式session
session粘滞
即粘性 session，当用户访问集群中的某台机器后，强制指定后续的所有请求均落在此机器上。
使用场景：机器数量适中、对稳定性要求不是非常严格。
优点：实现简单、配置方便、没有额外的网络开销。
缺点：网络中有宕机时，用户 session 会丢失，容易造成单点故障。
方案：Nginx 的 ip_hash 负载均衡方案。
session复制
将一台机器上的 session 数据广播复制到集群中其余的机器上。
使用场景：机器较少、网络流量小。
优点：实现简单、配置方便、当网络中有宕机时不影响用户访问。
缺点：广播式复制到其他机器有一定的网络延迟，带来一定的网络开销。
方案：开源方案 tomcat-redis-session-manager，暂不支持 tomcat8。
缓存集中式管理
将 session 存入分布式缓存中的某台机器上，当用户访问不同的节点时先从缓存中拿 session 信息。
使用场景：集群中机器数量较多、网络环境复杂。
优点：可靠性好。
缺点：实现复杂、稳定性依赖于缓存的稳定性、session 信息放入缓存时要有合理的策略写入
方案：开源方案 Spring-Session，也可以自己实现，主要是重写 HttpServletRequestWrapper 中的 getSession() 方法。
2.2 分布式配置中心
每一个大型分布式系统都应该有一个配置中心。
开源解决方案：
- disconf
- diamond
- doozer
- etcd
- zookeeper
2.3 分布式事务、分布式锁
常见的分布式锁实现方案
- mysql（数据库）
- redis、memcached（内存数据库等）
- zookeeper
CAP理论
一个分布式系统最多只能同时满足：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance） 这三项中的两项。
一致性
一致性分为：强一致性、弱一致性、最终一致性。
可用性
可用性：指服务一直可用，且是正常的响应时间。
分区容错性
分区容错性：指分布式系统在遇到某节点或网络故障时，仍然能够对外提供满足一致性和可用性的服务。
BASE理论
BASE 理论指：基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency）。
BASE 理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性，但应用可以采用合适的方式达到最终一致性。
基本可用
指分布式系统出现故障时，允许损失部分可用性，保障核心可用。
软状态
指允许系统存在中间状态，而该中间状态不影响系统整体的可用性。分布式存储系统中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。
最终一致性
指系统中所有数据副本经过一段时间后，最终能够达到一致的状态。
2.4 一致性算法和协议
由于 BASE 理论需要在一致性和可用性方面做出权衡，因此出现了很多一致性算法和协议：
- 两阶段提交
- 三阶段提交
- Paxos算法
- Zab协议