分布式套路之分库分表漫谈

既然是“漫谈分库分表”，那么我们需要确定我们要谈什么，不谈什么。

1. 首先，我们不讨论具体的分库分表框架的实现和源码，这不是我们讨论的范围。

2. 我们讨论的是思路，主要讨论如何分库分表的套路，有什么坑，有什么心得，不针对具体的细节进行展开式讨论。当然我自己的能力有限，只是希望能够抛砖引玉。

3. 我们要明确，分库分表，并不是一个银弹，它只是我们针对MySQL单机性能不够的情况下，想要节约成本的一种方式。对于boss来说，既想要想要节约成本，又想要支撑业务，提供稳定持久度性能。

程序员发挥出聪明才智，绞尽脑汁，日复一日的努力与实践，最终产生出主要的两种方式：

1. agent嵌入式模式，用一个jar包，集成到我们的代码里，在代码里通过路由规则，分片键方式进行分库分表，属于嵌入式方式。

2. cs模式（客户端-服务端模式），提供一个三方组件， 如： mycat，sharding-sphere中的proxy方式，类似于mycat；存在中心化，需要保证三方组件的高可用。

如果有更好的技术选型，我们宁愿不用分库分表，因为它本身就是一个复杂的解决方案。只是一种折中，更合适的是NewSQL、商业化数据库（比方说，Oracle，在大部分场景下，性能足够用，但是费用高昂）。

如果真的有一天，出现了一个优秀的、经济的newSQL, 比方说 oceanbase，tidb，那么我们基本上可以告别分库分表。

我们之所以选择使用分库分表策略，根本上还是因为，一方面是因为我们的使用成本不能太高；一方面，单机DB数据库性能不够了；一方面，newSQL当前还不成熟，太贵，不敢用。

分库分表用的厂家挺多的，有丰富的开源框架，有社区，还有成熟的案例，所以我们采用，

直接原因在于，阿里站台了，我们国内的风气是，阿里用啥我用啥，阿里怎么做我这么 跟风严重。我的想法是，我们还是有自己的技术前瞻性一些看法，最好不要唯阿里，唯技术。

说了这么多，我们回归正题，开始看问题。

1. 只做分表可以吗？还是必须要分表又分库，如果是分库的话 库是在多个服务器上吗？这个怎么来考虑

我想说，还是要看业务规模，既看当前的业务规模，也看未来3-5年的业务发展趋势。

涉及到技术选型，我们的宗旨是，永远选择最适合当下业务的、成本最低的，收益最高的，合适的就是最好的。

我们选择的方案最好是技术团队刚刚好能够hold住的选型。如果选型已经不适合当前的业务发展，那么大可以换套更适合的。这个本来就是事物发展的必然规律。

要么，业务还没发展到一个更高层次，就已经GG了，那么刚刚好，不用浪费钱买更好的设施，刚好止损；

要么，就是当前的方案确实不够用了，我们换了一套更牛X的，虽然说这样会花更多的钱，请更多的人，但是，这不正合我们的心意么，我们的目的本身就是通过合适的技术架构，更加优秀的代码，支持业务发展。

一句话总结就是，既然不得不花钱，那该花就花吧。

分场景讨论

一图胜千言，我们分别看看这两种场景。

对于 离线数据分析场景

<