您可以捐助,支持我们的公益事业。

金额: 1元 10元 50元

姓名:

邮件:

电话:

公司:

说明:

认证码: 验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   专家招募  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
58同城数据库架构设计思路
 
来源: 程序员日志 发布于: 2015-05-13
来自于要资料   1601 次浏览     评价:      
 

(1)可用性设计

解决思路:复制+冗余

副作用:复制+冗余一定会引发一致性问题

保证“读”高可用的方法:复制从库,冗余数据,如下图

带来的问题:主从不一致

解决方案:见下文

保证“写”高可用的一般方法:双主模式,即复制主库(很多公司用单master,此时无法保证写的可用性),冗余数据,如下图

带来的问题:双主同步key冲突,引不一致

解决方案:

a)方案一:由数据库或者业务层保证key在两个主上不冲突

b)方案二:见下文

58同城保证“写”高可用的方法:“双主”当“主从”用,不做读写分离,在“主”挂掉的情况下,“从”(其实是另外一个主),顶上,如下图

优点:读写都到主,解决了一致性问题;“双主”当“主从”用,解决了可用性问题

带来的问题:读性能如何扩充?解决方案见下文

(2)读性能设计:如何扩展读性能

最常用的方法是,建立索引

建立非常多的索引,副作用是:

a)降低了写性能

b)索引占内存多了,放在内存中的数据就少了,数据命中率就低了,IO次数就多了

但是否想到,不同的库可以建立不同的索引呢?如下图

TIPS:不同的库可以建立不同索引

主库只提供写,不建立索引

online从库只提供online读,建立online读索引

offline从库只提供offline读,建立offline读索引

提高读性能常见方案二,增加从库

上文已经提到,这种方法会引发主从不一致问题,从库越多,主从时延越长,不一致问题越严重

这种方案很常见,但58没有采用

提高读性能方案三,增加缓存

传统缓存的用法是:

a)发生写请求时,先淘汰缓存,再写数据库

b)发生读请求时,先读缓存,hit则返回,miss则读数据库并将数据入缓存(此时可能旧数据入缓存),如下图

带来的问题:

a)如上文所述,数据复制会引发一致性问题,由于主从延时的存在,可能引发缓存与数据库数据不一致

b)所有app业务层都要关注缓存,无法屏蔽“主+从+缓存”的复杂性

58同城缓存使用方案:服务+数据+缓存

好处是:

1)引入服务层屏蔽“数据库+缓存”

2)不做读写分离,读写都到主的模式,不会引发不一致

(3)一致性设计

主从不一致解决方案

方案一:引入中间件

中间件将key上的写路由到主,在一定时间范围内(主从同步完成的经验时间),该key上的读也路由到主

方案二:读写都到主

上文已经提到,58同城采用了这种方法,不做读写分离,不会不一致

数据库与缓存不一致解决方案

两次淘汰法

异常的读写时序,或导致旧数据入缓存,一次淘汰不够,要进行二次淘汰

a)发生写请求时,先淘汰缓存,再写数据库,额外增加一个timer,一定时间(主从同步完成的经验时间)后再次淘汰

b)发生读请求时,先读缓存,hit则返回,miss则读数据库并将数据入缓存(此时可能旧数据入缓存,但会被二次淘汰淘汰掉,最终不会引发不一致)

(4)扩展性设计

(4.1)58同城秒级别数据扩容

需求:原来水平切分为N个库,现在要扩充为2N个库,希望不影响服务,在秒级别完成

最开始,分为2库,0库和1库,均采用“双主当主从用”的模式保证可用性

接下来,将从库提升,并修改服务端配置,秒级完成扩库

由于是2扩4,不会存在数据迁移,原来的0库变为0库+2库,原来的1库变为1库和3库

此时损失的是数据的可用性

最后,解除旧的双主同步(0库和2库不会数据冲突),为了保证可用性增加新的双主同步,并删除掉多余的数据

这种方案可以秒级完成N库到2N库的扩容。

存在的问题:只能完成N库扩2N库的扩容(不需要数据迁移),非通用扩容方案(例如3库扩4库就无法完成)

(4.2)非指数扩容,数据库增加字段,数据迁移

[这些方法在(上)篇中都已经介绍过,此处不再冗余,有兴趣的朋友回复“同城”回看(上)篇]

方案一:追日志方案

方案二:双写方案

(4.3)水平切分怎么切

四类场景覆盖99%拆库业务

a)“单key”场景,用户库如何拆分: user(uid, XXOO)

b)“1对多”场景,帖子库如何拆分: tiezi(tid, uid, XXOO)

c)“多对多”场景,好友库如何拆分: friend(uid, friend_uid, XXOO)

d)“多key”场景,订单库如何拆分:order(oid, buyer_id, seller_id, XXOO)

[这些拆库方案在(上)篇中都已经介绍过,此处不再冗余,有兴趣的朋友回复“同城”回看(上)篇]

(5)海量数据下,SQL怎么玩

不会这么玩

a)各种联合查询

b)子查询

c)触发器

d)用户自定义函数

e)“事务”都用的很少

原因:对数据库性能影响极大

拆库后,IN查询怎么玩[回复“同城”回看(上)篇]

拆库后,非Partition key的查询怎么玩[回复“同城”回看(上)篇]

拆库后,夸库分页怎么玩?[回复“同城”回看(上)篇]

问题的提出与抽象:ORDER BY xxx OFFSET xxx LIMIT xxx

单机方案:ORDER BY time OFFSET 10000 LIMIT 100

分库后的难题:如何确认全局偏移量

分库后传统解决方案:查询改写+内存排序

a)ORDER BY time OFFSET 0 LIMIT 10000+100

b)对20200条记录进行排序

c)返回第10000至10100条记录

优化方案一:增加辅助id,以减少查询量

优化方案二:模糊查询

a)业务上:禁止查询XX页之后的数据

b)业务上:允许模糊返回 => 第100页数据的精确性真这么重要么?

最后的大招!!!(由于时间问题,只在DTCC2015上分享了哟)

优化方案三:终极方案,业务无损,查询改写与两段查询

需求:ORDER BY x OFFSET 10000 LIMIT 4; 如何在分库下实现(假设分3库)

步骤一、查询改写: ORDER BY x OFFSET 3333 LIMIT 4

[4,7,9,10] <= 1库返回

[3,5,6,7] <= 2库返回

[6,8,9,11] <= 3库返回

步骤二、找到步骤一返回的min和max,即3和11

步骤三、通过min和max二次查询:ORDER BY x WHERE x BETWEEN 3 AND 11

[3,4,7,9,10] <= 1库返回,4在1库offset是3333,于是3在1库的offset是3332

[3,5,6,7,11] <= 2库返回,3在2库offset是3333

[3,5,6,8,9,11] <= 3库返回,6在3库offset是3333,于是3在3库的offset是3331

步骤四、找出全局OFFSET

3是全局offset3332+3333+3331=9996

当当当当,跳过3,3,3,4,于是全局OFFSET 10000 LIMIT 4是[5,5,6,6]

总结:58同城数据库架构设计思路

(1)可用性,解决思路是冗余(复制)

(1.1)读可用性:多个从库

(1.2)写可用性:双主模式 or 双主当主从用(58的玩法)

(2)读性能,三种方式扩充读性能

(2.1)增加索引:主从上的索引可以不一样

(2.2)增加从库

(2.3)增加缓存:服务+缓存+数据一套(58的玩法)

(3)一致性

(3.1)主从不一致:引入中间层 or 读写都走主库(58的玩法)

(3.2)缓存不一致:双淘汰来解决缓存不一致问题

(4)扩展性

(4.1)数据扩容:提升从库,double主库,秒级扩容

(4.2)字段扩展:追日志法 or 双写法

(4.3)水平切分

(单key)用户库如何拆分:, user(uid XXOO)

(1对多)帖子库如何拆分: tiezi(tid, uid, XXOO)

(多对多)好友库如何拆分: friend(uid, friend_uid, XXOO)

(多key)订单库如何拆分:order(oid, buyer_id, seller_id, XXOO)

(5)SQL玩法

(5.0)不这么玩:联合查询,子查询,触发器,自定义函数,事务

(5.1)IN查询:分发MR or 拼装成不同SQL语句

(5.2)非partition key查询:定位一个库 or 分发MR

(5.3)夸库分页

(5.3.1)修改sql语句,服务内排序

(5.3.2)引入特殊id,减少返回数量

(5.3.3)业务优化,允许模糊查询

(5.3.4)查询改写,二段查询

   
 订阅
  捐助
相关文章

阻碍使用企业架构的原因及克服方法
世界级企业架构的行业挑战
企业架构和SOA架构的角色将融合
什么最适合您的组织?
相关文档

企业架构与ITIL
企业架构框架
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

企业架构设计
软件架构案例分析和最佳实践
嵌入式软件架构设计—高级实践
企业级SOA架构实践
 

专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS

面向应用的架构设计实践
单元测试+重构+设计模式
软件架构师—高级实践
软件架构设计方法、案例与实践
嵌入式软件架构设计—高级实践
SOA体系结构实践

相关咨询服务
应用架构设计与构建

锐安科技 软件架构设计方法
成都 嵌入式软件架构设计
上海汽车 嵌入式软件架构设计
北京 软件架构设计
上海 软件架构设计案例与实践
北京 架构设计方法案例与实践
深圳 架构设计方法案例与实践
嵌入式软件架构设计—高级实践
更多...   
 
 
 实录  架构级性能评测
主讲:高楼
性能优化专家
 
 实录  企业架构建模
 主讲:俎涛
 火龙果软件创始人
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号