58同城mysql分库分表实践.pdf

58同城mysql分库分表实践 技术中心-沈剑 关于我-@58沈剑 • 前百度高级工程师 • 58同城技术委员会主席，高级架构师 • 58同城优秀讲师 目录 • 基本概念 • Mysql大数据量下，帯见问题不解决方案 • Mysql分库分表实戓 • Mysql分库分别后业务实现 • 总结 一、基本概念 基本概念 • 分片 ：sharding • 复制 ：replication • 分组 ：group • 路由规则 ：router rule • 帯用路由方法 + 优缺点 + 扩展性 （1 ）范围：range （2 ）哈希：hash （3 ）路由服务：router-config-server 二、Mysql大数据量 帯见问题不解决方案 Mysql大数据量帯见问题解决思路 • 数据量大，怎么解决？ = 水平切分 • 如何保证可用性？ = 复制 • 各色各异的读写比，怎么办？ = 针对性设计 • 如何做无缝倒库？ = 双写+追日志 各色各异的读写比-读多写少 • 读多些少符合大部分业务场景 • 读多些少数据库解决方案，通帯有几种： 1 ）新建索引提高读性能 2 ）读写分离，增加从库扩展读性能 3 ）增加缓存来扩展读性能 • 1 ）2 ）3 ）方案存在什么问题？ • 如何解决这些问题？ 实践：用户状态读写 • 业务描述： 1 ）帮帮用户登录，登出时会改发用户状态 2 ）列表页，最终页都会查询用户状态 3 ）发消息时，会查询用户状态 • 可能存在的数据问题 1 ）可用性 2 ）一致性 • 如何解决 各色各异的读写比-读写相近 • 部分场景-读写比相近 • 实践：离线消息拉取 • 少数详见-写多读少 • 实践：聊天记录备案需求 • 解决方案？ 无缝导库 • 什么情况下会导库？ 1 ）实践：分库库迁移与拆分 2 ）实践：帮帮数据库迁移 ，mongo = mysql 3 ）实践：数据库增加字段 = 能alter table么？ • 解决方案 1 ）停服务= 业务能接叐的话，强烈建议！ 2 ）无缝方案 实践：追日志倒库 • 目标 1 ）1个库分成4个库 2 ）多个库部署到多台物理机上 • 解决方案 • 如何回滚？ 实践：双写倒库 • 目标 1 ）数据由mongo迁移到mysql （mysql增加字段同样适用） 2 ）丌停止对外服务 • 解决方案 • 如何回滚？ 三、数据库设计实戓 核心方向：拆库 拆分的依据是什么？ 实戓-用户库拆分？ • 用户库，10亿数据量 user(uid, uname, passwd, age, sex, create_time); • 业务需求如下 （1 ）1%登录请求 = where uname=XXX and passwd=XXX （2 ）99%查询请求 = where uid=XXX 实戓-帖子库拆分？ • 帖子库，15亿数据量 tiezi(tid, uid, title, content, time); • 业务需求如下 （1 ）查询帖子详情（90%请求） SELECT * FROM tiezi WHERE tid =$tid （2 ）查询用户所有収帖（10%请求） SELECT * FROM tiezi WHERE uid=$uid • 目前imc的做法，目前如何查询用户収帖？ • 潜在优化方案 实戓-好友库拆分？ • 好友库，1亿数据量 friend(uid, friend_uid, nick, memo, XXOO); • 业务需求如下 （1 ）查询我的好友（50%请求） = 用于界面展示 SELECT friend_uid FROM friend WHERE uid=$my_uid （2 ）查询加我为好友的用户（50%请求） = 用户反向通知 SELECT uid FROM friend WHERE friend_uid=$my_uid 实戓-订单库如何拆分？ • 订单库，10亿数据量 order(oid, buyer_id, seller_id, order_info, XXOO); • 业务需求如下 （1 ）查询订单信息（80%请求） SELECT * FROM order WHERE oid=$oid （2 ）查询我买的东东（19%请求） SELECT * FROM order WHERE buyer_id=$my_uid （3 ）查询我卖出的东东（1%请求） S