分布式—一般概念、分布式ID、分布式锁、分布式任务调度

分布式系统

Distributed System
顾名思义就是利用多台计算机协同解决单台计算机所不能解决的计算、存储等问题。
概念：分布式ID、分布式锁、分布式事务、分布式服务框架、微服务架构（MSA）、数据一致性、对等集群、CAP原则、定时调度、数据分片、分布式消息服务、分布式计算、分布式存储、分布式监控、分布式的版本控制、容器技术
特性：分布性、对等性、并发性、缺乏全局时钟、故障总是发生（故障容忍）

几种实现分布式ID的方案：

• 使用数据库自增Id
• 使用reids的incr命令
  *使用UUID
  *Twitter的snowflake算法
  *利用zookeeper生成唯一ID
  *MongoDB的ObjectId

分布式锁

各种锁

乐观锁	悲观锁
比较适合读取操作比较频繁的场景	比较适合写入操作比较频繁的场景
获取数据时不加锁，新数据是判断数据修改否	获取数据时加锁
update table set x=#{newVal}, version=version+1 where id=#{id} and version=#{oldVersion};	Java中synchronized的思想

• 在java中，公平锁可以通过new ReentrantLock(true)来实现；非公平锁可以通过new ReentrantLock(false)或者默认构造函数new ReentrantLock()实现。
• synchronized是非公平锁，并且它无法实现公平锁。

Redis实现分布式锁

• SETNX命令（SET if Not eXists）

当且仅当 key 不存在，将 key 的值设为 value ，并返回1；若给定的 key 已经存在，则 SETNX 不做任何动作，并返回0。

redis的setnx命令天生就适合用来实现锁的功能

为了防治死锁，即某个程序获取锁之后程序出错没有释放锁，其他程序无法获取锁，从而导致整个分布式系统无法获取锁而导致一系列问题，甚至导致系统无法正常运行。这时需要给锁设置一个超时时间，即setex命令，锁超时后，从而其它程序就可以获取锁了。

SETNX和SETEX原子性操作。
多个线程同时加锁的并发问题
redis集群问题，redis集群备份是异步的，不能实时

分布式的一些原则

CAP原则

任何一个分布式系统中，Consistency(一致性 C)、 Availability(服务可用性 A)、Partition tolerance(服务对网络分区故障的容错性 P)，三者不可兼得。分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。

传统单机数据库基于 ACID 特性(原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)) ，放弃了分区容错性，能做到可用性和一致性。

对于一个分布式系统而言，分区容错性是一个最基本的要求。既然是一个分布式系统，那么分布式系统中的组件必然需要被部署到不同的节点，会出现节点与节点之间的网络通讯。

而网络问题又是一定会出现的异常情况，分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。

系统架构师往往需要把精力花在如何根据业务特点在一致性和可用性之间寻求平衡。

网络分区

当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够进行正常通信，而另一些节点则不能——我们将这个现象称为网络分区，就是俗称的“脑裂”。

BASE 理论

对 CAP 原则中一致性和可用性权衡的结果：Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent(最终一致性)。

基本可用：是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，这不等价于系统不可用。

完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

分布式三态

某个节点向另一个节点发起RPC(Remote procedure call)调用，这个RPC 执行的结果有三种状态：“成功”、“失败”、“超时（未知）”，称之为分布式系统的三态。

异常处理原则

被大量工程实践所检验过的异常处理黄金原则是：任何在设计阶段考虑到的异常情况一定会在系统实际运行中发生，但在系统实际运行遇到的异常却很有可能在设计时未能考虑，所以，除非需求指标允许，在系统设计时不能放过任何异常情况。

CAP原则权衡

CP without A 如果不要求A（可用）。很多传统的数据库分布式事务都属于这种模式。银行涉及到金额。
AP wihtout C 要高可用并允许分区，则需放弃一致性。现在众多的NoSQL都属于此类。

副本

副本（replica/copy）指在分布式系统中为数据或服务提供的冗余。
副本协议是贯穿整个分布式系统的理论核心。

副本一致性

强一致性(strong consistency)
单调一致性(monotonic consistency)
会话一致性(session consistency)
最终一致性(eventual consistency)
弱一致性(week consistency)

分布式系统的指标

性能：系统的吞吐能力，通常可以用系统每秒处理的总的数据量来衡量；系统的响应延迟，指系统完成某一功能需要使用的时间；系统的并发能力，指系统可以同时完成某一功能的能力，通常也用QPS(query per second)来衡量。
可用性(availability)：系统停服务的时间与正常服务的时间的比例来衡量，也可以用某功能的失败次数与成功次数的比例来衡量。衡量了系统的鲁棒性。
可扩展性(scalability)：好的分布式系统总在追求“线性扩展性”。
一致性：分布式系统为了提高可用性，总是不可避免的使用副本的机制，从而引发副本一致性的问题。

分布式任务调度

主流的：quartz的集群解决方案、TBSchedule、elastic-job、Saturn

Saturn

是唯品会在github开源的一款分布式任务调度产品。它是基于当当elastic-job来开发的，其上完善了一些功能和添加了一些新的feature。Saturn的任务可以用多种语言开发比如python、Go、Shell、Java、Php。其在唯品会内部已经发部署350+个节点，每天任务调度4000多万次。同时，管理和统计也是它的亮点。
仓库 https://github.com/vipshop/Saturn
文档 https://vipshop.github.io/Saturn/#/zh-cn/3.x/quickstart

别人整理的分布式系列：
https://www.cnblogs.com/itxiaok/p/10356650.html