分布式架构的演进过程

从一个电商网站开始

一个计算机的性能，CPU，磁盘IO，网络IO，内存

CPU/IO/内存：
1. 主要是上下文的切换，因为每个 CPU 核心在同一时刻只能执行一个线程，而 CPU 的调
度有几种方式，比如抢占式和轮询等，以抢占式为例，每个线程会分配一定的执行时间，
当达到执行时间、线程中有 IO 阻塞或者有高优先级的线程要执行时。CPU 会切换执行其
他线程。而在切换的过程中，需要存储当前线程的执行状态并恢复要执行的线程状态，这
个过程就是上下文切换。比如 IO、锁等待等场景下也会触发上下文切换，当上下文切换
过多时会造成内核占用比较多的 CPU。

2. 文件 IO，比如频繁的日志写入，磁盘本身的处理速度较慢、都会造成 IO 性能问题

3. 网络 IO，带宽不够

4. 内存，包括内存溢出、内存泄漏、内存不足

实际上不管是应用层的调优也好，还是硬件的升级也好。其实无非就是这几个因素的调整。

计算机水平和垂直扩容

• 垂直

  • 加CPU

    • 好：

      • 处理阻塞IO

    • 坏：

      • 锁竞争

      • 并发请求是控制的

      • 任务是单线程

  • 加内存

    • 好

      • IO速度更快

    • 坏

      • 堆大小固定，没用

• 水平

  • 多加机器

    • 问题：

      • 路由到那台服务器上去

        • 负载均衡

          • 轮询法

            • 优：顺序

            • 缺：服务器配置，性能

          • 随机法

            • 优：简单

            • 缺：数据量需达到一定量

          • 源地址哈希法

            • 同一个客户端，服务端不变，请求同一个 取模

          • 加权轮询法

            • 配置高，负载低，分配更高权重，处理更多请求

          • 最小连接数法

            • 请求次数均衡，并不代表负载的均衡，选取服务器连接数最小的一台

      • session共享

        • 无状态变成有状态

          • 服务器端实现的session复制，session共享

            • 缺：同步sesion造成网络开销，只要session变化，就要更新

            • 每台服务器都要保存全部的session，不适合多台集群

          • session不保存到本机而存到集中存储的地方，修改也是修改集中存储的地方

            • 缺：读写session数据，引入了网络操作，相对于本机而言，增加了时延和不稳定，2.如果集中存储的session的机器，或集群挂了，会影响到应用

          • session维护在客户端

            • 安全性问题，要加密

 

服务器够用了，可以处理这么多，并发了，但是，数据库连接不够用了，这个时候出现了

数据库压力变大，读写分离开始步入

读的压力大，写的比较少，

读写分离

• 读写分离

  • 问题1 数据如何同步

    • 新建读库解决主库读的压力，首先要解决这么复制数据到读库，数据库系统提供了这个功能eg：Master+slave

  • 问题2 应用数据源如何路由

    • 根据不同的情况，选择不同的数据库源，读就读库，新增，就新增库

    • 搜索引擎其实是一个读库

分布式存储

引入分布式存储

• Nosql

• 数据缓存

  • 热点数据存，

  • 时间到期，移除

  • 改变进行更新

• 页面缓存

• redis、mongoDB、cassandra、HBase

通过集群提供一个高容量，高并发访问，数据冗余

 

又来问题了，通过读写分离，及某些场景用分布式存储系统替换关系型数据库，降低了主库的压力

解决了数据存储的方面的问题，不过随业务的增长，堆数据提出了，

垂直拆分，水平拆分.

• 垂直拆分

  • 不同业务的数据，拆分到不同的数据库当中，比如用户，交易，商品

    • 问题

      • 如何处理原来单机跨业务的事务

        • 1. 使用分布式事务解决

          1. 去掉事务或者不追求强事务的

          支持

    • 优

      • 将所有的业务数据都放在一个数据中的压力问题

• 水平拆分

  • 将同一张表进行水平拆分到两个数据库当中，为什么呢？因为这张表，已经达到了单给数据库的瓶颈。

    • 跟读写分离比，读写只是处理了，读的压力，并没有解决大量的数量的更新

    • 跟垂直拆分，一个是将业务进行分拆在不同的库，一个是将同一张表进行字段的拆分

  • 影响

    • sql路由，那个条件，来决定当前请求发到那个数据库中

    • 主键的处理，不能自增id，要全局id

    • 由于同一个业务，数据被拆分到不同的数据库，涉及查询要跨两个数据库获取，如果数据量大，需要分页，比较难处理

这些都是数据方面的出路，接下来是，

业务方面的处理

• 第一，应用越来越大

  • 把应用拆开

    • 比如，将用户，商品，交易，分成3个部分

• 第二，服务化道路

  • web系统

  • 服务中心

  • 对应的数据

  什么是分布式架构

  • 分布在网络计算机上

  • 组件之间仅仅通过消息传递来通信并协调

  为什么？

  • 升级单机处理能力性价比越来越低

  • 单机处理能力存在瓶颈

  • 对于稳定性和可用性的要求，单机环境是提供不了的