多租户系统数据库连接池的那些事

Question

多租户连接池

最近对多租户数据库连接池做了一下改造。改造之前，是一个商户一个小池子，数据库连接只是在小池子里共享。改造之后，是所有商户都一个大池子，数据库连接在大池子中共享。每个商户请求时，从大池子里拿连接，然后切换到自己的商户库中。
效果还是杠杠的，一下子把以前的尖刺给削平了。纪念一下。

改造之后留下的小坑

从连接池中获取连接后，需要将连接切换到当前请求的商户库上。但是如果连接池上次使用时，就是当前商户库，则跳过切换的动作。这个设计本意是利用状态，避免重复切换。但是在实际部署过程中，由于新开商户的数据库，暂时需要手工配置账户权限，导致没有配置权限之前，出现串库现象。很快就从代码中，找到了问题。

1. 第一次访问，连接被打当前商户标记（本质是连的别的商户库）后，切库失败抛出异常；
2. 用户再次尝试访问，刚好拿到上次的连接，发现刚好是当前商户（假象），不切库，导致串库。

连接池连接数配置公式

https://mp.weixin.qq.com/s/dYUGA0wLfn-GbWrMKRKAAQ

下面的公式是由 PostgreSQL 提供的，不过我们认为可以广泛地应用于大多数数据库产品。你应该模拟预期的访问量，并从这一公式开始测试你的应用，寻找最合适的连接数值。

连接数 = ((核心数 * 2) + 有效磁盘数)

核心数不应包含超线程(hyper thread)，即使打开了 hyperthreading 也是。如果活跃数据全部被缓存了，那么有效磁盘数是 0，随着缓存命中率的下降，有效磁盘数逐渐趋近于实际的磁盘数。这一公式作用于 SSD 时的效果如何尚未有分析。

按这个公式，4 核 i7 数据库服务器的连接池大小应该为((4 * 2) + 1) = 9。

更少的线程[更接近于 CPU 核心数]会发挥出更高的性能。只有当阻塞创造了更多的执行机会时，更多的线程数才能发挥出更好的性能。

笔者注：

这一公式其实不仅适用于数据库连接池的计算，大部分涉及计算和 I/O 的程序，线程数的设置都可以参考这一公式。我之前在对一个使用 Netty 编写的消息收发服务进行压力测试时，最终测出的最佳线程数就刚好是 CPU 核心数的一倍。

公理：你需要一个小连接池，和一个充满了等待连接的线程的队列