软件与数据
数据定义、解释
数据的软件价值
数据+语义+逻辑=业务
代码+业务=软件应用系统
数据带来的架构变化
单机MySQL->Memcached+MySQL+垂直分离->MySQL主从读写分离->分库分表+水平拆分+MySQL集群->NoSQL
单机MySQL和存在的问题
- 数据量过大，单机存储不下（MySQL 5.7单表极限存储量500w）
- 数据量过大，单机内存存不下索引数据
- 访问量过大，读写混合的情况下，一个实例受不了
Memcached+MySQL+垂直分离
- 使用缓存减轻对数据库的压力，将频繁访问的数据放置于缓存中；
- 垂直分离指按业务划分不同的数据，放在不同的数据库里（例如支付业务、其他业务放到不同的数据库里）
MySQL主从读写分离
- 主从复制：容灾备份、缓存备份，保证数据完整性
- 读写分离：增删改是写，查是读；使用不同的数据库服务器来完成写和读，分工明确
分库分表+水平拆分+MySQL集群
如果不进行分库分表的话，随时间和业务发展，库里的表会越来越多，表里的数据也越来越多，增删改查的开销也会越来越大
NoSQL Not Only SQL
云时代对DB的需求：
1. 高性能
2. 海量存储
3. 高伸缩与高可用性
数据层非功能需求与架构技术
- 存储高性能：读写分离、数据缓存、分库分表、NoSQL
- 存储高可用：主从、CAP理论
- 存储高扩展：分库分表、NoSQL
读写分离
基本原理
将数据库读写分散到不同节点
- 主从集群，一主一从，一主多从都OK
- 主机读写，从机只读
- 数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据
- 业务服务器将写操作发给主机，将读操作发给从机
复制延迟问题
如果向从机读取数据时，它还没被主机复制过去，就可能引起问题
解决方案：
- 写操作后的读操作指定发给主机
- 读从机失败后再读一次主机
- 关键业务读写操作全部指向主机，非关键业务采用读写分离
分配机制
- 程序代码封装
- 中间件封装
主备复制的实现
- 主机存储数据，通过复制通道将数据复制到备机
- 正常情况下，客户端无论读写都发给主机，备机不对任何读写服务
- 主机故障也是如上，系统处于不可用状态
- 3发生时，如果主机恢复了，则返回正常；否则需要人工将备机升级为主机，增加新的备机，切换访问链路
- 3发生时且主机无法恢复，如果有数据尚未复制到备机，需要人工排查、恢复，也有风险是部分数据丢失
- 的
此方案的优缺点：
优点：客户端不需要感知备机的存在；对于主备机
主从复制的实现
- 主机存储，复制到备机
- 正常时，写操作给主机，读操作可主可从
- 主机故障，无法写操作，仅可读
- 若主机可恢复，返回正常
- 若不能恢复，要人工升级从机为主机，人工增加新机器为从机
- 仍可能丢失数据
- 主从复制延迟会出现数据不一致
此方案优缺点：
优点：
- 主机故障，读操作不受影响
缺点：
同样需要人工干预
两个方案共同点：
- 都有一个主机一个备机
主从倒换、主备倒换
互连式
主备机直接建立状态传递的渠道
中介式
- 主、备都进行状态上报
- 初始主备机都是“备机”，并且如果与中介断开连接，自己降级为备机，可能出现双备机；
- 主机与中介断联后，中介通知备机，备机将升级为主机；
- 此后主机如果恢复，将作为备机的身份存在
上述两者之间还存在数据赋值，是当时的主机向备机复制
模拟式
主备机之间并不传递任何状态数据，而是备机模拟成为一个客户端，向主机发起模拟的读写操作，根据读写操作的响应情况来判断主机的状态。
主主复制
两台都是主机，互相复制数据给对方，都能够读写
数据集中集群
也称为一主多备/一主多从，数据往主机写
数据分散集群
每个服务器负责存储一部分数据，也会备份一部分数据。
关于如何分散存储，需要考虑：
- 均衡性
- 容错性：部分服务器故障后需要分配给其他服务器
- 可伸缩性
对比：
- 写数据角色
- 集中集群：只写到主机
- 分散集群：任意服务器都可读写
- 应用场景
- 集中集群适用于数据量不大，集群机器数量不多的场景，如ZooKeeper集群，个位数机器
- 分散集群由于伸缩性，适合数据量巨大的业务场景，如
Hadoop集群，可达上千台服务器