DBA 会架构，实际案例分析--“IT流氓”得下跪-优快云博客

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2790人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群260+ 9群)

这个世界太疯狂，玩数据库的，都要懂架构，那架构师干嘛去？在这个谁能，谁上的世界，搞数据库的能不能玩架构，我觉得可以，至少那些扣在数据库上的翻不了身的锅，就的有地方说到说到了。

我们先不说大道理，我们以一个实例来说明，为嘛数据库不懂架构吃亏。

A项目，是一个综合类的项目，对接着B、C、D、E、F多个其他项目，A项目为部分项目的基础数据，同时A项目也接受其他项目推送来的业务数据。A项目的数据库经常出问题，这里总结经常出什么问题。

1 经常有其他项目的大事务推送过来，且密集型UPDATE，INSERT。

2 经常需要给其他项目进行基础数据推送，当其他项目的基础数据出现故障或不统一的时候，需要进行统一拉取数据。

3 A项目本身就是一个业务繁忙的项目，自己本身的DML 就比较多，DDL 也经常有，因为要对接其他的项目，其他的项目的字段变化了，这边也要变化，添加字段了也要添加字段。

这就导致以下几个问题

1 A项目的表宽表多

2 A项目的表数据量大

3 A项目的表经常发生死锁和BLOCKED

4 A项目的表将从被全表读取，因为要拉取数据

最终导致A项目的数据库经常告警，不是CPU,就是内存，IOPS持续的告警。

我们按照DBA的等级来给出处理方法

1 添加索引，优化SQL，建立规范，减少误操作。

这样的解决方法，只能解决简单的问题，而当上面的B C D E F，IN OUT ，大事务一来，马上就歇菜。

2 更换数据库产品

作为DBA架构，那么如果是这样的情况，第二个祭出的方案就是更换更强有力的数据库产品，通过技术来化解这些问题，比如更换吞吐量更大的分布式数据库，或者将其他的数据库产品引入，如REDIS,MONGODB ，但这样的解决方案，很多情况下会落空，因为项目改动量太大，架构师未必答应，同时备不住反过来还给你DB扣帽子，把三维问题，给你打回二维，继续说你SQL优化的不好，没有加好索引，等等技术问题。

3 DBA 升级思维模式，升级为架构师思维模式

1 架构思维第一式：拆分法

如上图，如果 B C D F 项目不讲究，经常推送大事务，突发事务，DELETE 操作等给A项目，造成A库承担了太多的业务属性，那么首先就要祭出拆分法。

拆分法本身是从业务出发将一些可以拆出与A项目业务核心无关的，但属于对接的信息拆出，比如如，配置信息，基础信息，业务对接信息，只要与A项目实时业务无关的信息都挑出去。

结果：A项目本身的性能的问题将只和自己的业务有关，此时在祭出低维度的解决方案如，SQL优化，索引优化，先进的数据库技术将本身的问题解决。

至于与A项目无关的部分，什么B项目推送大事务了，F项目经常拉取档案数据，C项目经常丢失配置信息了，D项目经常拉取核心信息，都将这些放到另外一个库。

那么这里属于解决自己的问题，将矛盾激化的阶段，在处理一些棘手问题的方法，现将自己置身事外，然后激化矛盾，那么这里A项目的矛盾就从内部矛盾，变成外部矛盾。

你可以说，这是B项目因为推送大事务，导致锁表，所以F项目你拉取数据的任务无法完成，也可以和C项目说，因为D项目经常丢失数据，整体拉取数据，导致A的IOPS高，你UPDATE的时候正好赶上，所有有延迟。

那么方案可以继续优化，比如我们将经常拉取的数据缓存话，A库对外的信息拉取部门将变成REDIS的数据库，满足B快速拉取的问题。同时将F库快速的大事务的数据库转成 MOGNODB，这样外部的A库就变成了。

上图的样子，整体的问题很可能会进一步化解，当然问题可能还没有完全解决，A 库中C和D两个一个需要写入，一个需要读取，同时读写分离还要求数据的时效性，也就是 C 和 D 之间的业务是上下游的问题，D希望C 库立即交付数据。

那么这里DBA架构对于数据库的理解能力，和丰富的知识程度就显现了，MYSQL首先就被封杀，通过BINLOG 进行主从复制将读写库解耦的方法，不能满足业务的要求，首先就被抛弃。

那么可以满足读写分离，主从一致的数据库的名录里面，如MongoDB,PostgreSQL,SQL SERVER, ORACLE，或者我们可以选择主从强一致的数据库 POLARDB for MySQL, POLARDB FOR PostgreSQL 来做支持，如果实在阿里云上的话，且这两者的数据强一致性是建立在高性能的模式，也就是主库写完，从库必须在20ms内显现主库的数据，这样的方案基本上满足 C 写数据，D要读数据，读写分离解耦，但满足数据一致性的要求，且也能满足A项目自己对数据的获取，因为如果读取的节点性能无法满足，POLARDB 可以制造出 15个从节点，且数据强一致。基本上读写分离数据强一致的老大难问题就从数据库这个角度解决了。当然有可能有人会说，那 A 库和 A库之间数据同步的问题呢，我们可以找到一些即时性的CDC软件来解决，如TapData,上一秒写数据到数据库，下一秒就可以传到另一个库里消费。

此时一个DBA如果有如此的境界，来解决问题，很多的黑锅想扣到他脑袋上，估计是难了！！八张嘴等着那些不长进的家伙呢？DBA 会架构，看谁还敢轻易欺负DBA。

置顶

数据库的 4月1日愚人节，我没有被愚弄！

搞 PostgreSQL多才多艺的人--赵渝强《PG数据库实战派》

追逐太阳的男人--林春《金融数据库转型实战》

数据库的 4月1日愚人节，我没有被愚弄！

数据库界的“申公豹”，带云DBA走出--救生筏困境！

阿里云DTS 产品，你真让我出离愤怒，3年了病还没治好？？？

让数据先“活”起来，如何实现数据在企业中的最大价值

专访唐建法-从MongoDB中国第一人到TapData掌门人的故事

ETL 行业也够卷，云化ETL，ETL 软件不过了

天上的“PostgreSQL” 说地上的 PostgreSQL 都是“小垃圾”