题图： from Zoommy

对于许多金融企业（含互金）来说，在系统初始阶段，使用 ‘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实例，并配置最牛逼的机器，来解决目前的现状，想想也挺好的。

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

- 小   结 -

数据库，从商业数据库切换至MySQL，无论是否分布式，都无法采取像中间件SDK那样的平滑适配方案（可参考 #我与SDK之间的爱恨悲欢# 这篇文章）。

光改SQL这一项，就不得不让你付出与重构相对等的成本与代价。

截止当下，我们正处于探索与方案尝试的阶段，所以本文也无法给出确切的方案，只是通过一些思考与整理，尽量让探索之路显得更明确、更贴身。

后期，我也会通过本公众号陆续分享 #我们在分布式数据库的进展和遇到的坑# ，欢迎关注。

感谢您的阅读

您的支持是我最大的前进动力

- End -