分布式
中心化
中心化副本控制协议的基本思路是由一个中心节点协调副本数据的更新、维护副本之间的一致性。
去中心化副本控制协议没有中心节点，协议中所有的节点都是完全对等的，节点之间通过平等协商达到一致。
Zookeeper：
用Paxos协议选择Leader，用Lease协议控制数据是否有效。用Quorum协议把Leader的数据同步到follow。
MySql：
MySQL的主从库设计也是基于日志。从库只需通过回放主库的日志，就可以实现与主库的同步。由于从库同步的速度与主库更新的速度没有强约束，这种方式只能实现最终一致性。
读写分离，主从同步
两阶段提交：
两阶段提交的思路比较简单，在第一阶段，协调者询问所有的参与者是否可以提交事务（请参与者投票），所有参与者向协调者投票。在第二阶段，协调者根据所有参与者的投票结果做出是否事务可以全局提交的决定，并通知所有的参与者执行该决定。在一个两阶段提交流程中，参与者不能改变自己的投票结果。两阶段提交协议的可以全局提交的前提是所有的参与者都同意提交事务，只要有一个参与者投票选择放弃(abort)事务，则事务必须被放弃。可以这么认为，两阶段提交协议对于这种超时的相关异常也没有很好的容错机制，整个流程只能阻塞在这里，且对于参与者而言流程状态处于未知，参与者即不能提交本地节点上的事务，也不能放弃本地节点事务。
8． 第一、两阶段提交协议的容错能力较差。
9．第二、两阶段提交协议的性能较差。一次成功的两阶段提交协议流程中，协调者与每个参与者之间至少需要两轮交互4个消息“prepare”、“vote-commit”、“global-commit”、“确认global-commit”。过多的交互次数会降低性能。另一方面，协调者需要等待所有的参与者的投票结果，一旦存在较慢的参与者，会影响全局流程执行速度。
单机上的事务：
事务靠日志技术或MVCC等技术实现。
MVCC即多个不同版本的数据实现并发控制的技术，其基本思想是为每次事务生成一个新版本的数据，在读数据时选择不同版本的数据即可以实现对事务结果的完整性读取。在使用MVCC时，每个事务都是基于一个已生效的基础版本进行更新，事务可以并行进行。其思想是根据版本号，在多个节点取同一个版本号的数据。
负载均衡算法：
常见负载均衡算法举例，轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接达。大部分算法为了服务器上线、下线或宕机带来的并发问题，都会将服务调用地址缓存在线程本地变量中；
• 轮询法：将服务调用地址缓存在线程本地变量中，通过同步顺序调用，保证请求转移的绝对均衡。缺点是缓存变量不能很好的更新下线的机器列表，并且悲观锁导致性能和吞吐量下降；
• 随机法：将服务调用地址缓存在线程本地变量中，利用随机函数，随机选择一台服务器进行访问。比如random.nextInt(serverSize);
• 源地址哈希法：利用客户端访问的IP地址，通过哈希函数计算得到一个数值，并对服务器列表大小取模运算，得到需要访问的索引；特点是每个IP访问的服务器地址将是固定的，所以可以建立有状态的session会话；
• 加权轮询法：
给性能优良、配置好的服务器设置更大的权重值，根据权重大小，把服务器地址重复地添加到线程本地服务器地址中，权重越大，每次轮询获得的请求次数就越多；
• 加权随机法：
与加权轮询法类似，不同的是，它按照权重来随机选取服务，而非顺序；
• 最小连接数：
根据后台服务器的连接情况，动态的选择其中当前积压连接数最少的服务器来处理当前请求；
• 一致性哈希：先构造一个长度为232的整数环（这个环被称为一致性Hash环），根据节点名称的Hash值（其分布为[0, 232-1]）将服务器节点放置在这个Hash环上，然后根据数据的Key值计算得到其Hash值（其分布也为[0, 232-1]），接着在Hash环上顺时针查找距离这个Key值的Hash值最近的服务器节点，完成Key到服务器的映射查找。
虚拟节点：将一个物理节点拆分为多个虚拟节点，并且同一个物理节点的虚拟节点尽量均匀分布在Hash环上。采取这样的方式，就可以有效地解决增加或减少节点时候的负载不均衡的问题。
title: 分布式技术
date: 2017-03-09 13:20:13
tags:
分布式
中心化
中心化副本控制协议的基本思路是由一个中心节点协调副本数据的更新、维护副本之间的一致性。
去中心化副本控制协议没有中心节点，协议中所有的节点都是完全对等的，节点之间通过平等协商达到一致。
Zookeeper：
用Paxos协议选择Leader，用Lease协议控制数据是否有效。用Quorum协议把Leader的数据同步到follow。
MySql：
MySQL的主从库设计也是基于日志。从库只需通过回放主库的日志，就可以实现与主库的同步。由于从库同步的速度与主库更新的速度没有强约束，这种方式只能实现最终一致性。
读写分离，主从同步
两阶段提交：
两阶段提交的思路比较简单，在第一阶段，协调者询问所有的参与者是否可以提交事务（请参与者投票），所有参与者向协调者投票。在第二阶段，协调者根据所有参与者的投票结果做出是否事务可以全局提交的决定，并通知所有的参与者执行该决定。在一个两阶段提交流程中，参与者不能改变自己的投票结果。两阶段提交协议的可以全局提交的前提是所有的参与者都同意提交事务，只要有一个参与者投票选择放弃(abort)事务，则事务必须被放弃。可以这么认为，两阶段提交协议对于这种超时的相关异常也没有很好的容错机制，整个流程只能阻塞在这里，且对于参与者而言流程状态处于未知，参与者即不能提交本地节点上的事务，也不能放弃本地节点事务。
8． 第一、两阶段提交协议的容错能力较差。
9．第二、两阶段提交协议的性能较差。一次成功的两阶段提交协议流程中，协调者与每个参与者之间至少需要两轮交互4个消息“prepare”、“vote-commit”、“global-commit”、“确认global-commit”。过多的交互次数会降低性能。另一方面，协调者需要等待所有的参与者的投票结果，一旦存在较慢的参与者，会影响全局流程执行速度。
单机上的事务：
事务靠日志技术或MVCC等技术实现。
MVCC即多个不同版本的数据实现并发控制的技术，其基本思想是为每次事务生成一个新版本的数据，在读数据时选择不同版本的数据即可以实现对事务结果的完整性读取。在使用MVCC时，每个事务都是基于一个已生效的基础版本进行更新，事务可以并行进行。其思想是根据版本号，在多个节点取同一个版本号的数据。
负载均衡算法：
常见负载均衡算法举例，轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接达。大部分算法为了服务器上线、下线或宕机带来的并发问题，都会将服务调用地址缓存在线程本地变量中；
• 轮询法：将服务调用地址缓存在线程本地变量中，通过同步顺序调用，保证请求转移的绝对均衡。缺点是缓存变量不能很好的更新下线的机器列表，并且悲观锁导致性能和吞吐量下降；
• 随机法：将服务调用地址缓存在线程本地变量中，利用随机函数，随机选择一台服务器进行访问。比如random.nextInt(serverSize);
• 源地址哈希法：利用客户端访问的IP地址，通过哈希函数计算得到一个数值，并对服务器列表大小取模运算，得到需要访问的索引；特点是每个IP访问的服务器地址将是固定的，所以可以建立有状态的session会话；
• 加权轮询法：
给性能优良、配置好的服务器设置更大的权重值，根据权重大小，把服务器地址重复地添加到线程本地服务器地址中，权重越大，每次轮询获得的请求次数就越多；
• 加权随机法：
与加权轮询法类似，不同的是，它按照权重来随机选取服务，而非顺序；
• 最小连接数：
根据后台服务器的连接情况，动态的选择其中当前积压连接数最少的服务器来处理当前请求；
• 一致性哈希：先构造一个长度为232的整数环（这个环被称为一致性Hash环），根据节点名称的Hash值（其分布为[0, 232-1]）将服务器节点放置在这个Hash环上，然后根据数据的Key值计算得到其Hash值（其分布也为[0, 232-1]），接着在Hash环上顺时针查找距离这个Key值的Hash值最近的服务器节点，完成Key到服务器的映射查找。
虚拟节点：将一个物理节点拆分为多个虚拟节点，并且同一个物理节点的虚拟节点尽量均匀分布在Hash环上。采取这样的方式，就可以有效地解决增加或减少节点时候的负载不均衡的问题。
分布式事务
Redis
分布式锁
分布式缓存，
分布式数据库