如果评委的SQL数据库真的有2W+的高并发，那我真的要恭喜你了。你已经比很多公司的MIS高级多了。2W和2K有这么大的区别吗？嗯，有。2K并发的MIS系统也经常出现无法访问和超时异常。处理这些异常就足以让很多朋友操心了。2W+并发需要了解的知识框架就更复杂了。笔者曾服务过一个500W+用户的电商系统，再也不想看到24/7的噩梦了。几年前，我在一个电商平台工作，团队里有超过500万的直销顾问。平时的流量很稳定，基本都在几千，月底会冲上来拼性能，会有1W+的并发。大多数数据库开发人员在日常生活中仍然是无情无压力的。不过电商系统有个习俗，是淘宝带出来的，会搞促销，类似于双11，这个时候要时刻警惕流量是不是井喷了。一旦越过红线，系统就会和之前的12306一样，经常延迟。在DBA组的介入下，慢慢解决了这个问题。写这篇文章的初衷也是来自于对这段经历的总结。1、单实例数据库应用这种应用架构最简单，UI+应用服务器+数据库服务器，所有的请求，不管是读还是写，都直接丢给数据库。往往在一个项目的早期阶段，为了快速证明我们的想法是可靠的并推向市场，我们会选择这样的架构来实现产品。这时候往往注册了10万用户，但是每天的访问量才200多，每个数据库表的总数最多不会超过5000。这样一个应用，一个开发能力强的人就可以搞定，复杂的业务需要分前后端。但无论如何，这是一个基础工程。如果工作三四天后还是这个模式，就该补课了。事物总是在发展的，只要系统正常运行，总有一天用户会增加，随之而来的请求会超出你的想象（前提是你做过pv,uv数据分析），很这种架构会很快就会遇到超过100万的用户，超过20万的日访问量，2万的并发峰值，数据库表的数量将逼近亿级。这时候如果应用系统还是基于原来的硬件（比如16GB、16核、240GB硬盘），你应该会明显感受到拖卡慢的尴尬，更多的是用户的吐槽和抱怨。就像12306前期买票，轮到你的时候，票往往没了。2、多实例数据库遇到流量增加的应用，如果确定压力在数据库上，那么分库是必然的。将一个大数据库拆分成若干个小数据库，并保持数据库对象一致。这样，各个小数据库会分担一部分流量，应用最终会回到最初的简单架构，很好地服务用户。以目前4000并发的硬件，简单的商用是没有问题的。你能负责多少取决于系统上线后的基线（baseline）监控。这里我们假设4000并发。所以分成5个相同的库做分库。这足以同时写入4000个并发。这里会遇到一个技术细节，就是分库路由。如何将流量平均分配到各个图书馆，需要开发一种算法。例如，已知全国用户分布均衡，即华东、华北、西部、华南、华中各有4000个用户。我们根据地理位置分成5个数据库，根据用户身份证哈希成5个哈希值，分别对应5个数据库，对用户进行导流。只要用户数量不剧增，老板对这家小而美的企业很满意，这个架构就可以一直沿用下去。基本上不会有瓶颈。顶多时间长了，表数据越来越大了。我们可以用分库的思想来分表。当前年（月）数据放在主表中，历史数据归档在聚合表中；或者简单的每个月，每年分表存储，跨时间段的查询由视图控制。但是用户的行为总是不可控的，所以我们必须要做一系列的事情来满足和留住用户。比如促销、打折、团购等。这时候，用户的行为已经不是下单、买杯咖啡那么简单了。他们会大量查询他们的数据，导致读请求远大于写请求。众所周知，即使读请求不影响写请求（如MVVC），也会耗尽服务器的CPU\IO\Network资源。那我们还要更上一层楼，读写分离。3.读写分离读写分离是另一种分库，但与前面的分库有着不同的用途。分库与源库完全一样，都是只读的，不接受用户写请求。每个数据库的实现细节不同，也可以使用实时同步工具。详情请参考《Designing Data-Intensive Applications》一书。不仅给出了指导思想，还指导了各个数据库的读写分离组件。
