作为数据库核心成员如何让淘宝不卡顿一点,淘宝app卡顿( 四 ) _为什么淘宝一上就卡

文章插图
拆分表的数据访问——SQL转发
其中拆分和寻找的算法：怎么知道对应哪个表？即自动路由算法。常见的有：固定哈希算法和一致性哈希算法。
a）固定哈希算法

文章插图
b）一致性哈希算法
一致性哈希算法在1997年由麻省理工学院提出，是一种特殊的哈希算法，目的是解决分布式缓存的问题。
一致性哈希算法的优势：
极好的应对了服务器宕机的场景。很好的支持后期服务器扩容。在引入虚拟节点后：能很好的平衡各节点的数据分布。由于一致性哈希算法的优势，此算法几乎是所有分布式场景下使用的方案，包括mysql的分布式、redis的分布式等。

文章插图
（2）结果合并

文章插图
升华：引入fork-Join，提升操作速度（多线程并发重点场景，代码中也很常用哦）。
任务拆分多路并行操作结果合并

文章插图
（3）全局唯一主键
算法：基于数据库更新＋内存分配。在数据库中维护一个ID，获取下一个ID时，会对数据库进行ID=ID 100 WHERE ID=XX，拿到100个ID后，在内存中进行分配。
优势：简单高效。缺点：无法保证自增顺序。例：
水平分库分表：一拆三场景。主键分隔值：1000 。表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的区别。

文章插图
核心问题：
数据的备份同步问题：参考4.4.3 。读写比例支持动态设置：结合业务，如淘宝可设置为20:1 。4.3.2 容灾