分布式常用解决方案集合

分布式方案

分布式任务调度

elastic job

elastic-job使用了quartz的调度机制，内部原理一致，他可以看作是quartz的一个扩展实现，使用注册中心(zookeeper)替换了quartz的jdbc数据存储方式，此外，elastic-job又支持分片等特殊功能

三种作业方式

Simple类型作业Simple类型即为简单实现，未经任何封装的类型，需实现SimpleJob接口，该接口仅提供单一方法用于覆盖，此方法将定时执行，与Quartz原生接口相似，但提供了弹性扩缩容和分片等功能；

DataFlow类型作业 Dataflow类型用于处理数据流，需实现DataflowJob接口，该接口提供2个方法可供覆盖，分别用于抓取(fetchData)和处理(processData)数据； 可通过DataflowJobConfiguration配置是否流式处理。 流式处理数据只有fetchData方法的返回值为null或集合长度为空时，作业才停止抓取，否则作业将一直运行下去； 非流式处理数据则只会在每次作业执行过程中执行一次fetchData方法和processData方法，随即完成本次作业。 如果采用流式作业处理方式，建议processData处理数据后更新其状态，避免fetchData再次抓取到，从而使得作业永不停止，适用于不间歇的数据处理。 Script类型作业Script类型作业意为脚本类型作业，支持shell，python，perl等所有类型脚本。只需通过控制台或代码配置scriptCommandLine即可，无需编码。执行脚本路径可包含参数，参数传递完毕后，作业框架会自动追加最后一个参数为作业运行时信息；

分片机制

• 分片是指将一个任务拆分成多个任务执行，比如：现在要对一些数据进行处理，为了快速的执行任务，我们用2台服务器，让每台服务器执行任务的50%

• 这样任务执行就比较快，可以充分利用服务器资源，你可以部署很多台机器来执行这些分片任务；Elastic-job提供的分片功能，能够让任务通过分片进行水平扩展，可以通过多部署几台服务器，支撑海量数据量的任务调度，当任务减少，可以缩减服务器，实现了动态伸缩（扩容和缩容）；

• 分片策略

  • 轮询分片策略

  • 奇偶分片策略

  • 平均分片策略

高可用

1. 当任务服务器在运行中宕机时，注册中心同样会通过临时节点感知到，并将在下次运行时将分片转移至仍存活的服务器，以达到任务高可用的效果，本次由于服务器宕机而未执行完的任务，则可以通过失效转移的方式继续执行；

2. 失效转移：Elastic-Job不会在本次执行过程中进行重新分片，而是等待下次调度之前才开启重新分片流程，当任务执行过程中服务器宕机，失效转移允许将该次未完成的任务在另一任务节点上补偿执行；

3. 线程池策略

4. 错误处理策略

分布式锁

Redis实现：SETNX + EXPIRE

zk实现

优点锁

安全性高，zk可持久化，且能实时监听获取锁的客户端状态。一旦客户端宕机，则瞬时节点随之消失，zk因而能第一时间释放锁。这也省去了用分布式缓存实现锁的过程中需要加入超时时间判断的这一逻辑。

5适用场 对可靠性要求非常高，且并发程度不高的场景下使用。如核心数据的定时全量/增量同步等。

3缺点性能开销比较高。因为其需要动态产生、销毁瞬时节点来实现锁功能。所以不太适合直接提供给高并发的场景使用。

4实现可以直接采用zookeeper第三方库curator即可方便地实现分布式锁。

分布式会话

tomcat session共享

spring 基于redis的共享

分布式事务

seata

用于在分布式系统中保证不同节点之间数据一致性

分布式数据库

一致性hash

分布式RAFT算法，一致性协议选举

消息中间件

activeMq

rabbit mq

什么情况下需要用到分布式

a.优点:

i.模块解耦，把模块拆分,使用接口通信,降低模块之间的耦合度i.项目拆分，不同团队负责不同的子项目: 把项目拆分成若干个子项目,不同的团队负责不同的子项目.ii.提高项目扩展性: 增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。

iv.分布式部署:可以灵活的进行分布式部署.v提高代码的复用性:比如service层 如果不采用分布式rest服务方式架构就会在手机wap商城,微信商城pcandroid，ios每个端都要写一个service层逻辑,开发量大,难以维护一起升级,这时候就可以采用分布式rest服务方式公用一个service层。

b.缺点: i.系统之间的交互要使用远程通信,接口开发增大工作量ii.网络请求有延时; ii.事务处理比较麻烦，需要使用分布式事务

微服务如何拆分

1、业务方面拆分:所有技术方面的考虑，包括架构设计和解拆分都要考虑业务的需要。在服务拆分时，先从业务角度确定拆分的方案。拆分的边界要充分考虑业务的独立性和专业性，比如搜索类服务、支付类服务、购物车类服务，按服务的业务功能合理地划出拆分边界。

2、减少维护成本:拆分前的维护成本-拆分后的维护成本>0

3、服务独立:确保拆分后的服务由相对独立的团队负责维护，尽量不要出现在不同服务之间的交叉调用。

4、系统扩展:拆分的一个重要理由也是最有价值的结果是提高了系统的扩展性。用户对不同的服务有不同的并发和性能方面的要求，因此服务具有不同的扩展性。把具有不同扩展性要求的服务拆分出来分别进行部署，可以降低成本，提高效率.

接口限流方案

1.限制 总并发数(比如 数据库连接池、线程池)

2.限制 瞬时并发数(如nginx的limit conn模块，用来限制 瞬时并发连接数)

3.限制时间窗口内的平均速率(如Guava的RateLimiter、nginx的limit req模块，限制每秒的平均速率)

4.限制远程接口调用速率 

5.限制MQ的消费速率

6可以根据网络连接数、网络流量、CPU或内存负载等来限流

常见限流算法

计数器法

一分钟最多100个请求，用一个计数器记录，每过一分钟清零，大于100则无法通过

滑动窗口

计数器算法的改进，防止瞬间并高发

漏桶算法

请求滴在桶里，桶地下有洞，均匀的流出（成功请求），当桶满了，多余请求就会失败

令牌桶算法

桶里最多放100个钥匙，以一个固定速率放入token，一个请求拿走一个钥匙，没有钥匙则无法通过

ELK

1. Elasticsearch -->存储数据是一个实时的分布式搜索和分析引擎，它可以用于全文搜索，结构化搜索以及分析。它是一个建立在全文搜索引擎 Apache Lucene 基础上的搜索引擎，使用 Java 语言编写，能对大容量的数据进行接近实时的存储、搜索和分析操作。

2. Logstash --> 收集数据数据收集引擎。它支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储到用户指定的位置。

3. Kibana --> 展示数据数据分析和可视化平台。通常与 Elasticsearch 配合使用，对其中数据进行搜索、分析和以统计图表的方式展示。EFK是ELK日志分析系统的一个变种，加入了filebeat 可以更好的收集到资源日志 来为我们的日志分析做好准备工作。

ELK 是现阶段众多企业单位都在使用的一种系统，它能够方便的为我们收集你想要的日志并且展示出来日志分析ELK是Elasticsearch、Logstash、Kibana的简称，这三者都是开源软件，通常配合使用。

Elasticsearch 是一个实时的、分布式的可扩展的搜索引擎，允许进行全文、结构化搜索，它通常用于索引和搜索大量日志数据，也可用于搜索许多不同类型的文档。Beats 是的得力工具。将 Beats 和您的容器一起置于上，或者将 Beats 作为函数加以部署，然后便可在 Elastisearch 中集中处理数据。如果需要更加强大的处理性能，Beats 还能将数据输送到 Logstash 进行转换和解析。数据采集服务器Kibana 核心产品搭载了一批经典功能：柱状图、线状图、饼图、旭日图，等等。不仅如此，您还可以使用 Vega 语法来设计独属于您自己的可视化图形。所有这些都利用 Elasticsearch 的完整聚合功能。Elasticsearch 通常与 Kibana 一起部署，Kibana 是 Elasticsearch 的一个功能强大的数据可视化 Dashboard，Kibana 允许你通过 web 界面来浏览 Elasticsearch 日志数据。

解决方案

大数据高并发

优化思路

• 限流：只有少部分可以秒杀成功。限制大部分流量

• 削峰：利用缓存和消息中间件

• 异步处理

• 内存缓存：高并发下数据库读写一般是最大的瓶颈，磁盘IO性能低

如何防止库存超卖

• 乐观锁

• 数据库锁（ for update）

• 分布式锁

• 悲观锁

• 消息队列，使修改库存操作串行化

• redis watch 监视键值对，如果事务提交时发现监视的键值对发生变化，事务将被取消

雪花算法：snowflake

Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是∶使用41bit作为毫秒数，10bit作为机器的ID( 5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生4096个ID)，最后还有一个符号位，永远是0。可以保证几乎全球唯一!

如何保证服务幂等性

• 接口的幂等性实际就是接口的可重复调用，在调用多次的情况下，结果一致有些接口天然幂等，如查询

• 全局唯一ID：雪花算法，再执行操作前判断id是否存在

• 多版本控制

• 状态机控制：比如订单创建0，付款成功100，付款失败99，做状态机更新时，可以 where id = #{id} and status< #{status}

单点登录

OAuth2

OAuth2.0的授权模式

授权码模式（authorization code）  简化模式（implicit）  密码模式（resource owner passwordcredentials） 客户端模式（client credentials）

应用：微信三方登录OAuth2.0获取access_token流程微信 OAuth2.0 授权登录让微信用户使用微信身份安全登录第三方应用或网站，在微信用户授权登录已接入微信 OAuth2.0 的第三方应用后，第三方可以获取到用户的接口调用凭证（access_token），通过 access_token 可以进行微信开放平台授权关系接口调用，从而可实现获取微信用户基本开放信息和帮助用户实现基础开放功能等。

三种实现

1. 应用服务器集群模式：基于tomcat等应用服务器的session同步机制

2. 微服务模式：cookie+redis，将session用户信息放入redis中，各个模块可以共享redis中用户信息

3. token：按照规则生产字符串，字符串中可以包含用户信息，开发人员可以自定义生成规则，也可以使用提供好的生成规则（如JWT自动生成含用户信息的字符串）

疑问

如果第三方应用直接通过服务提供方的账户密码访问，存在信息泄露给了第三方，比如微信QQ单点登录第三方App，不可能把账户密码给第三方

分库分表

实现方案

1. Mycat中间件服务，无需改代码就可兼容

2. Spring Boot集成ShardingJdbc实现分库分表

   1. ShardingJdbc本质上是一个轻量级的JDBC驱动代理，在使用的过程中只需要依赖相关Jar包即可，并不需要额外部署任何服务。通过系统配置文件就可以实现分库分表逻辑的定义，并实现应用透明代理访问。

3. JDBC直接实现水平分表

考虑问题点

业务关联，存储规划、未来数据增长模式评估、怎么拆、一致性问题、分布式事务、跨节点JION、分页排序统计问题、分库分表细节如何对应用透明，如何用代理层屏蔽分库分表对程序带来侵入

TOP key海量搜索

局部淘汰

分治

hash去重

最小堆

持续集成、持续发布、jenkins

分布式全局唯一发号器

redis生产ID INCR原子操作

Twitter的snowflake雪花算法

带过期策略的LRU缓存

利用链表和hashMap，当插入时在链表中命中，则把节点移到最前，不存在则新增插入头部，如数据已满，则移除最后节点

设计统一配置中心

特点

• 配置的CURD

• 不同环境配置隔离

• 高性能 高可用

• 高并发