作者：刘剑利，乐信运维副总监。
前言，今天的分享主要分四点：一个是什么是消费金融，这里简单介绍一下。第二介绍一下我们这边是怎么样的架构实践。第三介绍我们数据库的DvOps实践，最后是未来展望。
1、什么是消费金融？消费金融其实很简单，举一个简单的例子，就是分期购物，可能这边土豪比较多，没有做过分期购物。我可以简单介绍，比如一个苹果X，PPT上面的流程是简化过后的，大体是下单，分控、资金匹配、生成帐单、还款，当然这是简单的场景。
消费金融也可以从字面去理解，就是一个消费，就是有一些电商属性在里面，金融就是涉及到资金，字面意思也比较直观。
那么这种业务场景下，对我们数据库的要求是什么，因为我们主要是线上，所以要求高并发，涉及金融，数据要求高安全、强一致，第一点大体就过了。
2、数据库的架构实践然后我们重点看一下数据库的架构实践，架构实践说实在话，包括前面两位老师说的，是在不断的背锅中积累成长起来的。
我们公司数据库历史可以大体介绍一下，就是数据库的实践时间是两年多，不算长，也不短。
套用最近比较火的一句话“开局一把刀，装备全靠捡”，一开始都是给你两台数据库，但是业务是不断快速发展，我们怎样做到在背锅踩坑的时候不断完善我们的架构。
我个人观点是架构上没有一套适用所有业务的架构，可能每个人根据自己的业务形态、业务场景、发展阶段，架构都会不一样。也就是没有最好的架构，只有最适合的架构。
我们的架构是从问题出发不断演化而来。比如我们遇到了短链接压力、数据不一致、单表过大、配置管理混乱、各实例相互影响、缓存使用等问题。
下面将针对每个问题来介绍我们的解决方案。
我们第一个遇到的问题就是短链接压力，刚开始使用得好好的，问题来自哪里呢，就是我们搞大促，也就是并发来的，最后被搞死了。
短链接不知道大家有没有遇到过，会导致CPU直接被耗光，可能很多请求还没有进入到Mysql里面，机器就死了。数据库挂了我们的压力也很大，而且第二天同时间段还有活动，只有一天时间解决问题，所以要快速解决问题。
我们用的是官方社区版的，对链接池的管理不是很好，有开源的链接池管理的不错的版本，如MariaDB和PconaSrvr，但是换版本我们在时间上来不及，一天时间换一个不同分支的版本，可能可以临时解决这个问题，但是担心会引入更多的问题，所以当时就把这个方案否掉了。
最后我们用了一个方案，就是加了一个Proxy，它是的atlas，非常轻量，不需要动原来的MySQL。atlas还有读写分离、sharding的功能，不过这里我不介绍，因为我们只用了它的短链接转长链接的功能。
这是数据库的安全和一致性，其实这里跟大家也差不多，一个就是主库故障能做到自动切换，备库故障也能剔除，然后采取半同步复制的方式保证数据的一致性。
managr主要做判切和切换的逻辑，本地agnt主要是切换前binlog的补偿传输。我们所有的实际切换动作最终都在Proxy去做的，主机挂了，只要判断故障之后，managr向proxy发送指令，proxy把请求改到选举出来的新主机上去。
然后这也是大家使用MySQL会遇到的问题，单表瓶颈问题，各家解决单表瓶颈的问题也不一样。我们这边做了分库分表的方案，看PPT左边我们的分库分表路由配置，可以看到语法跟MyCat差不多，但我们这里是没有做成中间件的方式，只是做成一个Sharding库，需要用sharding功能的直接本地引用它就行，这样的好处是都是本地调用，非常快。
这里举个例子，Sharding类型我们目前只有三种：百库十表、年库月表和年库天表，当然这个也很容易扩展，只要定义好对应类型的路由规则。
这里介绍一个百库十表，它把一个逻辑表分成一千张表，因为这里的分库分表做得比较简单，可能会有一些使用的规则限制。
配置里面的url确定了该区间内的库表会到哪个实例上去，比如这里的00~49这50个库的0~9这张表，会路由到DB1实例，剩下的张表路由到DB2实例，这里最多可以做到的是张表可以放到个实例里面去，但目前还没有达到那样的数据量，整体的数据迁移和扩容对研发来说不是完全透明，需要开发在代码里面声明一下，目的是让大家知道自己使用了有限制条件的sharding功能。比如不支持分布式事务、sql必须带shardingky，不支持join等操作。
因为做分布式的事务，投入产出比太低了，shardingky和刚才老师说到的多活类似，我们准备在多活的时候也用上。
下一个问题是配置不统一的问题，这里讲一下历史背景，一开始全部研发不是在一起的，各业务自己搞，数据库也不是一个团队在维护。
这里面临什么问题？有些团队直接写在代码里，还有一些是稍微标准一点，用了一些配置文件统一管理，还有一些用的是配置的集中管理。比如写死在代码里面，如果修改配置，需要研发配合发布版本，大家都比较痛苦，用配置文件的形式，对研发是透明了，但是每次变更，需要重启一堆的服务，生效时间比较长。
所以最后我们选择用集中的配置中心管理配置。配置中心实现配置自动监听，我们配置修改之后，应用自动监测到。这样有个好处就是，我不管数据库这边做任何的改动，其实对研发来说是透明的，不至于像之前，DBA这边要做改动的话，研发这边需要熬夜配合该配置、发版本，怨声载道。
对研发来说，其实我的数据库是个大的集群，然后每个应用之间，我给它一个Ky，它只要知道它自己的Ky，后端怎么部署的它不用管。
刚才第一个刘老师分享的时候，我听到一个同学有个问题：在混部的情况下如何解决相互影响。
我这边可以给你提供一下参考，就是我们这边实例也很多，机器不是那么多，所以会混部，这就遇到一个问题，怎么在混部的时候不会相互影响。我们有什么方案可选呢？一个是单机单实例，现在大家维持单机单实例的有多少？举一下手，估计是土豪公司。
这里说个题外话，节省成本对运维来说是创造价值的东西，在确保质量的同事，就可以做到分。资源隔离我们用的是cgroups，这里我们会根据业务的重要性，还有根据一些平时每个实例跑的情况去做隔离，比如单机可能会有24个或者48个实例，看实际情况。
最终选用cgroups是因为它非常轻量，维护成本低，调整资源也可以做到动态调整。但这里在用的过程中会短暂中断业务，就是需要重启数据库才能加入到隔离里面去，它可以做CPU、内存、IO和网络的隔离。
随着业务量的增长，mysql在应对高频的查询请求有些力不从心，这时候一般都会引入Rdis做缓存来把读压力前置。下面我会介绍一下高性能缓存，我们用的Rdis。
Rdis也是一样，最终发展起来总会遇到水平扩展的问题，水平扩展其实常用有两种方案，一个是集群，一个是用中间件做分片。最终我们选用中间件方案，因为这个方案最轻量，而且不会动原生的Rdis。
下面主要看水平扩展实践，先看一下从一个分片扩展到两个分片的方案，这里会先做好一个新的集群，然后用Rdis-port同步工具，这个工具我们当时拿来用发现不可用，所以做了一些改造。
通过Rdis-port把数据同步过来后，新数据也会持续同步到新集群，最后一步就是做切换，把proxy用新的分片规则指向新的集群，影响业务1秒左右。
我们这个方案是可以做到任意扩展，可以伸可以缩，可以从N到M的任意伸缩。从两分片扩展到三分片的步骤和上面完全一样，这里不重复介绍了。
我们现在线上最大的分片就是10个分片，QPS峰值是20万+。
下面讲一个缓存更新的问题，我们在使用业务缓存的时候，多少都会有一些问题，如怎么去保证缓存中的数据跟数据库中的数据是一致的，还有就是更新缓存的及时性，有些缓存更新没有那么及时，导致类似缓存洞穿的问题。
我们这里是分两种场景来做的，一个是读多写少的情况，这种场景我们不会去写Rdis，我们只会写Mysql。那么如何把这部分数据更新到rdis上呢？第一步是写MySQL，第二步是ottr会把更新的binlog拉过来写入MQ，第三步是起一个进程从MQ消费这部分数据更新到Rdis。
这里感觉流程有些长，其实用程序做起来也就是几十毫秒的事情。这个方案可以得到一个保证，就是rdis数据跟Mysql数据一致，而且不需要再做一步对帐。
另一个场景就是读多写多的场景，我们是双写Rdis和MQ，然后再去异步更新Mysql，异步写MySQL因为该场景直接写MySQL可能会给MySQL带来较大的写压力。这个方案也能够保证rdis跟Mysql最终的一致性。
3、数据库的DvOps实践!数据库的架构实践介绍到这里就结束了，下面介绍一下数据库的DvOps实践。DvOps这里我简单从思路上看能否为大家做一个抛砖引玉。我想问一下，我们现在会场内的都是运维还是开发？都有。
先看一下DvOps的主流定义，就是利用一些主流平台来提升研发、运营、质量三个角色的整体效率。
以前的三者的效率主要靠人，那么这里面会掺杂着很多的抱怨和吐槽。另一个定义是我自己说的，不是主流的定义，就是从一开始研发或者质量会吐槽你到最后赞美你、从相杀到相爱。
我们三者的效率最终还是停留在人上，这时候瓶颈就出现在人上，我们最终要做好这个事情，不能一直靠人去堆，所以DBA还是要面临转型，这也是大势所趋，现在出去，你要不会一些开发能力，你都不好意思，而且这个目前也体现在我们这边的招聘上了。
那么这个转型是不是很难呢？我觉得万事都是开头难，因为我最开始做这个转型的时候也是，总感觉无从下手，这里我讲一下过程中的转型之路，然后看对大家有没有一些启发。
第一步就是先找到自己的第一个需求，其实大家现在可能很多痛点，比如跟开发之间的沟通问题，或者内部的效率问题，建议你找目前最痛的点来作为第一个需求，因为这样，会比较有动力和耐心坚持完成这个需求。
我当时找的第一个需求是一个线上DML和DDL的变更，因为我们当时业务发展挺快的，各种数据库变更，我们当时年的时候团队有三个人，一天基本要有一个人完全去支持DML和DDL上面，开发抱怨效率低、团队成员抱怨没时间做更有价值的事，当时也没有专门的开发可以帮我们做，所以只能自己谋出路。
第一个需求确认了之后怎么开始我们的第一个需求，我们借助开源的力量，可以看到不管是前面的数据库架构还是我们的DvOps实践，基本上开源跟自研都是8比2的关系，在开源的基础上去做，可以达到事半功倍的效果。
我们更多的是借助开源，利用一些轮子，不重复造轮子，我们用已有的轮子和零部件自己去组装，打造适合自己的平台。
首先是前端，一开始我们做前端，不管对运维还是DBA都是比较痛的点，最终发现做的页面交互，还有整体的体验都不太好，那还不如用所见即所得的东西，这里推荐蓝鲸的MagicBox，对我们来说是最痛的点上它可以很好的解决。
然后Wb，我们用的是Django，当然还有一些其它的点可以选，比如flask和tornado，这几个都是python的wb框架，大家可以自由发挥。
有同学听说过开源的Incption，除了自带的审核规则，我们有自己的一些规范和要求，于是我们在上面做了一些封装。
最后就是怎么把这个东西部署下去，这个应该是运维的专长了，用Nginx+Uwsgi。所用到的完整技术上面都介绍了，具体细节这里就不展开了。
看一下我们数据库需求最后的界面，这里面是一天的需求，DML和DDL加起来差不多50多个吧，这些需求对我们来说，做了这个功能，就可以减少一个人力出来。第一个需求完成后，我们也尝到了甜头，逐步梳理我们工作中的痛点，并逐步解决它。
我们已经完成了SQL查询功能，方便研发在排查问题时做一些查询；还有库表查询功能、慢查询视图、MySQL私有云、实例详情、日常巡检等功能，具体实现我这里不做过多介绍。
4、展望然后来看一下展望，第一个是去年流行起来的叫NwSQL的东西，这是NwSQL比较官方的定义，它是对各种新的可扩展高性能数据库的简称。这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。
这类数据库有两个比较有名的，一个是GooglSpannr（未开源）、另一个就是TiDB，我们对TiDB做了测试，水平扩展只需要加机器就好，不需要其他任何动作，而且部分节点故障也不影响集群，我想这就是下一代的数据库吧，所以我们放了一个非核心业务在上面。
再看一下AI，现在好像不谈AI都不好意思说自己是混互联网的了。从年3月，阿尔法狗以来，整个业界掀起了一场AI热。
我们看一下跟我们数据库相关的，年6月份，谷歌出了一个OttrTun，它自动去学习、自动去调优数据库配置的工具。
当时我的感受就是完了，再不搞AI，感觉下一波浪潮里要被淘汰了。
其实我们这里运维社区也发布了一个叫《AIOps的白皮书》，我看了，大体就是不管目前处于什么阶段，都可以尝试去做AI，DvOps刚起步可以做，DvOps到了成熟阶段也可以去做。AI在一些场景下面还是比人好用，它可以协助我们处理很多问题，如异常检测、关联分析、容量预测、故障预测等。
AI是大势所趋，我觉得大家应该要积极去拥抱。我们这边做了数据库容量预测，比如我一套实例，每天上报容量数据，经过预测后，会知道什么时候需要扩容，这个已经做了，可能做得没那么深。还有就是异常检测，具体的方法我这里就不展开。AI落地思路大体就是利用大数据，然后用机器学习去做。
此次的分享就这么多，谢谢大家！
这是一个最好的时代，这是DvOps时代
DvOps国际峰会正式起航