分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。
分布式锁也就是我们分布式协调技术实现的核心内容。
分布式锁两种实现方式：
(资料图片)
1. 基于缓存（Redis等）实现分布式锁 获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自 动释放锁，锁的value值为一个随机生成的UUID, 释放锁的时候进行判断。 获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。 释放锁的时候，通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。
SETNX ：set一个key为value的字符串，返回1；若key存在，则什么都不做，返回0。expire: 为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。delete ：删除key2. ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树 结构，规定同一个目录下只能有一个唯一文件名, 基于ZooKeeper实现分布式锁的步骤如下：
创建一个目录mylock线程A想获取锁就在mylock目录下创建临时顺序节点获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前 线程顺序号最小，获得锁线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果 是则获得锁二、服务削峰1、为什么要削峰
主要是还是来自于互联网的业务场景，例如，春节火车票抢购，大量的用户需要同一时间去抢购； 以及大家熟知的阿里双11秒杀， 短时间上亿的用户涌入，瞬间流量巨大（高并发）。
2、流量削峰方案
削峰从本质上来说就是更多地延缓用户请求，以及层层过滤用户的访问需求，遵从“最后落地到数据 库的请求数要尽量少”的原则。
1. 消息队列解决削峰 要对流量进行削峰，最容易想到的解决方案就是用消息队列来缓冲瞬时流量，把同步的直接调用转 换成异步的间接推送，中间通过一个队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去。
消息队列中间件主要解决应用耦合，异步消息， 流量削峰等问题。常用消息队列系统：目前 在生产环境，使用较多的消息队列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、RocketMQ 等。 在这里，消息队列就像“水库”一样，拦截上游的洪水，削减进入下游河道的洪峰流量，从而达 到减免洪水灾害的目的。
2. 流量削峰漏斗：层层削峰 分层过滤其实就是采用“漏斗”式设计来处理请求的，这样就像漏斗一样，尽量把数据量和请求量一 层一层地过滤和减少了。如下图所示：
分层过滤的核心思想
通过在不同的层次尽可能地过滤掉无效请求。通过CDN过滤掉大量的图片，静态资源的请求。再通过类似Redis这样的分布式缓存过滤请求分层过滤的基本原则
对写数据进行基于时间的合理分片，过滤掉过期的失效请求。对写请求做限流保护，将超出系统承载能力的请求过滤掉。涉及到的读数据不做强一致性校验，减少因为一致性校验产生瓶颈的问题。对写数据进行强一致性校验，只保留最后有效的数据。三、服务降级1、什么是服务降级
当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心服务正常运作或高效运作。
整个架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保 证重要或基本的服务能正常运行，我们可以将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用。
2、降级策略
当触发服务降级后，新的交易再次到达时，我们该如何来处理这些请求呢？
从分布式,微服务架构全局的 视角来看，降级处理方案：
页面降级 —— 可视化界面禁用点击按钮、调整静态页面延迟服务 —— 如定时任务延迟处理、消息入MQ后延迟处理写降级 —— 直接禁止相关写操作的服务请求读降级 —— 直接禁止相关读的服务请求缓存降级 —— 使用缓存方式来降级部分读频繁的服务接口针对后端代码层面的降级处理策略，则我们通常使用以下几种处理措施进行降级处理：
抛异常返回NULL调用Mock数据调用Fallback处理逻辑3、分级降级
结合服务能否降级的优先原则，并根据台风预警（都属于风暴预警）的等级进行参考设计，可将分布式服务架构的所有服务进行故障风暴等级划分为以下四种：
