在分布式数据库技术选型前，我们都考虑些什么？

对于许多金融企业（含互金）来说，在系统初始阶段，使用 ‘IOE’ 技术选型进行核心系统的搭建，似乎是种标配，但随着系统拆分的演进，从年初起，我们开始讨论数据库中长期规划的相关话题。

跟大多数金融行业的数据库选型一样，我们的核心系统运行在商业关系型数据库之上，而将大部分 QPS 交给分布式缓存来进行处理。

01. 为什么选择 MySQL 作为选型

在这一点上，通过大量的调研与大咖交流后，我们最初除 MySQL 外，还尝试了解过例如 PostgreSQL，TiDB 等其他不同种类的 DB，但最终选择了 MySQL，不是说 MySQL 最优秀，也不是其它 DB 不优秀，更重要的原因是 MySQL 可以对他们的业务模型在支撑上更方便一点，更重要的原因是其他数据库的人才难招、难管、难养活。

除此之外，其他数据库在国内社区没发展起来，用户及业务场景覆盖度不够广等原因，也是产生顾虑的主要来源，而反观 MySQL，无论社区还是产品成熟度，相对更加稳定、更加活跃。

大胆设想下，除非业务规模已处于 “扛不住了，不干就死了” 的地步，又有哪家强业务驱动型的金融企业，愿意建立 “一个看似华丽，投入又大的数据库团队” 呢？疯了吧？

以上这些原因，促使我们选择了 MySQL。

02. 为什么要开搞分布式数据库

简明扼要，列出思考的起始点（如与 Oracle 数据库相比）：

• 钱往哪花？购买商业数据库授权？还是用开源数据库+自主研发？

• 服务越来越多怎么办？搞过 Oracle 的人都知道，面对越来越多的服务数量，及越来越小的服务颗粒，光存储设备的投入，就可以让你眼睛一辣。

• 怎么上云？虽说现在 Oracle 12C 号称能够上云，但并不是所有的云厂商都能支持，就算能支持，也会开出个天价。

• 数据越来越大怎么办？这点上，Oracle 有着完美的解决方案，但又不能光看这一项而忽略以上几项，可 MySQL（单/群）又无法满足，只能通过对数据的水平拆分，或者垂直拆分来进行加持。

• 数据库管理的成本怎么投？这点上，Oracle 也属于完胜，但是该把这部分钱投在买商业管理软件上呢？还是投在自主研发上呢？如果选择商业路线，后期的维护可以跟上吗？

其实，以上五点未必都是“不用分布式数据库就会死”的核心理由，有些也只不过是借助这件事的推动，而期望获得的辅助收益罢了。

不管怎么说，数据库，一个系统（或者一家企业）的命脉，在业务发展进入稳定期之后，结合自身特点、技术价值观及中长期技术投入考虑，选定一个关系型数据持久化的技术选型进行长久的规划与孵化，是非常有必要的。

03. 分布式数据库有哪几种玩法

根据思考的起始点，我们整理出两种玩法，下面我以笔记的形式进行下罗列：

第一种：重量级中间层

大体上可以分为两类形态：

• 商业形态：如腾讯云 DCDB、阿里云 DRDS。

• 开源形态：如 MyCat、Cobar。

商业形态

把大部分关于数据库的操作通过数据库的中间价层来去实现，例如支持各种规则的分库和分表，支持分布式事物，支持各种分片节点的聚合等操作。

优点

• 使用中间价来分担后端的数据库的压力。

• 使用中间价来完成数据聚合，减少开发的代码逻辑。

缺点

• 会产生一定购买中间价的费用。

• 对于中间价和中间件厂商的依赖过大。如果中间件厂商不靠谱，毕竟代码不开源，那时候我们该应对？

开源形态

目前主流的开源 MyCAT 和 dble 等产品。dble 主要是针对 MyCAT 进行 bug 的修复和一些新功能的完善。目前社需活跃，修复 bug 还算及时。

图 1. MyCat 的系统拓扑图

优点

• 相对商业化的产品，可能不需要依赖云平台，可以节约一定成本。

• 代码开源，可以根据实际情况进行修改。

缺点

• 部分功能的不支持，不如商业产品的完善 可靠。

• 虽然代码开源，如要针对进行功能的添加和二次的修改，要么依赖社区或者厂商，要么自己招聘相关的工程师。

第二种：轻量级中间层

轻量级的中间价的开源产品主要有 proxysql，由国外工程师开发，目前社区活跃，修复 bug 和更新代码能力的频率还是挺好的。

中间价主要的工作就是，按照规则连接的转发。把前端的 SQL 解析，按照一定的路由规则，发配到后端数据库，然后数据库返回结果，并吐给前端应用。可以做到读写分离 或者分库等。

图 2. 自研 ProxySet 模式的系统拓扑图

优点

• 相对商业化的产品，可能不需要依赖云平台，可以节约一定成本。

• 代码开源，可以根据实际情况进行修改。

缺点

• 不一定能满足我们的业务的场景，可能需要开发同学大力的配合。

• 虽然不在过渡依赖中间价产品，但对后端的数据压力确增大了，这就意外后端的数据库需要更好的机器 更好的配置。

此外，也可以直接裸用 MySQL，简单粗暴的雇佣 20 个 DBA，1 人只管理一个 MySQL 实例，并配置最牛逼的机器，来解决目前的现状，想想也挺好的。

根据上述方案我们看到，对于体量较小的业务层，理论上采用第二种方案更经济实惠，而对于体量较大，并发性、稳定行要求较高的，理论上采用第一种方案更为稳妥。

本文转载自头哥侃码公众号。

原文链接：https://mp.weixin.qq.com/s/UsUOwbEWOmulGsmeY8lSFg