分布式系统

分布式系统

分布式事务

分布式事务实现方案

• 最大努力通知

  • 基于BASE理论做的保证数据最终一致性方案，基本可用，软状态，最终一致性
  • 具体实现为，写本地事务，同步写一张事务消息表，发送事务消息，消息异步通知关联系统，处理失败则利用MQ的重试功能做自动重试，超过重试次数记录失败状态，定时任务扫描手动处理

• TCC事务补偿方案

  • 需要一个事务处理器
  • 每个事务必须实现try、confirm、cancel三个方法，开发维护成本高
  • 阿里开源框架实现seata

• 基于可靠消息的最终一致性方案

  • RocketMQ有事务消息的实现
  • 具体原理为，业务方发送一个事务消息，MQ将消息落表，此时消息对消费方不可见
  • 发起方执行本地事务，通知MQ提交或回滚
  • MQ会定时查询发起方的事务执行状态，决定提交或回滚

TCC的优缺点

* 每个事务必须实现try、confirm、cancel三个方法，开发维护成本高
* 事务管理器也存在单点问题
* 事务管理器事务活动日志的存储成本

两阶段提交与三阶段提交的区别

* 三阶段提交相比两阶段提交多了第 0 步检查是否可提交，降低了反复的“锁定-释放”的可能

SpringCloud

• 微服务服务发现与调用流程
  服务提供者启动将自己的注册到eureka
  服务消费者通过serviceId到eureka拉取服务提供者的实例IP
  服务消费者通过Ribbon，默认采用轮询的方式调用消费者IP列表中实例

• ribbon的重试机制

  • 默认超时后重试原实例一次
  • 可配置重试其他实例的次数
  • 实际配置关闭了重试，因为超时失败下次请求大概率也会失败，重试容易放大故障，增加压力
• ribbon多次调用一个实例失败会将其剔除吗？
• eureka服务下线感知
  有至少30秒延时（认为延时可接受，用无损发布可解决，无损发布使用两个池，一个起来之后将流量切过去）

微服务架构

• 系统设计的分层思想
  *各层独立

    *只需了解当前层的使用，不需要关心其他层的实现细节
    *组件之间独立实现、独立部署
    *可以使用不同技术栈，实现多语言开发
    *各个服务可根据自身业务负载情况进行实例和数据等资源扩展

  *职责专一，业务边界清晰

    *可以按业务组织团队
    *服务按业务线划分，可减少业务变化时的影响面，减少服务内部修改产生的内耗

  *变化和资源隔离

    *不同层之间的代码或实现方式修改，不影响其他层
    *组件之间调用线程隔离，并引入熔断机制，可以防止服务一挂全挂的情况

  *高内聚

    *将大问题分解成小问题，有利于降低实现难度
    *代码容易理解，开发效率高
    *有利于代码功能复用
  

iso协议分层，应用分层等为什么分层

*各层独立
    *只需了解当前层的使用，不需要关心其他层的实现细节
*变化隔离
    *不同层之间的代码或实现方式修改，不影响其他层
*高内聚
    *将大问题分解成小问题，有利于降低实现难度

• 微服务的缺点
  *数据一致性，分布式事务问题。由于分布式部署不能使用数据库的事务机制，分布式事务实现复杂。
  *网络、容错问题。各服务间通过网络协议通信，需要考虑服务间调用的负载均衡、限流、熔断等问题。
  *分布式资源管理的问题。组件与服务实例管理，连接池等公共资源分配。
  *运维难度加大。运维需管理的服务组件变多
  *涉及多个服务间互相调用使自动化测试难度加大
  *可能增加沟通成本

• 微服务架构使用时机
  *业务已经成型，可以抽象定义出各类独立的功能模块进行开发管理
  *已经有比较大业务数据基础，系统功能变得庞大复杂，可以按照微服务进行组件拆分

  *业务还没有理清楚，处于快速开发、快速试错、快速迭代阶段
  *业务数据少，还未完成爆炸式增长
  *系统功能少

设计高并发、高可用系统用到的方法

高并发

高并发性，是系统从上到下优化改造的结果，从系统架构到业务处理都要注意处理

• 架构层面

  • 系统集群化

    • 反向代理lvs、网关Nginx、微服务组件、redis都是集群化部署
    • 多机同时对外提供服务
    • 服务无状态，可无限水平扩容
  • 前后端分离，静态页面服务使用CDN加速
  • 数据库分库分表、读写分离

• 业务层面

  • 加缓存

    • 加redis缓存，redis热key打散
    • Google Guava本地缓存

  • 代码优化，流程优化

    • 性能低的代码，如集合类的容量设置，多余的循环，多查的数据，多余的外部请求

  • 异步处理

    • 一些非关键业务的落库操作改为异步。如大数据业务染色的token，异步保存，超线程池后，mq延迟消费

  • 并行处理

    • future加线程池并行处理

  • MQ削峰

    • mq消费速率固定，可防止峰值请求冲垮系统
    • mq延迟消费
    • 设置开关，开启则暂时不消费，应对冲击高峰
  • 版本探测机制
  • 数据增量返回
• 压测，性能摸底

• 限流降级

  • 网关对接口直接限流，令牌桶算法对占资源的接口限流，如下单、支付等
  • 应用层对业务限流，如优惠券使用令牌桶算法，超阈值就异步处理
  • 非关键业务直接降级，返回固定值，或服务不可用，关闭风控

高可用

高可用通过集群冗余，加故障自动转移实现

• 系统集群化，多机同时提供服务

  • 入口层：DNS轮询
  • 反向代理层：lvs的keeplived+虚ip
  • 网关层：nginx的upstream多次请求一台实例失败，会将这台实例剔除
  • 微服务组件层：服务注册与发现，心跳机制

• 故障自动转移

  • 心跳机制，定期续约
  • 故障自动剔除
  • 主从切换
• 数据冗余，主从切换机制
  redis缓存：主从复制，故障转移（线上redis一主一从，16台16G）
  数据库：主从同步

• 流量分配，过载保护

  • 负载均衡：轮询、哈希、随机、固定比例、动态比例

  • 限流

    • 限流算法

      • 令牌桶：固定速率往桶中放令牌，可应对突发流量
      • 漏桶：固定速率从桶中流出请求，适应调下游服务承载能力固定的场景
      • 信号量限流：比较暴力，超过阈值直接丢弃请求

    • 分布式限流算法

      • Nginx加lua实现令牌桶算法对接口进行限流

• 防故障蔓延

  • 降级
  • 隔离
  • 超时
• 容灾：多机房、多活
• 快速回滚
• 性能指标监控