4.17 周五 数据层的软件架构技术

软件与数据

数据定义、解释

数据的软件价值

数据+语义+逻辑=业务

代码+业务=软件应用系统

数据带来的架构变化

单机MySQL->Memcached+MySQL+垂直分离->MySQL主从读写分离->分库分表+水平拆分+MySQL集群->NoSQL

单机MySQL和存在的问题

1. 数据量过大，单机存储不下（MySQL 5.7单表极限存储量500w）
2. 数据量过大，单机内存存不下索引数据
3. 访问量过大，读写混合的情况下，一个实例受不了

Memcached+MySQL+垂直分离

• 使用缓存减轻对数据库的压力，将频繁访问的数据放置于缓存中；
• 垂直分离指按业务划分不同的数据，放在不同的数据库里（例如支付业务、其他业务放到不同的数据库里）

MySQL主从读写分离

• 主从复制：容灾备份、缓存备份，保证数据完整性
• 读写分离：增删改是写，查是读；使用不同的数据库服务器来完成写和读，分工明确

分库分表+水平拆分+MySQL集群

如果不进行分库分表的话，随时间和业务发展，库里的表会越来越多，表里的数据也越来越多，增删改查的开销也会越来越大

NoSQL Not Only SQL

云时代对DB的需求：

1. 高性能
2. 海量存储
3. 高伸缩与高可用性

数据层非功能需求与架构技术

• 存储高性能：读写分离、数据缓存、分库分表、NoSQL
• 存储高可用：主从、CAP理论
• 存储高扩展：分库分表、NoSQL

读写分离

基本原理

将数据库读写分散到不同节点


• 主从集群，一主一从，一主多从都OK
• 主机读写，从机只读
• 数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据
• 业务服务器将写操作发给主机，将读操作发给从机

复制延迟问题

如果向从机读取数据时，它还没被主机复制过去，就可能引起问题

解决方案：

1. 写操作后的读操作指定发给主机
2. 读从机失败后再读一次主机
3. 关键业务读写操作全部指向主机，非关键业务采用读写分离

分配机制

1. 程序代码封装
2. 中间件封装

主备复制的实现


1. 主机存储数据，通过复制通道将数据复制到备机
2. 正常情况下，客户端无论读写都发给主机，备机不对任何读写服务
3. 主机故障也是如上，系统处于不可用状态
4. 3发生时，如果主机恢复了，则返回正常；否则需要人工将备机升级为主机，增加新的备机，切换访问链路
5. 3发生时且主机无法恢复，如果有数据尚未复制到备机，需要人工排查、恢复，也有风险是部分数据丢失
6. 的

此方案的优缺点：

优点：客户端不需要感知备机的存在；对于主备机

主从复制的实现

1. 主机存储，复制到备机
2. 正常时，写操作给主机，读操作可主可从
3. 主机故障，无法写操作，仅可读
4. 若主机可恢复，返回正常
5. 若不能恢复，要人工升级从机为主机，人工增加新机器为从机
6. 仍可能丢失数据
7. 主从复制延迟会出现数据不一致

此方案优缺点：

优点：

1. 主机故障，读操作不受影响

缺点：

同样需要人工干预

两个方案共同点：

1. 都有一个主机一个备机

主从倒换、主备倒换

互连式

主备机直接建立状态传递的渠道

中介式

• 主、备都进行状态上报
• 初始主备机都是“备机”，并且如果与中介断开连接，自己降级为备机，可能出现双备机；
• 主机与中介断联后，中介通知备机，备机将升级为主机；
• 此后主机如果恢复，将作为备机的身份存在

上述两者之间还存在数据赋值，是当时的主机向备机复制

模拟式

主备机之间并不传递任何状态数据，而是备机模拟成为一个客户端，向主机发起模拟的读写操作，根据读写操作的响应情况来判断主机的状态。

主主复制

两台都是主机，互相复制数据给对方，都能够读写

数据集中集群

也称为一主多备/一主多从，数据往主机写

数据分散集群

每个服务器负责存储一部分数据，也会备份一部分数据。

关于如何分散存储，需要考虑：

1. 均衡性
2. 容错性：部分服务器故障后需要分配给其他服务器
3. 可伸缩性

对比：

1. 写数据角色
   1. 集中集群：只写到主机
   2. 分散集群：任意服务器都可读写
2. 应用场景
   1. 集中集群适用于数据量不大，集群机器数量不多的场景，如ZooKeeper集群，个位数机器
   2. 分散集群由于伸缩性，适合数据量巨大的业务场景，如Hadoop集群，可达上千台服务器