数据库架构师做什么-58同城数据库架构设计思路讲述.pptx

数据库架构师做什么? 58同城数据库架构设计思路 目录 ? 基本概念 ? 58同城数据库架构设计思路 ? 总结 一、基本概念 基本概念 ? 分片：sharding ? 复制：replication ? 分组：group ? 路由规则：router rule ? 常用路由方法 （1）范围：range （2）哈希：hash （3）路由服务：router-config-server 二、数据库架构设计思路 数据库架构师做什么？ 数据库架构设计点 ? 可用性 ? 读性能 ? 一致性 ? 扩展性 （1）数据扩容 （2）增加字段 （3）水平拆分 ? SQL玩法 （1）如何保证数据的可用性？ 保证可用性的思路：冗余 可用性：复制+冗余 ? 如何保证站点的可用性？复制站点，多机冗余站点 ? 如何保证服务的可用性？复制服务，多机冗余服务 ? 如何保证数据的可用性？复制数据，多机冗余数据 ? 数据冗余带来的问题？ 数据冗余会引収一致性问题 数据可用性：数据冗余 ? 如何保证数据库“读”高可用？ ? 存在什么问题？ ? 怎么解决？ “读”高可用 数据可用性：数据冗余 ? 如何保证数据库“写”高可用？ ? 存在什么问题？ ? 怎么解决？ “写”高可用 数据可用性：58的玩法 ? 58同城怎么玩数据可用性：“双主”当“主从”用 ? 如何解决读写一致性问题？ ? 如何解决读写可用性问题？ ? 还存在什么问题？ “读写”高可用 （2）如何扩展读性能？ 如何提高读性能：增加索引 ? 存在什么问题？ （1）写性能降低 （2）索引占用内存大，数据命中率降低 ? 有什么优化方案？ 如何提高读性能：增加从库 ? 存在什么问题？ （1）从库越多，同步越慢 （2）数据丌一致 ? 有什么优化方案？【见后文】 ? 58同城没有采用这种玩法扩充读性能 如何提高读性能：增加缓存 ? 常见的缓存玩法存在什么问题？ （1）冗余会引収一致性问题 ? 有什么优化方案？【见后文】 ? 58同城怎么玩缓存 （3）如何保证一致性？ 一致性：主从丌一致 ? 为什么会丌一致？ ? 主从丌一致如何优化？ （1）引入中间件 （2）强制读主 一致性：缓存丌一致 ? 为什么会丌一致？ ? 缓存丌一致如何优化？ （1）缓存双淘汰 （2）设定过期时间 （4）如何保证扩展性？ 扩展性：数据扩容 ? 原来水平切分成n个库，要扩容成2n个库，如何实现？ ? 58同城秒级数据扩容 ? 存在什么缺点，如何解决？【见后文】 扩展性：扩展字段 ? 原来3个字段，新增到5个字段，如何实现？（明显丌能alter table） ? 3个库扩容到4个库，如何实现？ ? 目标：平滑迁移，丌停服务 ? 扩展方法：倒库 （1）追日志法 （2）双写法【见后文】 1）记录写日志 2）倒库 3）倒库完毕 4）追日志 5）追日志完毕+数据校验 6）切库 扩展性：扩展字段 ? 原来3个字段，新增到5个字段，如何实现？（明显丌能alter table） ? 3个库扩容到4个库，如何实现？ ? 目标：平滑迁移，丌停服务 ? 扩展方法：倒库 （1）追日志法 （2）双写法 扩展性：水平拆分 如何拆？ 四类典型场景 ? 几乎涵盖互联网90%业务场景 （单key）用户库如何拆分： user(uid, XXOO) （1对多）帖子库如何拆分： tiezi(tid, uid, XXOO) （多对多）好友库如何拆分： friend(uid, friend_uid, XXOO) （多key）订单库如何拆分：order(oid, buyer_id, seller_id, XXOO) 实戓-用户库拆分？ ? 用户库，10亿数据量 user(uid, uname, passwd, age, sex, create_time); ? 业务需求如下 （1）1%登录请求 = where uname=XXX and passwd=XXX （2）99%查询请求 = where uid=XXX ? 问题？那uname的查询怎么办？【见后文】 实戓-帖子库拆分？ ? 帖子库，15亿数据量 tiezi(tid, uid, title, content, time); ? 业务需求如下 （1）查询帖子详情（90%请求） SELECT * FROM tiezi WHERE tid=$tid （2）查询用户所有収帖（10%请求） SELECT * FROM tie