大数据&云计算|作为数据库核心成员，如何让淘宝不卡顿？( 三 )
解决业务层面的耦合 ， 业务清晰 。
高并发场景下 ， 垂直分库一定程度的提升IO、数据库连接数、降低单机硬件资源的瓶颈 。
能对不同业务的数据进行分级管理、维护、监控、扩展等 。
垂直分库通过将表按业务分类 ， 然后分布在不同数据库 ， 并且可以将这些数据库部署在不同服务器上 ， 从而达到多个服务器共同分摊压力的效果 ， 但是依然没有解决单表数据量过大的问题 。
4.2.4 水平分库(TDDL 核心)
水平分库是把同一个表的数据按一定规则拆到不同的数据库中 ， 每个库可以放在不同的服务器上 。
本文插图
水平分库
作用总结：
解决了单库单表数据量过大的问题 ， 理论上解决了高并发的性能瓶颈 。
水平分库核心要解决的问题：
如何知道数据在哪个库里？- 路由问题
结果合并
全局唯一主键ID
分布式事务（暂时不支持）
4.2.5 水平分库——问题解决
（1）自动路由算法
sql转发：在水平拆分后 ， 数据被分散到多张表里 。 原来的一个sql需要拆解 ， 进行转发路由 。
例：
本文插图
拆分表的数据访问——SQL转发
其中拆分和寻找的算法：怎么知道对应哪个表？即自动路由算法 。 常见的有：固定哈希算法和一致性哈希算法 。
a）固定哈希算法
本文插图
b）一致性哈希算法
一致性哈希算法在1997年由麻省理工学院提出 ， 是一种特殊的哈希算法 ， 目的是解决分布式缓存的问题 。
一致性哈希算法的优势：
极好的应对了服务器宕机的场景 。
很好的支持后期服务器扩容 。
在引入虚拟节点后：能很好的平衡各节点的数据分布 。
由于一致性哈希算法的优势 ， 此算法几乎是所有分布式场景下使用的方案 ， 包括mysql的分布式、redis的分布式等 。
本文插图
（2） 结果合并
本文插图
升华：引入fork-Join ， 提升操作速度（多线程并发重点场景 ， 代码中也很常用哦） 。
任务拆分
多路并行操作
结果合并
本文插图
（3）全局唯一主键
优势：简单高效 。
缺点：无法保证自增顺序 。
例：
表1新增一条数据 ， 于是给表1分配1000个主键ID ，直到它用完 。
同理 ， 表2、表3在新增数据时 ， 也给它们分配1000个主键ID 。 直到它用完 。
当它们的1000个主键ID用完后 ， 继续给它们分配1000个即可 。
重复下去 ， 可保证各库表上的主键不重叠 ， 唯一 。
本文插图
这种产生全局唯一id的方式相当有效 ， 保证基本的全局唯一特性和高性能的同时 ， 可以对生成id的数据库分机架分机房部署达到容灾的目的 。
4.2.6 分表分库总结
本文插图
架构师角度：
优先考虑缓存降低对数据库的读操作 。
再考虑读写分离 ， 降低数据库写操作 。
最后开始数据拆分 ， 切分模式：首先垂直（纵向）拆分、再次水平拆分 。
首先考虑按照业务垂直拆分 。
再考虑水平拆分：先分库(设置数据路由规则 ， 把数据分配到不同的库中) 。
最后再考虑分表 ， 单表拆分到数据1000万以内 。
个人开发角度：
优先使用分表分库框架（直接使用） 。
优先考虑缓存降低对数据库的读操作 。
自己垂直分表 。
自己水平分表 。
之所以先垂直拆分才水平拆分 ， 是因为垂直拆分后数据业务清晰而且单一 ， 更加方便指定水平的标准 。
4.3 分布式化
分布式化是大潮 ， 是大规模服务器最后都要走的一步 。
本文插图
分布式数据库架构演变
4.3.1 读写分离
设计读写分离的数据库 ， 有两大意义：
主从只负责各自的写和读 ， 极大程度的缓解X锁和S锁的竞争 。
从库可配置myisam引擎 ， 提升查询性能以及节约系统开销 。
说明：myisam查询效率高于默认的innodb效率 。 参考：myisam和innodb的区别 。
推荐阅读
- Wind数据显|事关500万股民！2270亿洪峰将至，8只股票流通盘增逾3倍（附名单）
- 比例尺|航天科工成功获取首幅1：2000比例尺雷达测绘数据
- Mac|可能是Mac上最好用的键鼠套装：罗技MX Keys & MX Master 3 For Mac 使用体验
- |一桩喊冤疑案，“神级”检察官从亿万人像数据中“捞”出真凶
- 青年|洪雪飞后再无阿庆嫂：53岁为2千元殒命，全是"贪心"在作怪？
- 猫眼|国庆档8天揽近40亿，猫眼数据解读票房背后的秘密
- 搜索|百度精神卫生日搜索大数据：疫情冲击实体行业 今年餐饮业者心理压力增长最明显
- 消息资讯|卡思数据：抖音VS快手，服饰主播带货数据、案例、玩法大揭秘
- 数据|展现行业领先实力，土巴兔大数据研究院将推出家装数据报告
- 增长|美团国庆大数据:江河湖海鲜爆发式增长,大闸蟹交易增速355.9%