分布式架构设计

MarkAsh
125 阅读7分钟

高并发架构的两个指标：最大用户并发量和最大平均响应时间

架构演进

All-in-One架构

将系统的所有功能都放在一个项目中，部署一个应用服务器，一个数据库。

流量在1000万以内的架构设计

  1. 动静分离与前后端分离
  2. Nginx的高可用设计

高可用的Nginx集群是由一主多备的多个Nginx节点组成的，主Nginx负责工作，其他备Nginx不断与他同步，同时在他们之上假设一个Keepalive的虚拟IP。KeepAlive负责对所有的Nginx进行心跳检测，如果主Nginx宕机了，就会切换到另一个可用的备Nginx上，并将它升级为主节点。

  1. 多层复杂均衡的架构设计
  • Linux虚拟服务器(Linux Virtual Server, LVS)
  • Nginx负载均衡
    Nginx只支持第七层的HTTP协议与第四层的TCP长连接，虽然具有良好的I/O算法，但还是不如支持更底层协议的LVS性能高，LVS能支持二层协议的细腻IP+MAC地址，性能更高，可支持更大流量的多层复杂均衡。

流量在1000万以上的架构设计

  1. 数据库瓶颈与数据库集群

基于Oracle RAC的数据库集群，就是将数据的计算分配到多个节点上，从而起到提升系统性能的目的。然而数据库集群的设计思想还是基于Shared Disk，即虽然计算节点分布式了，但存储设备依然采用集中式。

  1. 三种类型的数据库操作
  1. 业务操作：就是大量用户在系统中进行的短事务，高并发的写操作。最好的优化措施就是降低数据库索引的使用，以提高写入速度。
  2. 随机查询：更多使用数据库索引成为最佳优化措施
  3. 统计分析：将数据通过预处理提前统计，存放到数据仓库中，每次查询在数据仓库中进行。
  1. 读写分离的数据库设计

mysql主从机的方式，写库与读库的同步靠MySQL固有的实时热备功能就能实现。然而，实施热备是一种备份的方案，因此不能对从机做任何优化，只能被动的与主机保持一致。这种方案决定了不能对写库减少索引，对读库增加索引，只能分别对他们进行优化，有较大的局限。
真正的读写分离方案：
image.png

  1. 数据分库的数据设计

当今数据库设计的核心思想是：Shard Disk和Shared Nothing
Shard Disk：它将计算节点拆分成多个节点进行分布式计算，然而最终的磁盘读写采用了集中式存储。这样设计可以很好满足数据的一致性要求，但是集中式存储成为了数据库的瓶颈。
Shared Nothing：将数据分布式存储在多个计算节点上，每个节点都只访问本地的磁盘，相互之间不共享。Shared Nothing获得了系统性能与吞吐量，损失的却是数据一致性。

  1. 纵向切分与微服务架构

数据库纵向切分就是按照业务模块将一个数据库切分成多个数据库，每个模型对应一个数据库。微服务架构就是按照约为模块纵向的切分整个系统。

  1. 横向切分与分布式数据库

横向切分在应用层面是为了某个功能模块的微服务部署多个节点，以此来应对系统的高并发，例如秒杀系统。
横向切分按照切分方式又分为范围存储和分片存储

  1. 范围存储就是根据某个字段的分区将数据存储在不同的数据库节点中，如按照地域切分，按照时间切分等
  2. 分片存储就是对某个key值进行hash计算
    数据库横向切分最好能对业务代码透明，设计如下： image.png 代理器决定数据写到哪个数据源中，同时代理器也是数据源接口，对于上层应用来说，他们还是像以前一样去访问这个数据源。

流量在5000万以上的架构设计

  1. 分布式缓存： 将缓存从应用服务器中分离出去，单独设备进行数据缓存
  2. 内存数据库：不是将数据都存储在内存的数据库，而是将一部分活动数据存储在内存中进行快速访问，当活动数据逐渐冷却下来以后，最终还要被存储到传统数据库的磁盘中。
  3. 异步化操作：通过消息队列将整个业务操作过程分为前后两个部分。这时制约吞吐量的瓶颈不再是受理端的处理速度了，而是消息队列的容量。

亿级流量的架构设计

  1. 三高的设计原则
  1. 高并发：通过层层限流熔断降级保证服务的稳定
  2. 高可用：多机房
  3. 高可靠：去中心化
  1. 服务治理
  2. 向云端的转型： 云技术逐渐从虚拟技术向着容器技术甚至Serverless方向转型。

分布式技术

  1. 分布式缓存
  1. 原理：在写入数据时，对key值进行散列处理。最简单的处理方式就是求余算法。但是求余算法在增加和减少节点时，整个数据无法重新分布。一致性性散列算法在减少节点时，会将失效的节点数据全部压倒另一个节点上。
  2. 数据一致性：解决分布式缓存数据一致性的解决方案，就是在数据库更新和删除数据的前后都分别执行一次该数据在缓存中的删除。然后为了避免最后一次删除失败，还需要定期比对缓存数据，将此比对不一致的数据从缓存中删除。
  3. Redis的分布式缓存设计：Redis部署有两种方式，
    3.1 一主多从：在系统中部署一个主redis和多个从redis，并在他们之间建立哨兵机制。平时只有主redis工作，多个从redis同步数据。当主redis失效后，通过哨兵机制就会自动切换到某个从redis，将其上升为主redis，从而保证高可用。
    3.2 redis集群：他将数据散列存储在多个redis节点中，每个节点只保存部分数据，从而将数据访问压力分解。需要为每个主redis节点配备一个从redis节点，以保证该节点的高可用。
  1. 内存数据库
  1. redis作为内存数据库的数据同步
  2. 异步化写数据方案
  1. 分布式事务
  1. XA分布式事务
    传统的XA分布式事务分为两阶段提交与三阶段提交两种类型。
  2. TCC分布式事务
    Try接口， Confirm接口，Cancel接口
  3. 基于消息的分布式事务 基于半消息的分布式事务
  1. 分布式队列

分布式队一般两种模型：生产者-消费者模型与发布者-订阅者模型

  1. 生产者-消费者模型中发送方将消息发送给队列，虽然有多个消费者，但只能有一个消费者接受到这个消息。
  2. 发布-订阅者模型时每个订阅者都有一个队列，系统将主题与多个队列绑定在一起。这样发布者是将消息发布到主题中，主题将消息分发给与他绑定的每个队列，这样每个订阅者都能接收到消息了。
  1. 分布式数据库
  1. MPP(Massively Parallel Processing大规模并行处理)数据库是一种基于Shared Nothing思想设计的分布式数据库。虽然MPP实现了分布式存储，但采用的依然是二维表的存储方式，在系统性能和可扩展性方面都存在较大的局限。
  2. NoSQL数据库：
    Redis， HBase， MongoDB
  3. New SQL数据库
    TiDB 技术架构 image.png
avatar
文章
阅读
粉丝