【IT168 评论】2009年，新浪微博出现，更普世的产品形态，更低门槛的UGC，在当时取得了巨大的成功。虽然作为一个常态化的产品，现在的微博已经褪去了当初被业界热捧的光环，但微博并没有失去其作为媒体平台的价值。从2015年的数据来看，微博的“热搜”功能使用频次达到2亿/日。
量变引发质变!如此体量的微博对后端数据库的支撑提出了巨大的挑战，对新浪DBA而言，每天都会遇到大量的问题，他们是如何分工?如何解决故障?故障处理流程有什么不同?又是如何降低故障的处理时长提高服务的可用性?
在2016年的Oracle技术嘉年华上，新浪微博研发中心数据库技术负责人肖鹏在演讲完后接受了老鱼的采访。
嘉宾介绍
肖鹏，微博研发中心数据库技术负责人，主要负责微博数据库相关的业务保障，性能优化，架构设计以及周边的自动化系统建设。专注于数据库的高性能和高可用技术保障方向，对于涉及数据方面的架构设计、优化以及大规模集群运维颇有心得。
老鱼：您今天的演讲主题是《MySQL性能优化经验谈》，性能优化是个经典的话题，这次的演讲又有哪些新的东西分享给大家?能否对您今天的主题做个简单的总结?
肖鹏：我个人比较关注性能优化，性能优化是一个贯穿数据库始终的话题，在每年每届的大会上都会有人提。但据我观察，不少关于性能优化的分享都是基于某个点或者某一类场景的分享，相对来说比较散，对于一些经验不丰富的新人DBA来说，没有一个成体系的优化思路。
这样的感受来自日常的DBA招聘，面试的很多新人觉得数据库优化很高深神秘，不知道从那个层次入手，似乎只有高级DBA或者资深人士才能谈优化。其实并非如此，如果能掌握系统的优化思路，一步一步去做，即使是新手也能做到比较好的效果。
此次，我给大家分享的内容其目的就为了是让大家能够有层次的去做数据库优化工作。分享的内容来自，这些年我在微博运维工作中提炼总结的一套数据库分层理论及优化体系，从最底层的硬件层，OS层，到中间层MySQL自身的调优，还有业务应用层，整体架构层面的一些设计思路，告诉大家我们是怎么做的，供大家参考。
老鱼：能否用数字简单介绍下目前微博的体量?很多人可能并不太了解，MySQL在微博上承载着一个怎样级别的业务。
肖鹏：微博初期也就是2009年，服务器只有几十台，很小的一个规模，但是后来随着用户暴增，服务器增加的很快，现在已经有小2000台了，1万的实例，单份数据量大概在300 TB左右，日访问量达到几百亿规模。
微博数据库主要使用MySQL和Redis，辅助一定的HBase，我们服务的是微博所有业务线，好几百个产品。
老鱼：支撑如此巨大的体量，相信对后端数据库提出了巨大的挑战，对您而言，每天一定会遇到不少的问题，故障处理是怎样的一个流程?如何降低故障的处理时长提高服务的可用性?
肖鹏：大家都知道量变会引发质变，这样的规模导致我们每天会遇到大量的问题，基本上每天一定会有些产品会出现问题，天天都在处理问题，所以这方面有比较多的经验积累，这也是促成我今天分享这个主题的原因所在。
我们的故障处理流程：
第一：第一时间恢复服务。
第二、一定要留一个现场，否则这个事情就会虎头蛇尾。我们一定会在保留现场的情况下，去做故障深层次的追查，之后会在部门内部Review。
第三、自动化运维的开发，我们会尽可能的把每次人为故障处理过程封装成一种自动化的方式，尽量用程序替我们把这个事情做了。
故障想完全杜绝是不太可能的，我们曾经讨论过，我们能不能防止所有的问题和隐患发生? 我们怎么可能防止一个我们都不知道的故障发生，根本不可能。我们能做到的事情是努力降低故障的处理时长，故障处理时长越低，服务的可用性就越高。
随着日积月累，我们自动化的系统会越来越健壮，能处理的问题越来越多，我们的服务也就越来越可靠。
老鱼：对很多DBA而言，在尽可能短的时间内处理完故障是一项不小的挑战，微博故障响应及处理时长有没有要求?又是怎么做的?如何快速定位问题?
肖鹏：我们的故障响应时间是实时的，公司规定故障不论大小，30分钟之内处理完。
对DBA来说，这有点强人所难，不可能什么问题都能30分钟内解决。但如果发动相关兄弟部门，这个事也是可以搞定的。并不是所有的问题都需要DBA来解决，我们会在整体架构层面做一些降级，容错容灾处理，让业务对最终端用户来说是柔性可用的，争取一些时间来做数据库上的恢复。
至于如何定位问题?首先，我们有自己的一套流程，先查什么后查什么，一目了然。
其次、就得靠个人经验了。如果你对业务架构，业务形态有足够的了解，是能猜到大概是那个地方出问题了，然后去验证它。
另外，微博本身的监控做的比较周全，可以把问题定位到一个小的范围内。当然我们也曾经走过很弯的路，但这也是一种经验。
老鱼：微博目前有多少个DBA?怎么分工?
肖鹏：有10多个DBA，按业务分工。我们内部戏称全栈DBA，什么数据库都要搞一搞。
曾经我们是按软件分工，比如MySQL,NoSQL。这样会导致一个问题，跟业务部门开会时要去好几个DBA，一对一的沟通成本、误传率显然要比一对多低很多，所以我们就按业务去分。
对DBA来说，这样划分其实是件好事，因为以前负责MySQL的DBA不看NOSQL对个人的职业发展和成长也不是一件很好的事情。
老鱼：您全程经历了微博的发展，这些年来，以数据库为例，面临过那些挑战，踩过了那些坑让您印象深刻?
肖鹏：埰的坑比较多，遇到的问题也很多，印象最深刻的还是数据库的吞吐能力问题。
微博服务访问和并发压力是非常大的。大家都知道，微博的突发热点那是真的随时随地突发，凌晨2-3点，休息日都可能发生，完全无法预知，不像淘宝的双十一等电商大促，可以提前准备。因此，突发热点对数据库产生了巨大的波动性，波动性带来的显著的问题就是成本矛盾，要扛住曾经发生的峰值，我们的成本付出去了，但日常用到的可能只有十分之一，这就造成了资源的浪费，对一个上市公司来说，这是不允许的，所以很麻烦。
我们的解决方案并不是数据库层面的解决方案，而是整体技术架构层的解决方案，这也是我在微博这么多年最大的收获。
作为DBA，不要光盯着数据库，还要多跟业务部门去沟通，看他们在业务上真正的需求是什么，要干什么，解决他什么问题，能不能用别的数据库解决，甚至能不能用非数据库的技术或者其它层面的东西来解决，把这个需求真正的满足。否则就会陷入相互扯皮的死循环，你说数据库没扛住，我说你超量了，最终的结果是公司受损。
老鱼：对于数据库选型，尤其是开源数据库与商业数据库选择，您有什么好的建议?
肖鹏：圈内有句话“开源软件人人使，但使的好使得差是天壤之别”，淘宝也使MySQL，很多公司也使用MySQL，淘宝双十一号称12万笔/秒，但是别家谁能跑12万?不太可能。
开源虽说是免费的，但是附加的投入很多，选开源还是商业的数据库，还是要根据自己的业务需求。比如公司处于什么阶段，公司拥有什么样的人，对数据库的需求是什么样的?
如果你就是个初创公司，如果你仅有的几个人都是OracleDBA,虽然Oracle非常贵，但你硬逼着他们去转MySQL，不仅有人员流失的可能，也有学不好的可能，这些都是成本，这些成本没准比你买个Oracle的成本更高。
商业数据库优势在于有比较强的服务团队，即我们所说的原厂服务，如果你没有一个在开源软件上钻研很深的技术团队，用开源软件，一旦你的技术团队搞不定，对于创业公司而言，结局可能就是消亡。但如果用商业的，其服务团队可能在你遇到生死存亡的那一刹那给你捞回来。
因此，数据库选型在什么阶段，得看具体需求。不要只考虑钱，很多人只看到软件的成本，没看到人力成本和时间成本。
