一、分布式架构
简单来说：在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。
二、分布式服务应用会面临哪些问题？
2.1 理解1
(1)当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
(2)当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
(3)接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
(4)服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？?
(5)一个服务有多个业务消费者，如何确保服务质量？(6)随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？?
2.2理解2
1、通信异常
从集中式向分布式演变的过程中，必然引入网络因素，由于网络本身的不可靠性，因此也引入了额外的问题。分布式系统需要在各个节点之间进行网络通信，因此每次网络通信都会伴随着网络不可用的风险，网络光纤、路由器或是DNS等硬件设备或 是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。另外，即使分布式系统各个节点之间的网络通信能够正常进行，其延时也会大于单机操作。通常 我们认为现代计算机体系结构中，单机内存访问的延时在纳秒数量级（通常是10ns），而正常的一次网络通信的延迟在0.1~1ms左右（相当于内存访问延 时的105倍），如此巨大的延时差别，也会影响到消息的收发过程，因此消息丢失和消息延迟变得非常普遍；
2、网络分区
当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够正常通信，而另一些节点则不能----我们将这个现象称为网络分区。当网络分区出现时，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式系统才能完成的功能，包括对数据的事务处理，这就对分布式一致性提出了非常大的挑战；
3、三态
上面两点，我们已经了解到在分布式环境下，网络可能会出现各式各样的问题，因此分布式系统的每一次请求与响应，存在特有的三态概念，即成功、失败、超时。在传统的单机系统中，应用程序在调用一个函数之后，能够得到一个非常明确的响应：成功或失败。而在分布式系统中，由于网络是不可靠的，虽然在绝大部分情况下，网络通信也能够接受到成功或失败的响应，当时当网络出现异常的情况下，就可能会出现超时现象，通常有以下两种情况：
（1）由于网络原因，该请求并没有被成功地发送到接收方，而是在发送过程中就发生了消息丢失现象；
（2）该请求成功地被接收方接收后，进行了处理，但是在将响应反馈给发送方的过程中，发生了消息丢失现象；
当出现这样的超时现象时，网络通信的发起方是无法确定当前请求是否被成功处理的。
4、节点故障
节点故障则是分布式环境下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象，通常根据经验来说，每个节点都有可能出现故障，并且每天都在发生。
三、分布式事务
3.1 分布式理论，cap
CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：
（1）一致性(Consistency)： 客户端知道一系列的操作都会同时发生(生效)
（2）可用性(Availability)： 每个操作都必须以可预期的响应结束
（3）分区容错性(Partition tolerance)： 即使出现单个组件无法可用,操作依然可以完成
3.2 一致性模型
其实，数据的一致性也分几种情况，大致可以分为：
（1）Weak弱一致性：当你写入一个新值后，读操作在数据副本上可能读出来，也可能读不出来。比如：某些存储系统，搜索引擎，实时游戏，语音聊天等，这些数据本文对完整性要求不高，数据是否一致关系也不大。
（2）Eventually最终一致性：当你写入一个新值后，并不一定能马上读出来，但在某个时间窗口之后保证最终能读出来。比如：DNS，电子邮件，消息中间件等系统，大部分分布式系统技术都采用这类模式。
（3）Strong强一致性：新的数据一旦写入，在任意副本任意时刻都能读到新值。比如：文件系统，RDBMS都是强一致性的。
（4）也就是说，在设计分布式系统时，我们并不一定要求是强一致性的，根据应用场景可以选择弱一致性或者是最终一致性。
3.3 BASE理论
在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？前人已经给我们提出来了另外一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：
（1）Basically Available（基本可用）
（2）Soft state（软状态）
（3）Eventually consistent（最终一致性）
（4）lBASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
3.4 分布式事务
（1）两阶段提交（2PC）
（2）补偿事务（TCC）
（3）本地消息表（异步确保）
（4）MQ事务消息
（5）Sagas事务模型
参考文档：
https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
3.5 分布式事务解决方案：CAP
（1）CAP同时支持 RabbitMQ，Kafka 等消息队列
（2）CAP同时支持 SQL Server, MySql, PostgreSql 等数据库
（3）CAP Dashboard同时支持中文和英文界面双语言，妈妈再也不用担心我看不懂了
（4）CAP提供了丰富的接口可以供扩展，什么序列化了，自定义处理了，自定义发送了统统不在话下
（5）CAP基于MIT开源，你可以尽管拿去做二次开发。（记得保留MIT的License）
四、分布式缓存技术
4.1 缓存的原理
（1）将数据写入/读取速度更快的存储（设备）；
（2）将数据缓存到离应用最近的位置；
（3）将数据缓存到离用户最近的位置。
4.2 分布式缓存的特性
（1）高性能:当传统数据库面临大规模数据访问时,磁盘I/O 往往成为性能瓶颈,从而导致过高的响应延迟.分布式缓存将高速内存作为数据对象的存储介质,数据以key/value 形式存储,理想情况下可以获得DRAM 级的读写性能;（2）动态扩展性:支持弹性扩展,通过动态增加或减少节点应对变化的数据访问负载,提供可预测的性能与扩展性;同时,最大限度地提高资源利用率;（3）高可用性:可用性包含数据可用性与服务可用性两方面.基于冗余机制实现高可用性,无单点失效(single point of failure),支持故障的自动发现,透明地实施故障切换,不会因服务器故障而导致缓存服务中断或数据丢失.动态扩展时自动均衡数据分区,同时保障缓存服务持续可用;（4）易用性:提供单一的数据与管理视图;API 接口简单,且与拓扑结构无关;动态扩展或失效恢复时无需人工配置;自动选取备份节点;多数缓存系统提供了图形化的管理控制台,便于统一维护;（5）分布式代码执行(distributed code execution):将任务代码转移到各数据节点并行执行,客户端聚合返回结果,从而有效避免了缓存数据的移动与传输.
4.3 缓存分类
（1）CDN缓存；
（2）反向代理缓存；
（3）分布式Cache；
（4）本地应用缓存；
4.4 缓存媒介
（1）常用中间件：Varnish，Ngnix，Squid，Memcache，Redis，Ehcache等；
（2）缓存的内容：文件，数据，对象；
（3）缓存的介质：CPU，内存（本地，分布式），磁盘（本地，分布式）
4.5 分布式缓存的典型应用场景
（1）页面缓存.用来缓存Web 页面的内容片段,包括HTML、CSS ,多应用于社交网站等;（2）应用对象缓存.缓存系统作为ORM 框架的二级缓存对外提供服务,目的是减轻数据库的负载压力,加速应用访问;（3）状态缓存.缓存包括Session 会话状态及应用横向扩展时的状态数据等,这类数据一般是难以恢复的,对可用性要求较高,多应用于高可用集群;（4）并行处理.通常涉及大量中间计算结果需要共享;（5）事件处理.分布式缓存提供了针对事件流的连续查询(continuous query)处理技术,满足实时性需求;（6）极限事务处理.分布式缓存为事务型应用提供高吞吐率、低延时的解决方案,支持高并发事务请求处理,多应用于铁路、金融服务和电信等领域.
4.6 如何缓存的问题？
（1）过期策略
（2）固定时间：比如指定缓存的时间是30分钟；
（3）相对时间：比如最近10分钟内没有访问的数据；
（4）同步机制
（5）实时写入；（推）
（6）异步刷新；（推拉）
4.7缓存技术之Ehcache
五、分布式专题
