目录
1. 分布式系统
1.自己对分布式系统的理解
把一个大的系统拆分为很多小的系统，甚至很小的服务，然后几个人组成一个小组就专门维护其中一个小系统，即分而治之，不同的小系统自己开发、测试和上线，跟其他小系统解耦；
不同的子系统之间通过接口互相调用（Restful、RPC），每个子系统都有自己的数据库。
2.分布式系统会涉及哪些技术问题？
不同的子系统或者微服务之间怎么通信？需要有一套分布式服务框架（了解过Service Comb微服务框架），常见的技术框架有dubbo、spring cloud；
贯穿全局的分布式事务怎么实现？需要了解TCC、最终一致性、2PC等分布式事务的实现方案；
分布式缓存怎么实现？即多个子系统共享一个缓存（Redis分布式缓存）；
分布式锁怎么实现？毕竟不在一个JVM里了，不同的子系统之间不可能再用synchronized来在全局加锁；
分布式消息系统怎么实现？多个子系统之间要进行消息队列的传递（Kafka分布式消息中间件）；
其他很多的技术，比如分布式配置中心、分布式日志中心、分布式监控告警中心、分布式会话等等。
2.分布式服务框架
Service Comb
Dubbo
RPC
负载均衡——Nginx
- Nginx是一个高性能的HTTP服务器和反向代理服务器；
- 也是一个IMPA/POP3/SMTP代理服务器；
- 既可以作为一个HTTP服务器进行网站的发布处理，也可以作为反向代理进行负载均衡的实现。
1. 正向代理和反向代理
【正向代理】
- 客户端非常明确要访问的服务器地址；
- 服务器只清楚请求来自哪个代理服务器，屏蔽或者隐藏了真实客户端信息；
- 客户端必须设置正向代理服务器，比如代理服务器的IP地址、端口；
- 正向代理的是客户端。
【反向代理】
- 客户端是无感知代理的存在；
- 反向代理隐藏了服务器的信息；
- 客户端不需要任何配置就可以访问；
- 反向代理的是服务器，主要用于服务器集群分布式部署的情况，保证内网的安全，负载均衡。
2. 负载均衡——将请求按照一定规则分发到不同的服务器
（1）weight轮询（默认）：接收到的请求按照顺序逐一分配到不同的后端服务器，即使在使用过程中，某一台后端服务器宕机，Nginx会自动将该服务器剔除出队列，请求受理情况不会受到任何影响。 这种方式下，可以给不同的后端服务器设置一个权重值(weight)，用于调整不同的服务器上请求的分配率；权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
（2）ip hash（第三方插件）：每个请求按照发起客户端的ip的hash结果进行匹配，这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器，这也在一定程度上解决了集群部署环境下session共享的问题，但是ip hash不一定平均。
（3）url hash（第三方插件）：和 ip hash类似，按照访问的url的hash结果分配请求，同一个用户访问同一个url，会被一样的服务器处理，可以在Nginx作为静态服务器的情况下提高缓存效率；缺点：请求频繁的url会请求到同一个服务器上。
（4）fair（第三方插件）：哪个服务器的响应速度快，就将请求分配到那个服务器上，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少。
3.分布式事务
1. 什么是分布式事务。
【定义】
分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。
【CAP定理】
- C（Consistency一致性）：对某个客户端来说，读操作能返回最新的写操作；如果在某个节点更新了数据，那么在其他节点如果都能读取到这个最新的数据，那么就称为强一致。
- A（Availability可用性）：非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。
- P（Paitition tolerance分区容错性）：当出现网络分区后，系统能够继续工作。打个比方，这里集群有多台机器，有台机器网络出现了问题，但是这个集群仍然可以正常工作。
- 在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。P是 必要的，即在一致性和可用性中做出选择，CP还是AP。
【BASE理论】
- BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写，是对CAP中AP的一个扩展。
- 基本可用：分布式系统出现故障时，允许损失部分可用功能，保证核心功能可用。
- 软状态：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。
- 最终一致：是指经过一段时间后，所有节点的数据将会达到一致。
【分布式事务几种常见的方案】
- 两阶段提交（2PC）
- 补偿事务（TTC）
- 事务消息中间件
- 本地消息表（最大努力通知）
2. 两阶段提交（2PC），又叫做XA Transactions。
该协议分为以下两个阶段：
- 第一阶段：事务协调器要求每个涉及到事务的数据库预提交（percommit）此操作，并反映是否可以提交。
- 第二阶段：事务协调器要求每个数据库提交数据。
优点：尽量保证了数据的一致性，适合对数据强一致要求很高的关键领域。
缺点：实现复杂，牺牲了可用性，对性能影响较大，事务时间相对变长，锁定资源的时间变长，不适合高并发性能场景。
3. 补偿事务（TCC）
TCC其实采用的是补偿机制，核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。分为三阶段：
- Try阶段主要是对业务系统检测及资源预留；
- Confirm阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认Confirm阶段时不会出错的，即只要Try成功，Confirm一定成功；
- Cancel阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
优点：解决了跨应用业务操作的原子性问题，在诸如组合支付、账务拆分场景非常实用。TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交，规避了数据库层的2PC性能低下问题。
缺点：在2,3步中都有可能失败；TCC属于应用层的一种补充方式，TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本高。
4.分布式缓存
一致性哈希算法：一种分布式算法，常用于负载均衡。Memcached client也选择这种算法，解决将key-value均匀分配到众多Memcached server上的问题。它可以取代传统的取模操作，解决了取模操作无法应对增删Memcached Server的问题(增删server会导致同一个key,在get操作时分配不到数据真正存储的server，命中率会急剧下降)。
5.分布式锁
6. 分布式消息中间件——Kafka消息队列
【链接】---- 深入浅出理解基于Kafka和Zookeeper的分布式消息队列
看上面的链接即可。
7. 分布式协调中间件——Zookeeper、ETCD
1. zookeeeper和etcd的类比
【功能介绍】
| 功能 | etcd | zookeeper |
| 分布式锁 | 有 | 有 |
| watcher | 有 | 有 |
| 一致性算法 | raft | zab |
| 选举 | 有 | 有 |
| 元数据存储 | 有 | 有 |
- watcher指的是订阅/通知，当一个值改变时，通知订阅过的节点，在etcd中是K/V值对的改变，在zookeeper中是znode的改变（值改变、节点删除等）；
- raft和zab都是paxos算法的变形，都是为了解决分布式系统中的读写一致性问题；
- 选举都是通过相应的一致性算法实现的。
【应用场景】
| 应用场景 | etcd | zookeeper |
| 发布与订阅（配置中心） | 有 | 有 |
| 软负载均衡 | 有 | 有 |
| 命名服务（Naming Service） | 有 | 有 |
| 分布式通知/协调 | 有 | 有 |
| 集群管理与Master选举 | 有 | 有 |
| 分布式锁 | 有 | 有 |
| 分布式队列 | 有 | 有 |
| 服务发现 | 有 | 有 |
【总结】
zookeeper和etcd解决的问题是一样的，都解决分布式系统的协调和元数据的存储，所以他们都不是一个存储组件。或者说都不是一个分布式数据库。etcd的灵感来源于zookeeper，但又在实现的时候有了很多的改进，如下：
- etcd更轻量级，raft算法更易懂，更易用；
- 高负载下的稳定读写；
- 数据模型的多版本并发控制；
- 稳定的watcher功能，通知订阅者监听值的改变；
- 可以容忍脑裂现象的发生，脑裂现象指的是，在一个分布式集群中，只允许一个leader协调工作，由于网络或其他原因，导致一个集群分成了两个集群，产生了两个leader同时工作，此时集群不在具备读写一致性。
2. zookeeper的zab协议
扫一扫
2344
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
