分布式系统

分布式事务

分布式事务实现计划

• 最大致力告诉

  • 基于 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 实现令牌桶算法对接口进行限流

• 防故障蔓延

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