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

【作为数据库核心成员如何让淘宝不卡顿一点,淘宝app卡顿】时间倒转穿越回2007年年底
一觉醒来，我还是照常去上班，走到西溪湿地附近，马路没有，高楼没有，有的是小山坡和金色的稻田。一番打听之后，才知道此时没有什么西溪园区。没办法，硬着头皮去滨江上班，一刷卡，才发现我并不是我，我现在的身份是淘宝数据库团队的核心成员。
此时全国上下在迎接着奥运的到来，一片祥和。淘宝网成交额突破400亿，日活用户达1000万。工程师们都非常兴奋，磨刀霍霍。但是也遇到了棘手的问题。
一分析当前的现状
1.1 现有业务背景
淘宝网给中国市场提供了全新的购物形式，在互联网的大潮下，用户暴增，成交量暴增，公司持续飞速增长。截止2007年，淘宝网成交额突破400亿，日活用户达1000万。全天有1000万用户访问淘宝。而绝大多数用户都是在网上逛，什么也不买。1.2 当前的问题
1.2.1 用户体验与反馈
用户普遍反馈逛淘宝卡顿，操作延迟特别明显。
1.2.2 分析核心原因
大量的用户在浏览商品，并不下单。这个人数和场景的比例有20:1 。说明：数据库模式事务，写操作会对表或者行加写锁，阻塞读操作。业务数据集中在一张表里，如user表。一张表里数据破几千万。查询一条数据需要好几秒（单表数据量太大）。说明：一张表数据提升，必然会导致检索变慢，这是必然事实。不论如何加索引或者优化都无法解决的。所有表集中在一个库里，所有库集中在一个机器里。数据库集中在一台机器上，动不动就说硬盘不够了（单机单库）。说明：所有业务共用一份物理机器资源。机器存在瓶颈：磁盘和CPU不够用且后期拓展性不佳。1.2.3 总结问题
20:1读写比例场景。单表单库数据量太大。小型机与单机场景，抗不住当前规模。

文章插图
当前现状
二我要做什么？
如何满足当前每天1000万用户逛淘宝的需求，且用户体验好（最基本要求：响应快）。如何满足未来有上亿用户的访问，甚至是同时访问，且用户体验好（最基本要求：响应快）。高筑墙，广积粮，积极做好准备。
提炼核心：
提高数据库操作速度。同时能应对未来规模变化。三我能做什么?
为实现以上两大目标，我能做什么？
3.1 提高数据库操作速度，通用方法
提炼常见的通用方法：
sql优化排除语法问题，烂sql下推优化下推的目的：提前过滤数据 -> 减少网络传输、并行计算。
提前过滤数据小表驱动大表等建立索引查询频率高的热点字段区分度高的(DISTINCT column_name)/COUNT(*)，以主键为榜样（1/COUNT(*)）长度小尽量能覆盖常用查询字段注意索引失效的场景分库分表垂直分库分表水平分库分表读写分离缓存的使用等等。
3.2 如何应对未来的持续变化？
必须支持动态扩容。必须走分布式化路线，百分百不动摇。3.3 结合定位，分析自己能做的
3.3.1 分析我们的架构定位
（1）大前提
我们要做通用型框架，不参与业务。从软件设计原则出发，开闭原则：对扩展开放，对修改关闭。说明：大修改就意味着不稳定，因此：我们要做到尽可能少的修改原来的代码。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。
（2）当前架构现状
淘宝网主要使用hibernate/ibatis传统框架：