故事篇：数据库架构演变之路

故事的开头总是这样，适逢其会、猝不及防。今天我哼着“也是黄昏的沙滩上，有着脚印两对半......”在海边散步，迎面走来了一位身穿黄金甲的男子，来海边还穿这么花哨，真是个傻 X。定睛一看，这不是嘉文吗？

背景介绍：嘉文四世，德玛西亚皇子，是有名的高富帅。与盖伦、菊花信并称草丛三剑客，整天嚷嚷着“犯我德邦者，虽远必诛”。

嘉文： 我在老爸的支持下自己开了家银行，最近有一个问题一直困扰着我：不知道怎样才能使我的银行业务处理起来又快又稳呢？

阿 Q： 内心 OS：我靠，土豪就是土豪呀，都开银行了。（假装淡定）你现在的模式是怎样的呢？能不能简单说一下你模式的转变过程呢？

单机 MySQL 的美好年代

嘉文： 我首先把银行定在了一个极具发展潜力的城郊上。从目前发展来看，我都佩服我自己。前期这边人不是很多，所以我就雇佣了一个柜员来处理存钱取钱的简单业务。

旁白: 看到这种单机模式，相信大家都倍感亲切吧，曾几何时，大家都是从这种单机项目起步的。那时候项目比较小，而且业务逻辑也比较简单，大家为了能够尽快地实现业务系统，验证市场，会将所有的业务数据都存放在同一个数据库中。

单机+缓存

阿 Q： 那你这一天也处理不了几个人的业务呀，这要是赶上周末来几十个人你就接待不了了呀。

旁白： 随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。

嘉文： 对呀，所以我就去别家银行看了看，几乎每家银行都有一个漂亮的小姐姐在那里接客。呸呸呸，是帮客户办理业务，所以我就又请了个大堂经理来负责办理那些小额又简单的业务。

旁白： 为了尽快缓解用户访问的压力，一般在优化数据库的结构和索引的基础上，会在应用服务器和数据库服务器中间加一个缓存层来抵消掉一部分的数据库查询操作。

主从复制：读写分离

阿 Q： 嗯嗯，这样确实解决了一部分问题。哎，我听说去年你们那边通地铁了吧？这样人流岂不是增加了，这样一来，加上大堂经理应该也不够用吧。

旁白： 增加数据库缓存层只能缓解数据库读取压力，拦截部分数据库访问请求。但是随着用户访问量的进一步增长，读写集中在一个数据库上让数据库不堪重负，数据库访问的瓶颈进一步凸显出来。这个时候，就不得不对数据层的架构进行改造。

嘉文： 谁说不是呢，还好我机智，我又招了两个人，把窗口进行了优化：A 专门负责存款业务，BC 窗口负责取款业务。这样一来，存取款业务就分离了，处理效率也就增加了。

旁白： 我们会启用多个数据库实例，把数据库划分为主库和从库：主库负责写入数据，又被称为写库；从库负责读取数据，又被称为读库，其中读库可以有多个。

主从库之间通过同步机制把主库的数据同步到从库，对于需要查询最新写入数据的场景，可以在缓存中多写一份，通过缓存获得最新数据。

主、从库可以部署到同一台服务器上，但是为了提高性能，在资源充足情况下，最好部署到不同的服务器上。

垂直拆分业务数据

阿 Q： 不错不错，没想到你还有这招，让我刮目相看呀。那你这边除了存取款业务，就没有其他的业务了吗？

嘉文： 那肯定得有呀，我可不能让他们老闲着聊天呀。我去年年底又增加了基金的业务，想着培养这批年轻人树立理财的意识，我是不是太无私了。但是自从加了这些业务，人手又不够了。哎！

旁白： 当我们使用了主从数据库架构之后，我们会发现我们能支撑更多的用户访问和请求了。但随着业务的进一步发展，如电商系统中增加了商品库存系统，此时就会与原有的订单系统抢占数据库资源，相互影响性能，导致数据库的压力进一步增大。

阿 Q： 听说你去年没少挣呀，那你是怎么解决的呢？

嘉文： （显示出得意的表情）我直接从外边挖来一个高管，让他和他的团队只负责基金等理财业务，我现有的团队还在传统的业务上。这样他俩相互工作，互不影响。

旁白： 为了缓解业务扩张导致的数据库压力问题，我们可以按照业务将数据库进行垂直拆分：将订单系统和商品库存系统的数据库分离开来，降低业务之间的资源竞争，使用独有的数据库进行存储。

水平分表

阿 Q： 现在大家都全面实现小康社会了，人们手里都有钱了，是不是现在存钱的人变多了呀。

嘉文： 昂，这不是前几个月我又招了几个大学生，扩展了一下柜台，专门用来负责存款业务嘛。

旁白： 以电商为例，随着用户交易量的增多，单张订单表已经无法满足存储的要求。此时我们可以将一张表拆成多张表来存储，采用一定的策略进行水平扩展，将请求尽可能的均匀的分发到服务器的各个小表中，并发量也进一步得到提升。

集群部署

阿 Q： 我听盖伦说你们那边小区入驻率很高呀，人流变大了，业务也突飞猛进吧。

嘉文： 哈哈，这就是我最自豪的事了，我又开了一家银行。照搬原来的模式，又搞了一套，这样东边和西边各有一个就不用担心忙不过来了。

旁白： 随着数据量的持续猛增，我们可以采用集群的方式来减轻访问的压力。但是集群的性能并不能很好的满足互联网的要求，只是在高可靠性上提供了非常大的保证。

NoSQL 数据库和搜索引擎

阿 Q： 我去，太牛了老铁，那你还愁眉苦脸的干啥，听你这么一说，该愁眉苦脸的是我呀。

嘉文： 你有所不知，前几天这边的商场开业了，辐射了周边，把周边的好多人都吸引来了。存取款的人一多，忙不过来了，总不能再开一家吧，再开一家的成本和收益比太低了，不值当的。

阿 Q： 奥奥，原来如此。我觉得你可以这样规划：在东西两家银行里都放几台 ATM 取款机，这样他们就不会去柜台办理存取款的小额任务了；再在新开的商场旁边租个门店，扔几台 ATM 取款机，减少了人工成本，这样你不就满足逛商场的人的需求了？

旁白： 当我们数据库中的数据数量和多样性达到一定规模后，仅仅使用 MySQL 已经无法满足我们的需求了，因此引进了其它的数据存储方式。拿电商为例，我们可以对其中的信息大致分类：

• 商品的基本信息存到MySQL、Oracle等关系型数据库中；

• 商品的描述、详情、评价等信息可以采用MongDB等文档数据库来存储，可以提高IO读写性能；

• 商品的图片采用分布式的文件系统HDFS；

• 商品的关键字可以使用搜索引擎ES、Solr；

• 商品的波段性热点高频信息可以使用内存型数据库Redis、Tair；

• 商品的交易、价格计算、积分积累等可以使用第三方接口或者支付系统。

嘉文： 有道理呀，术业有专攻呀，这样我晚上就可以睡个好觉了。走，带你出去嗨去！

阿 Q： 走着！

以上故事纯属虚构，只为给大家演示一下数据库架构的演变历程。真实的银行系统及业务如何办理，阿 Q 没有特别深入的研究，只是剧情需要杜撰了一下，仅为了增加大家的理解。

如果你有不同的意见或者更好的idea，欢迎联系阿 Q：可以关注公众号“阿 Q 说代码”，也可以加阿 Q 好友qingqing-4132，阿 Q 期待你的到来！