分布式架构的基本理论及应用
分布式一致性
对于不同业务的产品，我们对数据一致性的要求 是不一样的，比如12306要求的是数据的严格一致性，而银行转账要求的是数据的最终一致性，所以，用户在使用不同的产品的时候对数 据一致性的要求是不一样的 。
在分布式系统中要解决的一个重要问题就是数据的复制，因为数据库复制期间存在延时。
所谓的分布式一致性问题，是指在分布式环境中引入数据 复制机制之后，不同数据节点之间 可能出现的，并无法依 靠计算机应用程序自身解决的数据不一致的情况。简单讲， 数据一致性就是指在对一个副本数据进行更新的时候，必 须确保也能够更新其他的 副本，否则不同副本之间的数据 将不一致。如果是因为网络延迟导致的问题，可以把同 步动作进行阻塞，用户在查询的时候必须要等到数据同 步完成以后再来做。但是这个方案带来的问题是性能会受到非常大的影响。如果同步的数据比较多或者比较频繁，那么因为阻塞操作可能将导致整个新系统不可用的情况。
所以没有办法找到一种能够满足数据一致性、 又不影响系统运行的性能的方案，因此这里就产生了一个一致性的级别：
- 强一致性：这种一致性级别是最符合用户直觉的，它要 求系统写入什么，读出来的也会是什么，用户体验好，但 实现起来往往对系统的性能影响大
- 弱一致性：这种一致性级别约束了系统在写入成功后， 不承诺立即可以读到写入的值，也不久承诺多久之后数据 能够达到一致，但会尽可能地保证到某个时间级别（比如 秒级别）后，数据能够达到一致状态
- 最终一致性：最终一致性是弱一致性的一个特例，系统 会保证在一定时间内，能够达到一个数据一致的状态。这 里之所以将最终一致性单独提出来，是因为它是弱一致性 中非常推崇的一种一致性模型，也是业界在大型分布式系 统的数据一致性上比较用的多的模型。
CAP 理论
是一个经典的分布式系统理论。它告诉我们：一个分 布式系统不可能同时满足一致性（C：Consistency）、可用 性（ A：Availability）和分区容错性（P：Partition tolerance） 这三个基本需求，最多只能同时满足其中两项。CAP理论在互联网界有着广泛的知名度，也被称为“帽子理论”。
一致性：所有节点上的数据时刻保持同步。
可用性：每个请求都能接收一个响应，无论响应成功或失 败。
分区容错：系统应该持续提供服务，即使系统内部（某个 节点分区）有消息丢失。比如交换机失败、网址网络被分 成几个子网，形成脑裂；服务器发生网络延迟或死机，导 致某些server与集群中的其他机器失去联系 等。
分区是导致分布式系统可靠性问题的固有特性，从本质上 来看，CAP理论的准确描述不应该是从3个特性中选取两 个，所以我们只能被迫适应，根本没有选择权； CAP并不是一个普适性原理和指导思想，它仅 适用于原子读写的NoSql场景中，并不适用于数据库系统。
BASE 理论
从前面的分析中知道：在分布式（数据库分片或分库存在 的多个实例上）系统下，CAP理论并不适合数据库事务（因 为更新一些错误的数据而导致的失败，无论使用什么样的 高可用方案都是徒劳，因为数据发生了无法修正的错误）。 此外 XA 事务虽然保证了数据库在分布式系统下的 ACID （原子性、一致性、隔离性、持久性）特性，但也带来了一 些性能方面的代价，对于并发和响应时间要求比较高的电 商平台来说，是很难接受的。
BASE 全称 是Basically available,soft-state,Eventually Consistent. 指的是系统基本可用、软状态、数据最终一致性。相对于CAP来 说，它大大降低了我们对系统的要求。
Basically available（基本可用），在分布式系统出现不可预 知的故障时，允许瞬时部分可用性 ，如在淘宝上搜索商品的时间由1秒变成3秒；再比如数据库采用分片模式，100W 个用户数据分在 5 个数据库实例上，如果破坏了一个实例，那么可用性是有80%的用户都可以登录，系统仍然可用； 电商大促时，为了应对访问量激增，部分用户可能会被 引导到降级页面，服务层也可能只提供降级服务。这就 是损失部分可用性的体现。
soft-state（软状态）. 表示系统中的数据存在中间状态，并 且这个中间状态的存在不会影响系统的整体可用性，即系统允许在不同节点的数据副本之间进行数据同步 过程中存在延时； 比如订单状态的待支付、支付中、 支付成功、支付失败，支付中就是一个中间状态，这 个中间状态在支付成功以后，在支付表中的状态同步给订 单状态之前，中间会存在一个时间内的不一致。
Eventually consistent（数据的最终一致性），表示的是所有 数据副本在一段时间的同步后最终都能达到一个一直的状 态，因此最终一致性的本质是要保证数据最终达到一致， 而不需要实时保证系统数据的强一致 。
BASE理论的核心思想是：即使无法做到强一致性，但每个 应用都可以根据自身业务特点，采用适当的方式来使系统 达到最终一致性 。
分布式架构下的高可用设计
- 避免单点故障
a) 负载均衡技术（failover/选址/硬件负载/ 软件负载/去中心化的软件负载（gossip(rediscluster)））
b) 热备（linux HA）
c) 多机房（同城灾备、异地灾备） - 应用的高可用性
a) 故障监控（系统监控（cpu、内存） /链路监控/日志监 控） 自动预警
b) 应用的容错设计、 （服务降级、限流）自我保护能力
c) 数据量（数据分片、读写分离）
分布式架构下的可伸缩设计
垂直伸缩 ：提升硬件能力
水平伸缩 ：增加服务器
3.加速静态内容访问速度的 CDN
CDN是Content Delivery Network的缩写，表示的是内容 分发网络。CDN的作用是把用户需要的内容分发到离用户 最近的地方，这样可以使用户能够快速获取所需要的内容。
CDN其实就是一种网络缓存技术，能够把一些相对稳定的 资源放到距离最终用户较近的地方，一方面可以节省整个广域网的带宽消耗，另外一方面可以提升用户的访问速度， 改进用户体验。我们一般会把静态的文件（图片、脚本、静 态页面）放到CDN中，如图所示：
- 当用户点击网站页面上的内容URL，经过本地DNS系统解析，DNS系统会最终将域名的解析权交给 CNAME 指向的 CDN 专用 DNS 服务器
- CDN的DNS服务器将CDN的全局负载均衡设备IP地址返回用户
- 用户向CDN的全局负载均衡设备发起内容URL访问请求
- CDN全局负载均衡设备根据用户IP地址，以及用户请求的内容URL，选择一台用户所属区域的区域负载均衡设备，告诉用户向这台设备发起请求。
- 区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务，选择的依据包括：根据用户IP地址，判断哪一台服务器距用户最近；根据用户所请求的 URL 中携带的内容名称，判断哪一台服务器上有用户所需内容；查询各个服务器当前的负载情况，判断哪一台服务器
尚有服务能力。基于以上这些条件的综合分析之后，区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的IP地址 - 全局负载均衡设备把服务器的IP地址返回给用户 用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容传送到用户终端。如果这台缓存服务器上并没有用户想要的内容，而区域均衡设备依然将它分配给了用户，那么这台服务器就要向它的上一级缓存服务器请求内容，直至追溯到网站的源服务器将内容拉到本地。
什么情况下用 CDN
最适合的是那些不会经常变化的内容，比如图片， JS文件， CSS 文件，图片文件包括程序模板中的，CSS 文件中用到 的背景图片，还有就是作为网站内容组成部分的那些图片， 都可以；
灰度发布
我们的应用虽然经过了测试部门的测试，但是仍然很难全 面覆盖用户的使用场景，为了保证万无一失，我们在进行发布的时候一般会采用灰度发布，也就是会对新应用进行 分批发布，逐步扩大新应用在整个集群中的比例直到最后 全部完成。灰度发布是针对新引用在用户体验方面完全无 感知。 灰度发布系统的作用是可以根据自己的配置，来将用 户的流量导到新上线的系统上，来快速验证新的功能修改， 而一旦出问题，也可以马上的恢复，简单的说，就是一套 A/BTest系统．
