【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】（微信搜索DTCC2014,关注中国数据库技术大会公众号）现场演讲嘉宾冯超老师分享内容整理而成。录音整理及文字编辑IT168@ZYY@老鱼。

　　讲师简介：

▲冯超

　　DBA冯超，前美丽说数据库及中间件负责人，技术经理，6年数据库架构经验，1年创业经验，30年瞎掰经验。2008年加入人人，2014年从人人离职加入美丽说，经历了美丽说从导购转型电商的过程，2016年加入美图，成为美图数据库团队负责人。

　　正文：

　　大家好，我今天的演讲主题是“美丽说数据库架构变迁及自主研发中间件应用”。自2014年从人人网离职加入美丽说之后，经历了美丽说从导购网站向电商网站的转型。虽然过程坎坷，但结果还是比较不错的。美丽说的GMV从最开始不到百万到增长到最高峰的时候一天10亿左右的交易额。今天主要给大家介绍一下美丽说转型过程中数据库架构变迁的经验和心得。

　　我把美丽说的转型分为三个阶段;

　　1、 导购时代。

　　2、 转型时代，这个阶段是电商从无到有的建立过程，从小型交易到快速成长的过程，基本上从0到GMV百万级别，峰值订单10/s;

　　3、 爆发时代，根据前面积累的经验，公司进行了大规模的宣传和推广，这个阶段对我们的架构迎来了一些挑战， GMV从千万级增长到billion规模，峰值订单3k/s。

　　导购时代：

　　导购时代我总结的经验有两个关键字：“混合”、“无规范”。混合是指数据库业务、功能、用途都混合在一起。如商业库，只有一主三从结构，商家在用、用户在用、统计在用，我们DBA也在用。

　　另一个是无规范，当时没有专职的DBA，所以配置、版本、权限等都没有规范起来，造成两个问题：

　　1、 稳定性差，因为所有的业务和功能混合在一起，其中一项业务出问题就会影响到其他所有业务，当时的情况是，今天A业务出问题，明天B业务有问题，最后整个网站都会因为不同业务的问题导致整体稳定性非常差。

　　2、 扩展性差，耦合性强，扩展性就差。牵扯的业务众多，所以任何扩展都是意见非常耗时耗精力的事情。

　　当时问题比较多，也有一件正确的事情，也对未来的优化提供了一个基础，就是引入配置文件，在业务层做读写分离。所有在业务层读取的数据库，有了配置文件就相当于有了配置中心，我们所有的改变都是基于此实现的，这就是导购时代。

　　转型时代：

　　转型时代的关键就是“Change”，所有的东西都在变化。由于我本人的电商经验相对匮乏，所以我当时考虑的是如何应对电商的变化以及如何让它从正确的方向有序优化演进而不是以一种杂乱无章的方式变化到最后失控。

　　我首先想到的是建立规则，包括两方面：内部规则和外部规则。内部规则如主机名、版本、参数的规范，方便日后进行批量操作，其次也为监控推广提供基础。这样做还有个根本目的，第一减少DBA的人为操作失误，在没有规范，业务发展迅速的情况下，人为操作可能会发生很多问题;第二是规范定好，可为以后脚本化、自动化打下很好的基础。

　　外部规范，主要是sql规范，引导研发更好地利用Mysql的性能，写出符合更高效率的sql语句;其次是业务规范，说到底就是把业务解耦，让不同的业务访问自己的数据库，不同业务之间通过接口调用数据，在这个过程中特别强调的一件事是，把用户和权限规范起来。当时是为了开发方便，都走的root用户，具有所有权限，换句话说，每个用户都可以做任何想做的事，风险非常大。其次时不时就会有人把其它业务数据删掉或更新错误，需要不停地修补数据，浪费大量人力，所以在访问规范之后，制定了账户权限，读有读账户、写有写账户、DBA有自己的账户、访问有访问账户、脚本有脚本账户等，有迹可循，每个人都没有权限做额外的事情。

　　促销秒杀场景：

　　规则建好之后就需要解决实际问题，在导购时代是没有促销和秒杀的，美丽说成功转型电商以后，促销和秒杀的场景就非常多了。美丽说的第一次促销是5月20日12点，结果在那个时间点，美丽说所有的服务网站集体全部down掉，凌晨2点跑到公司去解决追查问题，但是有两个问题需要解决：第一是容量问题，对于数据库来说就是写瓶颈和读瓶颈。第二是短链接问题，当时用的是PHP语言，在高并发的情况下频繁建立和销毁链接，对PHP来说建立和回收都需要一定时间，高并发的情况下造成了很多超时问题，如果前端业务没有对超时问题进行从严和机制化处理就会造成服务在瞬间全部不可用。针对这两个问题，我们当时提出了两个容量问题解决方案：

　　一、 纵向扩展(成本换时间)。纵向扩展是可以比较快速实施起来的。纵向扩展主要有三个方法：一是升级磁盘，从普通的SAS盘升级到SSD;二是增加内存;三是升级CPU，由于线上的某些sql写的不是非常规范，所以很多运算都在数据库里发生，这就对CPU有了更高的要求，所以我们必须要升级CPU换取sql的优化时间。二是增加从库，解决读瓶颈。由于用户混合在一起，导致我们之前增加的从库效果并不明显。12点又是统计需求大量跑的时间点，增加的从库被统计需求大量消耗，最后用户的读容量并没有增加多少。之后我们开始对从库的用途进行拆分(配置文件)。三是增加缓存，例如redis、memecache等。

　　二、 横向扩展，就是数据拆分。把数据逐步打散分布到机器和实例中提高它的容量。关于数据拆分，我总结了一个方法，优先业务拆分再功能拆分，完成后再对具体的表进行垂直、水平拆分。

　　以上是纵向扩展实例，因为每个程序在读取数据库时都要去配置中心读取配置文件，我们就把配置文件进行拆分。比如专门给用户用的库就专属去读用户库的配置文件，举个例子比如A、B两个库专门给用户使用，然后后台脚本配了C、D，这样就可以将数据库和后台脚本拆分开。大促时就不需要动其他库，只需要在配置文件中增加用户库就可以把配置容量扩大，这就是纵向扩展做的事情。

　　再说横向扩展，我们对当需求集中到一个库以什么维度拆分进行了很多讨论，最后的结果是按照业务拆分。美丽说当时的情况是商业部门有交易小组、广告小组、专门对接商家的支付小组，我们先按照业务把一个商业库拆分为4个库，每个库基本上都是独立服务，服务之间通过接口访问。此时的GMV每天可以增加到100-200万的量级，但这对我们的目标是远远不够的，我们按照功能进行了二期拆分。

　　横向扩展以交易为例，通常电商网站促销之前都会进行抢劵活动，其实也相当于秒杀，但秒杀的不是商品而是优惠券。在拆分过程中一定要优先核心功能，首先要解决优惠券秒杀问题，要把优惠卷拆分出来。用户拿到优惠券以后就去看商品，当时我们的商品页面叫单宝页，又把单宝页拆分出来，用户查看商品后要添加到购物车，然后又把购物车拆分出来，看到购物车以后要提交订单，又把订单拆分出来，最后是商家和用户的反馈，由于并非是核心功能，就最后拆分。 其实拆分的过程没有这么简单，我觉得电商网站非常好的一点在于所有的指标都可以量化，我们拆分数据的依据是什么?就是我们对这次促销所定的目标，我们主要以GMV来定，这次促销的GMV是10亿，那用户订单数的金额大概就是在某个范围内，那我们的支付要承载多少压力、交易要承载多少压力、商家要承载多少，基本上做接口和压测都可以算出来。我们拆分的过程也是以这个数据为基础，比如最终以此评估拆分收益。

　　另一方面我们要解决短链接问题，我觉得其实有两方面问题，第一是频繁建立业务会超时。另外我对短连接没有一定的限制，也就是说数据库最大的链接数可能是13684，但秒杀的时候可能会有20万人在抢这个商品，可能就会有20万个短链接连到数据库，一瞬间就可以把数据库搞崩溃。如何解决这两个问题呢?

　　当时我们公司的情况是，正好有一个团队在解决某一个功能时做了一个有连接池功能的数据库代理，我们就把它拿来直接用，引入了连接池的概念。连接池就是数据库初始需求是解决短链接超时崩溃的功能，但核心价值反而不在这上面，我回过头来再想其核心价值大致有如下两点：

　　1、 proxy作为程序连接数据库的统一入口，可建立适当规范，源源不断的业务接入过程中，proxy可以保障是符合规范的，那可认为这些业务是可控的，方便未来的扩容和调整优化。

　　2、 和程序端解耦，业务爆发时，要求DBA短时间内进行大量的扩容工作，例如：垂直拆分，水平拆分，机器上下线。

　　开发过程中我们也实现了如下几大功能：

　　1、 连接池，用户程序请求连接时不需要新建，只要有空闲的链接，就可以进行复用;

　　2、 带权重的负载均衡，可根据机器性能设定相应权重。现在的硬件在不断发展，下一批机器到以后在硬件性能上肯定会提升很多，有了权重以后就可以根据机器性能设定相应权重，使其承担更多压力;

　　3、 大表透明水平切分，散表规则统一。比如按照用户ID分的表按照其他维度是不太好查的，后期我们做了并发操作，一个sql来的时候，我们可以拆分出10个线程到每一个库、每一个表里查询，最后将查询结果合并发给用户，如果一旦放开这个权限就有一个问题，可能同一时间有很多的需求链接不受控制，因为每个请求都会被分成100份。所以当时做的不是很完善，只支持以散表字段进行查询。

　　4、 透明的负载均衡，及故障切换，从库故障自动剔除。

　　5、 黑名单也分为两部分，一是sql黑名单，二是IP黑名单。sql黑名单无论是人为的有问题的sql还是程序bug或者安全漏洞造成的，只要我们一发现就会在代理上完全禁止掉，这样就能够保证数据安全。IP黑名单可禁止某些异常机器连接，保护数据库。

　　6、 防止数据库密码泄露，程序端仅可获得连接代理的密码。我们在基础文件前需要构造链接，就需要用户名密码这两个字段，有了代理以后用户可以拿到代理密码，我们在代理层进行加密处理，把密码隐去以防止密码泄漏，当然程序端也没法做非法操作，这些就可以在一定程度上保护数据库。

　　7、 主动断开功能，建立规则规范，对于不符合规范的sql可进行审核，一旦发现就可以自动断开，如获取结果集超过5M，在电商大促时，这类sql是致命的。

　　8、 连接数限制，连接数暴涨时，代理连接数限制，保护数据库不会被瞬间击垮。

　　9、 支持强制读主库。不支持跨库查询和分表后的复杂sql，如limit，count等。

　　转型时代最终架构：

　　爆发时代：

　　爆发时代突出一个“快”字，快速部署、快速扩容等。摆在我们面前的一个现实问题是--单机房限制。首先是容量限制，由于机架、机柜有限，无法满足我们的需求，也就是说我们受限于资源无法进行大规模扩展;其次是临时工的问题，经常会把电缆挖掉。印象深刻的一次是8月底的一次促销，8点开始，7：40整个电源全部断掉了，我们对此毫不知情。由于没有其他备用机房导致我们束手无策。最后是用户量增大以后，各地的访问速度明显不如以前。全国各地的网络速度都需要考虑用户体验，基于此，我们进行了多机房尝试，对DBA来说能想到的第一个多机房架构就是一主一从，采用级联方式减少带宽的压力。

　　刚开始没有服务端，只有数据库做异地备份切换，慢慢发现基于成本来说有些浪费，另外考虑到机房容量限制，我们设置了备用机房以便出现故障时可以快速切换。其二是可以不受主机房机柜的限制扩充备用机房，把服务部署在备用机房，通过跨机房写入到主机房。这个结构其实比较简单，同时方便运维维护，切换也比较方便。切换过程中如果出现数据丢失，必须根据日志等各方面配合来进行恢复。但这样的问题对网络依赖非常高，一旦网络出现抖动，数据将完全延迟，对于延迟非常敏感的应用来说，这就是一个灾难性的问题。起初，我们的主机房设在北京，备用机房设在广州，由于广州机房容量限制，我们又设置了另一个机房，做了一个两地三中心的架构。

　　在这个架构下我们做了很多故障切换演练，就是在两个机房之间拉一个专线，但这个专线的建设速度是有一定周期的，在没有建成之前，我们也进行了很多故障演练的切换，这就是说故障的切换需要多部门配合。一旦出故障，我们首先要保证服务第一时间恢复，其次数据才会缓慢的恢复过来。然后经过演练最后全部实现脚本化、自动化切换，最后的演练过程基本上保证在一分钟之内完成切换。

　　但这只是过渡期完成切换的一个架构，它的缺陷在于跨机房写，一旦网络出现问题，这些写就全部不能进行了。我们参考了阿里单量化的思路设计了一个demo,首先在业务层把用户维度进行拆分，也就是新进来的用户，比如这边的用户ID是13579，另一边进来的可能是02468，进行拆分只需要依赖本地机房读写，因为用户之间没有关联，每一个进入机房的用户，在本机房里就可以完成从浏览到下单的所有过程。解析出来放入队列延迟同步到另一个机房，这样即便网络断了也不会影响最终的数据同步，解决了多机房对网络的依赖问题。

　　这个架构不影响我们对具体业务的需求，做完上述所有改进之后，我们的规模基本上可以达到亿级别。但在爆发阶段还有一个头疼的问题，很多事情需要在极短的时间内完成，有时候我们不得不考虑自动化的方式。我们有一个由DBA维护的配置文件，存放了完整的源数据。基于这个配置文件可以实现备份系统，有了备份系统就可以自助扩容，第一个用自助扩容的是测试部门，因为每天要进行很多测试工作比如压测，每天不停的把数据删了建，建了删。DBA并不想每天都支持这样的业务，所以可以采用自助扩容，想要什么数据，我们把权限配置好，去页面上点一下扩容就可以自己压测了。大促前期，DBA只需要在页面填几个参数就可以扩容。

　　其次是工单系统。对DBA来说，每天处理工单也是非常麻烦的事情，之前每来一个需求，我们就需要手动连到客户端的具体DB再进行操作，有了配置文件以后，只要审核通过，在页面上一点就可以自动到数据库里执行，节省了很多时间。

　　再其次是可视化信息展示，DBA为了保护数据库做了很多壁垒，但其实是把正常需求拦截在外了，数据库分析都找不到只能猜，这样对数据库来说会有很多隐患。我们做了如下几件事情：

　　1、 慢查询，就是说不需要DBA查，我们收集好信息展示给用户，用户自行了解。

　　2、 巡检，针对用户关心的商品，我们每天都可以进行巡检，巡检完了以后，通过页面展示给用户，你可以看到自己业务正常运行时的数据库的状态。

　　3、 容量统计，我们会统计每个数据库增删查改的量。

　　4、 结构拓扑，就是把配置文件中的拓扑结构还原，还原后让DBA和研发人员知道每一步具体是做什么的。

　　我觉得做了这么多工作以后，业务量已经基本稳定，最高的时候一天可以达到7-8亿左右的交易额，但是对数据库的压力还不是很大，就是说如果再提升两到三倍也没有太大问题。虽然最后美丽说被蘑菇街收购，但过程还是有很多值得分享的东西。

　　今天的演讲到此结束，谢谢大家!