结合实践对水平分库做一个系统地剖析

　随着大型互联网应用的发展，海量数据的存储和访问成为系统设计的瓶颈，分布式处理成为不二选择。数据库拆分，特别是水平分库是个高难度的活，涉及一系列技术决策。
　　本人有幸负责1号店订单水平分库的方案设计及实施落地，这里结合项目实践，对水平分库做一个系统地剖析，希望为大家水平分库（包括去IOE）改造提供思路，主要内容包括：
　　水平分库说明分库维度– 根据哪个字段分库分库策略– 记录如何分配到不同库分库数量– 初始库数量及库数量如何增长 路由透明– 如何实现库路由，支持应用透明分页处理– 跨多个库的分页case如何处理Lookup映射—非分库字段映射到分库字段，实现单库访问整体架构– 分库的整体技术架构 上线步骤– 分库改造实施上线项目总结
　　水平分库说明
　　数据库拆分有两种：
　　1）垂直分库
　　数据库里的表太多，拿出部分到新的库里，一般是根据业务划分表，关系密切的表放同一数据库，应用修改数据库连接即可，比较简单。
　　2）水平分库
　　某张表太大，单个数据库存储不下或访问性能有压力，把一张表拆成多张，每张表存放部分记录，保存在不同的数据库里，水平分库需要对系统做大的改造。
　　
　　1号店核心的订单表存储在Oracle数据库，记录有上亿条，字段有上百个，访问的模式也是复杂多样，随着业务快速增长，无论存储空间或访问性能都面临巨大挑战，特别在大促时，订单库已成为系统瓶颈。
　　通常有两种解决办法：
　　1）Scale up，升级Oracle数据库所在的物理机，提升内存/存储/IO性能，但这种升级费用昂贵，并且只能满足短期需要。
　　2）Scale out，把订单库拆分为多个库，分散到多台机器进行存储和访问，这种做法支持水平扩展，可以满足长远需要。
　　1号店采取后一种做法，它的订单库主要包括订单主表/订单明细表（记录商品明细）/订单扩展表，水平分库即把这3张表的记录分到多个数据库中，订单水平分库效果如下图所示：
　　
　　原来一个Oracle库被多个MySQL库取代，支持1主多备和读写分离，主备之间通过MySQL自带的数据同步机制（SLA《1秒），所有应用通过订单服务访问订单数据。
　　分库维度
　　水平分库首先要考虑根据哪个字段作为分库维度，选择标准是尽量避免应用代码和SQL性能受影响，这就要求当前SQL在分库后，访问尽量落在单个库里，否则单库访问变成多库扫描，读写性能和应用逻辑都会受较大影响，。