实现的模式:
透明代理: 即用户访问时,已经给我们响应的就是服务器,其实可能是以下这些,这种就属于对用户透明的.
而且中间的转发控制器就成为网络的中心。如下：
LVS的NAT模型,
Haproxy, Nginx的反向代理
旁路代理
LVS的DR模型
名称服务模式:
DNS: 用户仅第一次访问时,需要查询,DNS通过名称给客户端反馈不同的解析IP,实现调度控制。
规则服务模式:
规则服务器:在数据库服务中,当数据库很大时,需要分库，分表时，就需要规则服务器在中间做为一个向导，
告诉第一次访问数据的客户端，你需要的数据是分散在多个主机上，还是一个节点上。
Master/Slave机制:
Master能够处理所有请求,Slave仅做为运算器分担部分读运算任务，Master需要控制给Slave发送数据，
所以Master也是一种控制器。
运算器的变化: 【暂时理解不深】
存储器的变化： 【暂时理解不深】
分布式系统实现的难点:
1.缺乏全局时钟: 在单机中,CPU的每秒中能产生很多个时钟频率，但是其它部件的功能频率相对与CPU来说是极慢的，为了达到步调一致，单机内部通过中断等机制实现协同工作。
2.面对故障时的独立性
3.处理单点故障
4.事务处理:
ACID
2PC(两段式提交)、BASE、CAP、Paxos(帕克索斯:希腊神话中的天马)
大型网站站点的架构演进方式:
LAMT, LNMT(Tomcat)
应用从资源占用的角度分两类:
CPU Bound: CPU密集型，ApplicationServer对CPU占用多。
IO Bound: IO密集型， 数据库对IO占用多。
网站从最开始一台主机上运行一个Nginx代理 + Tomcat应用服务器 + MySQL数据库.
当网站访问量增大时，首先出现告警的可能是MySQL数据库，因为磁盘I/O天生是系统的瓶颈,因此数据库先被分离出来，这样数据库压力就变小了。
引入MySQL主从面临的问题:
1. 数据复制的问题
2. 应用选择数据源的问题
接着网站访问量继续增大，Tomcat这类应用服务器，Nginx代理等都属于CPU密集型，它们在单机上出现了CPU资源争用的问题，这仅是小问题，更重要的是应用服务器出现了数据访问的热区，基本上会遵循二八定律，这时就必须分离，并且增加应用服务器，你的系统就变成了两台应用服务器，这时前端必须有一个反向代理，所以加上MySQL就是四台主机.但应用服务器分开后，就需要用户访问的会话保存问题，有以下三种解决方案:
Session sticky:会话粘性，存在单点故障，一定其中一台Server宕机，会话将丢失。
ip based：
cookie based:它带来的额外问题是，带宽占用将非常巨大，若一个cookie仅50字节,但是若一天一亿个请求,就有一亿个50字节,有多大？
Session replication: 会话复制，不适合大规模使用，因为一方面会消耗Server的内存，另一方会带来大量的内网同步Session的流量,影响整体网络环境。
Session server：通过Memcached来集中存储用户会话，扩展性好，适合大规模扩展。
若考虑到网站在一年内可能出现几何增长的可能，如:从200并发到过万的并发，这时使用前两种会话保存就不合适了，就必须使用第三种方案。