分库分表

分库分表

拆分的目的是什么？

拆库，仍是拆表？二者结合？

拆库方便进行扩容

其规则设计的好，表也能够移动

拆成多少合适

单实例最多1千张表

单表按1千万~1亿条数据规划，10G左右

对于大字段blob，text字段建议拆分并压缩，用主键关联(查询)

每一个表必须有主键，主键采用自增int/bigint

单库200~400张表

Hash拆分

拆分红10库10表

dbRule: db + (id/10 % 10)

tbRule: t + (id % 10)

Range拆分

id < 1千万在DB0

1千万 <= id <2千万 DB1

按日期拆分

create_time按月一个表 

按业务垂直拆分

用户基本资料库

好友关系库

等等

 

数据库拆分后续

拆分策略最好一开始就想清楚，不要在实施过程当中多变

优先采用可控性强的策略，也就是更方便后续扩展的策略

不单纯追求拆分后的均衡离散性 

拆分以后，须要选择一个合适的proxy方案

不必定非要proxy，单总体改造代价必定不能过高

proxy方案选择更适合本身场景的

 

数据分级决定缓存策略不一样

第一级：订单数据和流水数据，这两块数据对实时性和精确性要求很高，因此不添加任何缓存，读写操做将直接操做数据库 

第二级：用户相关数据，这些数据和用户相关，具备读多写少的特征，因此咱们适用redis进行缓存

第三级：配置信息，这些数据和用户无关，具备数据量小，频繁读，几乎不修改的特征，可使用本地内存进行缓存 

 

架构方案关键点 

如何保证多节点的写入可用性

keepalived+双主，但只写一个节点

PXC，多库多表并行写入

MHA，一主多从，或者双主多从

大杀器，MGR 

如何提升读可用性

一主一从，从故障时切换到主

一主多从，多从可作高可用，或者根据状况切到主

双主多从，同上

写压力分摊

垂直拆分

水平拆分

混合方案

读压力分摊

多从

nosql/cache

而且采用多级分层方案 

大数据量，而且进行分库分表后，不建议的SQL

复杂链接查询

跨库、跨表查询

分布式事务

子查询

涉及到跨库跨表查询时，一般须要好的中间层来解决

这个中间层大多靠自主开发，不多有现成的通用方案

跨表JOIN代价较高时，甚至能够考虑反范式，把多列存放在一个冗余表中，更方便查询 

 

如何应对瞬间暴增的业务压力 

快速响应，但延迟服务

前端利用CDN、缓存、静态内容抗住第一道访问

前端页面/APP端/转发层，增长刷新频率控制

动态请求须要有流控

业务隔离

区分不一样业务所在资源池

重点业务，重点保障

弹性资源池(云) 

 

秒杀业务 

面临问题：高并发、超卖

前端提早准备措施：静态化、扩容、限流、服务降级机制

后端：限制MySQL的并发线程(并启用thread pool)、订单提交时再次判断，是否还有库存，能够直接使用AliSQL分支版本(应对秒杀场景特别有效)

提早把商品分摊到多个Redis实例中，根据用户ID哈希分配到各实例 

Redis中保存2个队列，一个被秒的，一个待秒的

还有个队列保存已经参加过秒杀的用户列表

秒杀成功后，被秒队列+1，待秒队列-1，加入已秒用户列表

读取已秒队列及已秒用户列表，更新到MySQL中

重点：入口请求有序排队避免蜂拥，合并写请求减少写压力

 

互联网经常使用高可用架构方案

架构案例

 

NOSQL、NEWSQL对MySQL的影响

不管NOSQL仍是NEWSQL，都不能很好支持事务原子性

NOSQL更多的是cache做用

简单的KV数据，能够用innodb memcached plugin解决

复杂的文档数据，能够用JSON数据类型解决

NOSQL因为弱关系约束，后期反倒多是灾难

NEWSQL主要解决数据分布式存储

真正须要存储海量数据时，更多的是考虑用大数据解决方案 

 

数据库安全 

防止SQL注入

SQLmap

BSQL Hacker

Havij

Safe3 SQL Injector

防止长时间运行的SQL

及时干掉

启用timeout