分布式的前提，我们得有多台服务器，那么我们需要知道世界上第一台计算机的由来，而第一台计算机的参考模型就是冯诺依曼模型，为此奠定了所有的分布式都在围绕着这个模型里面的某一块或者相互之间模块进行打交道。
搞分布式又有什么意义呢？
1.升级单机处理能力的性价比越来越低
单机的处理能力主要依靠CPU、内存、磁盘。通过更换硬件 做垂直扩展的方式来提升性能，成本会越来越高。
2. 单机处理能力存在瓶颈
单机处理能力存在瓶颈， CPU、内存都会有自己的性能瓶颈， 也就是说就算你是土豪不惜成本去提升硬件，但是硬件的发 展速度和性能是有限制的
3. 稳定性和可用性这两个指标很难达到
单机系统存在可用性和稳定性的问题，这两个指标又是我们 必须要去解决的
分布式架构的常见概念
集群
小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人 多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能 炒一样的菜，这两个厨师的关系是集群
分布式
为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切 菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师 也忙不过来了，又请了个配菜师，两个配菜师关系是集群
节点
节点是指一个可以独立按照分布式协议完成一组逻辑的程序 个体。在具体的项目中，一个节点表示的是一个操作系统上的 进程。
副本机制
副本(replica/copy)指在分布式系统中为数据或服务提供的冗 余。 数据副本指在不同的节点上持久化同一份数据，当出现某一个 节点的数据丢失时，可以从副本上读取到数据。数据副本是分 布式系统中解决数据丢失问题的唯一手段。 服务副本表示多个节点提供相同的服务，通过主从关系来实现 服务的高可用方案
中间件
中间件位于操作系统提供的服务之外，又不属于应用，他是位 于应用和系统层之间为开发者方便的处理通信、输入输出的一 类软件，能够让用户关心自己应用的部分。
架构的演进过程
阶段一，单应用架构
阶段二，应用服务器和数据库服务器分离
阶段三、应用服务器集群-应用服务器负载告警，如何让应用服 务器走向集群
各种问题也会慢慢呈现
- 用户请求由谁来转发到具体的应用服务器
- 用户如果每次访问到的服务器不一样，那么如何维护 session
阶段四，数据库压力变大，数据库读写分离
这个架构的变化会带来几个问题
1. 主从数据库之间的数据同步 ； 可以使用 mysql 自带的 master-slave方式实现主从复制
2. 对应数据源的选择 ； 采用第三方数据库中间件，例如mycat
阶段五，使用搜索引擎缓解读库的压力
阶段六，引入缓存机制缓解数据库的压力
阶段七，数据库的水平/垂直拆分
垂直拆分：把数据库中不同业务数据拆分到不同的数据库
水平拆分：把同一个表中的数据拆分到两个甚至跟多的数据库中， 水平拆分的原因是某些业务数据量已经达到了单个数据库的瓶颈， 这时可以采取讲表拆分到多个数据库中
阶段八，应用的拆分
这样拆分以后，可能会有一些相同的代码，比如用户操作，在商品 和交易都需要查询，所以会导致每个系统都会有用户查询访问相关 操作。这些相同的操作一定是要抽象出来，否则就会是一个坑。所 以通过走服务化路线的方式来解决
那么服务拆分以后，各个服务之间如何进行远程通信呢？ 通过RPC技术，比较典型的有：webservice、hessian、http、RMI 等等 前期通过这些技术能够很好的解决各个服务之间通信问题，but， 互联网的发展是持续的，所以架构的演变和优化还在持续。
什么是分布式架构下的高可用设计 ？
1. 避免单点故障
a) 负载均衡技术（failover/选址/硬件负载/ 软件负载/去中心化的软件负载（gossip(rediscluster)））
b) 热备（linux HA）
c) 多机房（同城灾备、异地灾备）
2. 应用的高可用
a) 故障监控（系统监控（cpu、内存） /链路监控/日志监 控） 自动预警
b) 应用的容错设计、 （服务降级、限流）自我保护能力
c) 数据量（数据分片、读写分离）
附录：分布式架构的基本理论 CAP、BASE 以及应 用
CAP理论告诉我们：一个分 布式系统不可能同时满足一致性（C：Consistency）、可用 性（ A：Availability）和分区容错性（P：Partition tolerance） 这三个基本需求，最多只能同时满足其中两项。
一致性：所有节点上的数据时刻保持同步
可用性：每个请求都能接收一个响应，无论响应成功或失 败
分区容错：系统应该持续提供服务，即时系统内部（某个 节点分区）有消息丢失。比如交换机失败、网址网络被分 成几个子网，形成脑裂；服务器发生网络延迟或死机，导 致某些server与集群中的其他机器失去联系
CAP并不是一个普适性原理和指导思想，它仅 适用于原子读写的NoSql场景中，并不适用于数据库系统。
BASE 全称 是Basically available,soft-state,Eventually Consistent. 系统基本可用、软状态、数据最终一致性。
Basically available（基本可用），在分布式系统出现不可预 知的故障时，允许瞬时部分可用性
soft-state（软状态）. 表示系统中的数据存在中间状态，并 且这个中间状态的存在不会影响系统的整体可用性，也就 是表示系统允许在不同节点的数据副本之间进行数据同步 过程中存在延时
Eventually consistent（数据的最终一致性），表示的是所有 数据副本在一段时间的同步后最终都能达到一个一直的状 态，因此最终一致性的本质是要保证数据最终达到一直， 而不需要实时保证系统数据的强一致
BASE理论的核心思想是：即使无法做到强一致性，但每个 应用都可以根据自身业务特点，采用适当的方式来使系统 达到最终一致性
