很多网站或APP平台随着用户量的增加，对于数据库并发压力的问题就越来越多，2W并发和2K并发的区别那么大吗？嗯，真的有。2K并发的办公系统也常常是不可访问的，timeout异常，处理这些异常已经让很多朋友感到困扰。2W+的并发需要理解的知识框架更加复杂。

作者曾经服务过800W+用户的电子商务系统，7*24小时再也不想看到恶梦。几年前，我在一个拥有500多万直销顾问的团队建立了一个电子商务平台。平时的流量很稳定，几乎有一千人，月底业绩突破，1W+的并发。大部分数据库开发人员在日常生活中没有肺和压力。但是，电气商务系统有淘宝带来的惯例，促销就像双11.到了这个时间段，必须随时警惕流量是否井喷，越过红线，系统就像前期的12306一样频繁延迟。随着DBA组的介入，逐渐解决了这个问题。本文的初衷也来自于这段经历的总结。

单个实例数据库的应用。

这种应用架构最简单，UI+应用服务器+数据库服务器，所有的请求，读写都直接投入数据库。在项目初期，为了迅速证明自己的想法，获得市场，我们会选择这样的结构来实现产品。此时，通常有10万用户注册，但每天访问的人数刚刚超过200人，每张数据库表的总数最多不超过5000人。这样的应用，如果开发能力强，一个人就能搞定，业务复杂需要分前端和后端。但是，无论如何都是基础项目，如果你工作了3、4次还是停留在这个模式下，就应该补课。事物总是在发展中，只要系统正常运行，总有一天用户数量就会增加，随之而来的请求超出想象(以pv、uv的数据分析为前提)，这个结构很快就会遇到用户超过100万人，日访问量超过20万人，峰值合并2万人，数据库的表现接近亿级此时，应用系统应该在当初的硬件基础上(例如16GB、16核、240GB硬盘)明显感到卡慢的尴尬，增加的是用户的投诉和投诉。就像12306前期的买票，往往轮到你的时候，票就没了。

多个实例数据库。

遇到流量上升的应用，如果压力确定在数据库上，分库是必然的。将一个大库分成几个小库，使数据库的对象一致，使各个小库分配一部分流量，应用最终回到最初的简单结构，为用户提供服务。以现在的硬件服务4000个并发，对于不复杂的商业没有问题。具体来说，可以看到系统在线的baseline(基线)的监视，在这里假定4000并发。因此，分为5个相同的库，制作库。这样写4000并发就足够了。

在这里，技术细节是分库路由。如何将流量平均分配给各库，需要开发算法。例如，已知全国用户分布均衡，即华东、华北、华西、华南和华中，各有4000用户。我们根据地理位置分为五个库，根据用户身份证哈希成为五个散列值，分别对应这五个数据库，用户被分流。

只要用户没有激增，上司也满足这样小而美丽的生意，这样的结构可以一直使用。几乎没有瓶颈。最多的时间变长了，表的数据变大了，我们用分库的思想分钟就可以了。当前年(月)的数据放在主表中，历史数据存档在聚合表中，或者每月分为子表存储，跨时间段的查询用视图控制。

但是，用户的行为总是无法控制的，我必须做一系列的事情来满足和维持用户。例如促销、折扣、团购等。此时，用户的行为不仅仅是下一个单独买咖啡。他们大量查询他们的数据，带来的阅读要求远远大于写入要求。众所周知，即使读取请求不影响写入请求(例如MVVC)，也会消耗服务器的CPU\IO\Network资源。那么，我们必须进一层，读写分离。

读写分离。读写分离是另一个分库，但与以前的分库意图不同。分开的仓库和源仓库一模一样，只读不接受用户的写求。实现细节的每个数据库都不同，也可以使用实时同步工具。