分布式问题分析

参考：https://github.com/CyC2018/Interview-Notebook/blob/master/notes/

业务中的分布式：

分布式存储：将数据分片到多个节点上，不只能够提升性能（可扩展性），同时也可使用多个节点对同一份数据进行备份（高可用性）

分布式计算：将一个大的计算任务分解成小任务分配到多个节点上去执行，再汇总每一个小任务的执行结果获得最终结果。MapReduce 是分布式计算最好的例子。

 

分布式事务：
指事务的操做位于不一样的节点上，须要保证事务的 AICD 特性。

产生的缘由：

• 数据库分库分表；
• SOA 架构，好比一个电商网站将订单业务和库存业务分离出来放到不一样的节点上。

解决办法：

1. 两阶段提交协议（很好地解决分布式事务问题）

2. 消息中间件（本质上是一个暂存转发消息的一个中间件）

处理模型：（1）点对点；（2）发布/订阅

 

 

 负载均衡的算法与实现：

算法有轮询（Round Robin）、加权轮询、最少链接（将请求发送给当前最少链接数的服务器）、加权最小链接、随机算法

上面的没有加权的适合服务器性能差很少场景

 

Zookeeper 分布式锁

　　Zookeeper 是一个为分布式应用提供一致性服务的软件，例如配置管理、分布式协同以及命名的中心化等，这些都是分布式系统中很是底层并且是必不可少的基本功能，可是若是本身实现这些功能并且要达到高吞吐、低延迟同时还要保持一致性和可用性，实际上很是困难。

　　抽象模型：Zookeeper 提供了一种树形结构级的命名空间，/app1/p_1 节点表示它的父节点为 /app1。

监听器：为一个节点注册监听器，在节点状态发生改变时，会给客户端发送消息。

节点类型

• 永久节点：不会由于会话结束或者超时而消失；
• 临时节点：若是会话结束或者超时就会消失；
• 有序节点：会在节点名的后面加一个数字后缀，而且是有序的，例如生成的有序节点为 /lock/node-0000000000，它的下一个有序节点则为 /lock/node-0000000001，依次类推。

分布式锁实现：

1. 建立一个锁目录 /lock。
2. 在 /lock 下建立临时的且有序的子节点，第一个客户端对应的子节点为 /lock/lock-0000000000，第二个为 /lock/lock-0000000001，以此类推。
3. 客户端获取 /lock 下的子节点列表，判断本身建立的子节点是否为当前子节点列表中序号最小的子节点，若是是则认为得到锁，不然监听本身的前一个子节点，得到子节点的变动通知后重复此步骤直至得到锁；
4. 执行业务代码，完成后，删除对应的子节点。

会话超时

　　若是一个已经得到锁的会话超时了，由于建立的是临时节点，所以该会话对应的临时节点会被删除，其它会话就能够得到锁了。能够看到，Zookeeper 分布式锁不会出现数据库分布式锁的死锁问题。

羊群效应（在这里不存在羊群效应）

　　在步骤二，一个节点未得到锁，须要监听监听本身的前一个子节点，这是由于若是监听全部的子节点，那么任意一个子节点状态改变，其它全部子节点都会收到通知（羊群效应），而咱们只但愿它的后一个子节点收到通知。

--------------------------------------------------------

分布式 Session

　　在分布式场景下，一个用户的 Session 若是只存储在一个服务器上，那么当负载均衡器把用户的下一个请求转发到另外一个服务器上，该服务器没有用户的 Session，就可能致使用户须要从新进行登陆等操做。

Sticky Sessions

须要配置负载均衡器，使得一个用户的全部请求都路由到一个服务器节点上，这样就能够把用户的 Session 存放在该服务器节点中。

缺点：当服务器节点宕机时，将丢失该服务器节点上的全部 Session。

 

Session Replication

在服务器节点之间进行 Session 同步操做，这样的话用户能够访问任何一个服务器节点。

缺点：须要更好的服务器硬件条件；须要对服务器进行配置。

Persistent DataStore

将 Session 信息持久化到一个数据库中。

缺点：有可能须要去实现存取 Session 的代码。

 

In-Memory DataStore

可使用 Redis 和 Memcached 这种内存型数据库对 Session 进行存储，能够大大提升 Session 的读写效率。内存型数据库一样能够持久化数据到磁盘中来保证数据的安全性。