分布式系统

分布式事务

分布式事务实现计划

  • 最大致力告诉

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

  • 防故障蔓延

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