分布式处理系统服务器配置,分布式解决方案

分布式全局ID生成方案

1.UUID

优点：性能高，本地生成，没有网络消耗

缺点：不易于存储，信息不安全

2.数据库自增ID

优点：利用数据库现有功能实现简单成本低，id单调递增

缺点：依赖DB，ID发号性能瓶颈限制在单台MYSQL的读写性能

3.数据库多主模式(主从模式集群两台MySQL经过配置自动生成不同的ID)

优点：永不挂机生成ID

缺点：扩展性差，MySQL增多对应的步长加长可能导致ID重复

4.批量生成ID(号段模式)

优点：避免了每次生成ID都要访问数据库并带来压力，提高性能

缺点：属于本地生成策略，存在单点故障，服务重启造成ID不连续

5.Redis生成ID

优点：不依赖于数据库，数字ID天然排序

缺点：如果没有redis需要引入新的组件增加系统的复杂度，需要编码和配置的工作量比较大

6.利用zookeeper生成唯一ID

优点：比主键递增性能高，能保证趋势递增；如果DB宕机，proxServer由于有缓存依然可以坚持一段时间

缺点：和主键递增一样，容易被人猜测；DB宕机，虽然能支撑一段时间但是仍然会造成系统不可用

7.雪花算法-Snowflake

优点：毫秒数在高位，自增序列在低位，整个ID都是趋势递增；不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的；可以根据自身业务特性分配bit位，非常灵活

缺点：可以根据自身业务特性分配bit位，非常灵活

8.MongDB objectID：和snowflake类似方法通过 "时间+机器码+pid+inc"以4+3+2+3的方式最终标识成一个24长度的十六进制字符

分布式事务解决方案

2PC：事务管理器要求涉及到数据库的事务都要进行预处理，反映是否可提交之后进行提交或者回滚

优点：保证数据一致性，实现成本低

缺点：事务管理器一旦宕机，资源管理器将一直处于阻塞状态，导致数据库不可用；准备就绪之后，一致处于阻塞状态直至提交完成才释放资源；数据存在不一致性。

TCC(Try-Confirm-Cancel)：尝试执行try完成所有的检查，如果失败进行cancel；如果成功进行confirm；

适用范围：强隔离性，严格一致性要求活动业务，执行时间短的业务

优点：系统控制性强

缺点：复用性差，不同系统的逻辑不同

本地消息表：将需要处理的事务通过日志的方式进行异步处理，操作每个节点判断节点是否成功，失败的节点加入重试机制，保证最终的数据一致性。

优点：实现和逻辑通俗易懂，性能大幅度提升

缺点：牺牲一定的一致，实现了最终一致性

Saga事务：将长事务分成短事务，每个子事务都含有幂等的，每个子事务都直接提交到库，事务发生失败进行恢复。

Saga定义两种恢复策略：

向前恢复(forward recovery)：事务在哪里失败则从那开始进行进行重试不需要进行回滚。

向后恢复(backward recovery)：事务出现失败整个事务进行回滚

Saga事务常见的两种实现方法：

命令协调(order orchestrator)：中央协调器负责集中处理事件的决策和业务逻辑排序。总事务为事务发起方，中央管理器先知道整个事务的流程，中央管理器以命令/回复的方式与每项服务进行通信，任何事务一旦失败它负责向每个参与者发送命令撤销之前操作来协调分布式的回滚。

事件编排(Event Choreography0)：没有中央协调器、没有单点风险时，每个服务产生并观察其他服务的事件，并决定是否采取行动。

高并发下的服务降级、限流

服务降级：当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作

服务降级方案：

1.分布式开关:用于实现服务的降级，然后集中式管理开关配置信息

2.自动降级分类

a)超时降级：配置好超时时间和超时重试次数和机制，并使用异步机制探测恢复情况

b)失败次数降级：一些不稳定的API，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况

c) 如要调用的远程服务挂掉了(网络故障、DNS故障、HTTP服务返回错误的状态码和RPC服务抛出异常)，则可以直接降级

d)当触发了限流超额时，可以使用暂时屏蔽的方式来进行短暂的屏蔽

3.配置中心

启动主动拉取配置： 用于初始化配置(减少第一次定时拉取周期)

发布订阅配置：用于实现配置及时变更(可以解决90%左右的配置变更)

定时拉取配置： 用于解决发布订阅失效或消失丢失的情况(可以解决9%左右的发布订阅失效的消息变更)

离线文件缓存配置：用于临时解决重启后连接不上配置中心的问题

可编辑式配置文档：用于直接编辑文档的方式来实现配置的定义

提供Telnet命令变更配置：用于解决配置中心失效而不能变更配置的常见

4.处理策略：当触发服务降级后，新的交易再次到达时，我们该如何来处理这些请求呢？

微服务视角有以下解决方案：

a)页面降级:可视化界面禁用点击按钮、调整静态页面

b)延迟服务:如定时任务延迟处理、消息入MQ后延迟处理

c)写降级：直接禁止相关写操作的服务请求

d)读降级:直接禁止相关度的服务请求

e)缓存降级:使用缓存方式来降级部分读频繁的服务接口

后端代码降级解决方案：

a)抛异常

b)返回NULL

c)调用Mock数据

d)调用Fallback处理逻辑

5.降级分类

a)降级按照是否自动化可分为：自动开关降级和人工开关降级

b)降级按照功能可分为：读服务降级、写服务降级

c)降级按照处于的系统层次可分为：多级降级

6.服务降级要考虑的问题

a)核心和非核心服务

b)是否支持降级，降级策略

c)业务放通的场景，策略

高级特性

分级降级：在项目创建之初对服务进行建模评估，划分服务的降级级别。

降级权值：主要负责服务降级的细粒度优先级抉择

降级总结：大厂建议进行完整方案的研究和实施，小厂考虑到成本和发挥的价值建议先实现分布式开关和简单的分级降级。

服务限流：面对突然的大流量情况进行限流，防止大流量压垮系统

服务限流解决方案：

1.熔断：设计之初就要开始考虑，系统出问题短时间无法恢复时开启熔断开关，拒绝流量访问避免大流量对后端的过载请求，后端也要进行动态监控当系统恢复正常时关闭熔断开关。

2.服务降级：将非核心功能进行降级处理，释放更多的资源给核心功能

3.延迟处理：前端设置一个流量缓冲池，将所有请求存放在缓冲池中(常用是队列的模式)，后端的处理能力有限不能及时处理会有一定程度延迟。

4.特权处理：将用户进行分类，让系统优先处理高级用户，其他用户请求就会延迟处理或者不处理

5.熔断技术：熔断的技术可以重点参考Netflix的开源组件hystrix的做法，主要有三个模块：熔断请求判断算法、熔断恢复机制、熔断报警。

6.计算器方法：系统维护一个计算机，来一个请求+1处理一个请求-1，当计算器值大于阈值就拒绝请求

7.队列方法：所有请求放入队列，后端从队列里取出待处理的请求，遵循先进先出原则

8.令牌桶方法：所有请求放入队列，同时设置一个令牌桶并开启一个脚本以恒定的速度往令牌桶里面放令牌，后端每次处理请求时都会在令牌桶里面拿一个令牌，当令牌拿完就不处理请求

服务限流注意实现

实时监控：系统必须要做好全链路的实时监控，才能保证限流的及时检测和处理

手动开关：除系统自动限流以外，还需要有能手动控制的开关，以保证随时都可以人工介入

限流的性能：限流的功能理论上是会在一定程度影响到业务正常性能的，因此需要做到限流的性能优化和控制

服务熔断(过载保护)：服务出现过载现象，为了防止整个系统故障而采用的保护措施。

服务熔断和服务降级的异同：

1.两者都是从可用性和可靠性着想，防止系统的整体缓慢甚至崩溃，采用的技术

2.最终让用户感受到系统某些功能暂时不可达或不可用

3.粒度基本一致(数据库只给查不能进行增删改)

4.自治性要求高，熔断基于策略的自动触发，降级可人工降级，但在微服务下要采用开关预置、配置中心等手段

5.两者的触发点不同前者是某个故障所引起，后者是整体负荷考虑

6.管理目标层次不同，前者是每个服务都需要，后者是从外围服务开始

7.实现方式不同

分布式锁的解决方案

分布式锁具有的条件：

a)分布式系统中，一个方法在同一时间只能被一个机器的一个线程执行

b)高可用、高性能的获取锁与释放锁

c)具备可重入特性

d)具备锁失效机制，防止死锁

e)具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败

数据库锁：在表创建之初对表中方法名加上索引

优点：借助数据库，方案简单

缺点：在实际实施的过程中会遇到各种不同的问题，为了解决这些问题，实现方式将会越来越复杂；依赖数据库需要一定的资源开销，性能问题需要考虑

基于redis的分布式锁

优点：高性能，借助Redis实现比较方便

缺点：线程获取锁后，如果处理时间过长会导致锁超时失效，所以，通过锁超时机制不是十分可靠

基于Zookeeper的分布式锁

优点：具备高可用、可重入、阻塞锁特性，可解决失效死锁问题

缺点：因为需要频繁的创建和删除节点，性能上不如Redis方式

分布式架构下实现分布式定时调度

定时任务的实现方式：JDK自带的Timer+TimerTask方式、spring3.0的调度任务(Scheduled Task)、Quartz框架等

前两者的缺点是应用服务器集群下会出现任务多次被调度执行的情况，因为集群的节点之间是不会共享任务信息的，每个节点上的任务都会按时执行