微博数据库那些事儿：3个变迁阶段背后的设计思想.pdf

辉柏嘉910

259

7页

0次

2021-02-17

70墨值下载

2016/3/8

微博数据库那些事儿：3个变迁阶段背后的设计思想

http://weibo.com/ttarticle/p/show?id=2309403948901471268848 1/8

高可用架构 2016030311:15:40 阅读数：3209

微博数据库那些事儿：3个变迁阶段背后的设计思想

到了第三阶段，微博积累下来的数据库设计习惯，通常会采用一些“反模式”设计思路。

编者按：高可用架构分享及传播在架构领域具有典型意义的文章，本文由肖鹏在高可用架构群分

享。转载请注明来自高可用架构公众号「

ArchNotes

」。

肖鹏，微博研发中心技术经理，主要负责微博数据（MySQL/Reids/HBase/Memcached）

相关的业务保障、性能优化、架构设计，以及周边的自动化系统建设。经历了微博数据库

各个阶段的架构改造，包括服务保障及SLA体系建设、微博多机房部署、微博平台化改造

等项目，10年互联网数据库架构和管理经验，专注于数据库的高性能和高可用技术保障方

向。

数据库专家的成长感触

“与MySQL结缘主要也是源于兴趣。第一份工作是在一家小公司，由于人手有限，各个领域的工作

都要接触，相比之下我发现还是对数据库最感兴趣，所以就一直从事和数据库相关的技术工作了。

而随着工作年限的增加，在数据库方面积累的经验也逐渐增多，越来越觉得数据库管理员（DBA）

是一个偏实践的工种，很多理论上的东西在现实中会有各种的变化，比如“反范式”设计等。因此，如

果想成为数据库方面的专家，建议大家一定要挑选好环境，大平台很多时候会由于量变引发质变产

生很多有挑战的问题，而解决这些问题是成为技术专家的必经之路。”——肖鹏

微博数据库经历的变迁

首先为大家分享微博数据库经历的几个重要的阶段。

初创阶段

2016/3/8

微博数据库那些事儿：3个变迁阶段背后的设计思想

http://weibo.com/ttarticle/p/show?id=2309403948901471268848 2/8

初期微博作为一个内部创新产品，功能比较简洁，数据库架构采用的是标准1M/2S/1MB结构，按

照读写分离设计，主库承担写入，而从库承担访问。如果访问压力过大，可以通过扩容从库的数量

获得scaleout的能力。

个人认为，在初期，这种架构其实就可以满足业务的增长了，没有必要进行过度设计，开始就搞得

过于复杂可能会导致丧失敏捷的可能。

爆发阶段

随着微博上线之后用户活跃度的增高，数据库的压力也与日俱增，我们首先通过采购高性能的硬件

设备来对单机性能进行scaleup，以达到支撑业务高速发展的需求。然后，通过使用高性能设备争

取来的时间对微博进行整体上的业务垂直拆分，将用户、关系、博文、转发、评论等功能模块分别

独立存储，并在垂直拆分的基础上，对于一些预期会产生海量数据的业务模块再次进行了二次拆

分。

对于使用硬件这里多说几句，由于微博最开始的时候就出现了一个很高的用户增长峰值，在这个阶

段我们在技术上的积累不是很丰富，而且最主要的是没有时间进行架构改造，所以通过购买PCIE

Flash设备来支持的很多核心业务，我现在还清楚记得最开始的feed系统是重度依赖MySQL的，

在2012年的春晚当天MySQL写入QPS曾经飙到过35000，至今记忆犹新。

虽然看上去高性能硬件的价格会比普通硬件高很多，但是争取来的时间是最宝贵的，很有可能在产

品生命的初期由于一些性能上的问题引发产品故障，直接导致用户流失，更加得不偿失。所以，个

人认为在前期的爆发阶段，暴力投入资金解决问题其实反而是最划算的。

继续说数据库拆分，以博文为例。博文是微博用户主要产生的内容，可预见会随着时间维度不断增

大，最终会变得非常巨大，如何在满足业务性能需求的情况下，尽可能地使用较少的成本存储，这

是我们面临的一个比较有挑战性的问题。

首先，我们将索引同内容进行了拆分，因为索引所需存储空间较少，而内容存储所需空间较大，

且这两者的使用需求也不尽相同，访问频次也会不同，需要区别对待。

然后，分别对索引和内容采用先hash，再按照时间维度拆分的方式进行水平拆分，尽量保障每张

表的容量在可控范围之内，以保证查询的性能指标。

最后，业务先通过索引获得实际所需内容的id，再通过内容库获得实际的内容，并通过部署

memcached来加速整个过程，虽然看上去步骤变多，但实际效果完全可以满足业务需求。

上图乍一看和上一张图一样，但这其实只是一个博文功能模块的数据库架构图，我们可以看到索引

和内容各自分了很多的端口，每个端口中又分了很多的DB，每个DB下的表先hash后按照时间维

度进行了拆分，这样就可以让我们在后期遇到容量瓶颈或者性能瓶颈的时候，可以选择做归档或者

调整部署结构，无论选择那种都非常的方便。另外，在做归档之后，还可以选择使用不同的硬件来

承担不同业务，提高硬件的利用率、降低成本。

在这个阶段，我们对很多的微博功能进行了拆分改造，比如用户、关系、博文、转发、评论、赞

等，基本上将核心的功能都进行了数据拆分，以保障在遇到瓶颈的时候可以按照预案进行改造和调

整。

沉淀阶段

在上一个阶段，微博的数据库经历了很多的拆分改造，这也就直接造成了规模成倍增长的状况，而

业务经历了高速增长之后，也开始趋于稳定。在这个阶段，我们开始着重进行自动化的建设，将之

前在快速扩张期间积攒下来的经验用自动化工具加以实现，对外形成标准化和流程化的平台服务。

我们相继建设改造了备份系统、监控系统、AutoDDL系统、MHA系统、巡检系统、慢查系统、

maya中间件系统。并且为了提高业务使用效率、降低沟通成倍，相对于内部管理系统，重新开发

了iDB系统供数据库平台的用户使用。通过iDB系统，用户可以很便捷地了解自己业务数据库的运

行状态，并可以直接提交对数据库的DDL修改需求，DBA仅需点击审核通过，即可交由Robot在

2016/3/8

微博数据库那些事儿：3个变迁阶段背后的设计思想

http://weibo.com/ttarticle/p/show?id=2309403948901471268848 2/8

初期微博作为一个内部创新产品，功能比较简洁，数据库架构采用的是标准1M/2S/1MB结构，按

照读写分离设计，主库承担写入，而从库承担访问。如果访问压力过大，可以通过扩容从库的数量

获得scaleout的能力。

个人认为，在初期，这种架构其实就可以满足业务的增长了，没有必要进行过度设计，开始就搞得

过于复杂可能会导致丧失敏捷的可能。

爆发阶段

随着微博上线之后用户活跃度的增高，数据库的压力也与日俱增，我们首先通过采购高性能的硬件

设备来对单机性能进行scaleup，以达到支撑业务高速发展的需求。然后，通过使用高性能设备争

取来的时间对微博进行整体上的业务垂直拆分，将用户、关系、博文、转发、评论等功能模块分别

独立存储，并在垂直拆分的基础上，对于一些预期会产生海量数据的业务模块再次进行了二次拆

分。

对于使用硬件这里多说几句，由于微博最开始的时候就出现了一个很高的用户增长峰值，在这个阶

段我们在技术上的积累不是很丰富，而且最主要的是没有时间进行架构改造，所以通过购买PCIE

Flash设备来支持的很多核心业务，我现在还清楚记得最开始的feed系统是重度依赖MySQL的，

在2012年的春晚当天MySQL写入QPS曾经飙到过35000，至今记忆犹新。

虽然看上去高性能硬件的价格会比普通硬件高很多，但是争取来的时间是最宝贵的，很有可能在产

品生命的初期由于一些性能上的问题引发产品故障，直接导致用户流失，更加得不偿失。所以，个

人认为在前期的爆发阶段，暴力投入资金解决问题其实反而是最划算的。

继续说数据库拆分，以博文为例。博文是微博用户主要产生的内容，可预见会随着时间维度不断增

大，最终会变得非常巨大，如何在满足业务性能需求的情况下，尽可能地使用较少的成本存储，这

是我们面临的一个比较有挑战性的问题。

首先，我们将索引同内容进行了拆分，因为索引所需存储空间较少，而内容存储所需空间较大，

且这两者的使用需求也不尽相同，访问频次也会不同，需要区别对待。

然后，分别对索引和内容采用先hash，再按照时间维度拆分的方式进行水平拆分，尽量保障每张

表的容量在可控范围之内，以保证查询的性能指标。

最后，业务先通过索引获得实际所需内容的id，再通过内容库获得实际的内容，并通过部署

memcached来加速整个过程，虽然看上去步骤变多，但实际效果完全可以满足业务需求。

上图乍一看和上一张图一样，但这其实只是一个博文功能模块的数据库架构图，我们可以看到索引

和内容各自分了很多的端口，每个端口中又分了很多的DB，每个DB下的表先hash后按照时间维

度进行了拆分，这样就可以让我们在后期遇到容量瓶颈或者性能瓶颈的时候，可以选择做归档或者

调整部署结构，无论选择那种都非常的方便。另外，在做归档之后，还可以选择使用不同的硬件来

承担不同业务，提高硬件的利用率、降低成本。

在这个阶段，我们对很多的微博功能进行了拆分改造，比如用户、关系、博文、转发、评论、赞

等，基本上将核心的功能都进行了数据拆分，以保障在遇到瓶颈的时候可以按照预案进行改造和调

整。

沉淀阶段

在上一个阶段，微博的数据库经历了很多的拆分改造，这也就直接造成了规模成倍增长的状况，而

业务经历了高速增长之后，也开始趋于稳定。在这个阶段，我们开始着重进行自动化的建设，将之

前在快速扩张期间积攒下来的经验用自动化工具加以实现，对外形成标准化和流程化的平台服务。

我们相继建设改造了备份系统、监控系统、AutoDDL系统、MHA系统、巡检系统、慢查系统、

maya中间件系统。并且为了提高业务使用效率、降低沟通成倍，相对于内部管理系统，重新开发

了iDB系统供数据库平台的用户使用。通过iDB系统，用户可以很便捷地了解自己业务数据库的运

行状态，并可以直接提交对数据库的DDL修改需求，DBA仅需点击审核通过，即可交由Robot在

of 7

70墨值下载

database

关注