一、实现高性能数据库集群

一般我们业务在读多写少的场景下，遇到的第一个瓶颈就是数据库这块，大量的读请求会来到数据库，这样如果你初期部署的一个数据库就会造成IO大量增加，使得请求变慢，甚至会卡死整个数据库，到了这个阶段，我们一般会将读请求和写请求进行分开数据处理，即采用主从读写分离的方式。

注：这里说的是主从并不是主备，主从中的从服务器是要承担业务的，而主备中备份机器一般只作为备份存在。

我们采用主从读写分离的方式，目的是为了将更多的读请求进行分发来缓解我们的大量读请求。

读写分离架构原理

正如上面所说，读写分离是为了将请求流量分散到不同的数据库节点上，将写入数据的请求分发到主数据库，读取数据的请求分发到从数据库，从数据可以有多台，即一主多从。如下图：

从上图可看出，有个关键技术就是主从复制，每次写入数据的时候，需要将主服务器数据复制到从服务器中，用来确保数据一致性。下面我们来单独看看主从是怎么复制的，以我们互联网中最熟悉的MySQL为例。

1. 从服务器连接上主服务器，启动复制的时候，则会自身创建一个IO线程去像主数据库服务器拉取binlog的更新信息。
2. 把拉过来的binlog信息写到自己服务器的一个relay log日志文件中。
3. 从数据库服务器创建一个SQL线程，是为了将relay log的所有日志信息，进行sql回写到自己的数据库中，这样就和主库的数据一模一样了。
4. 当主数据库有数据更新的时候，比如新插入了一条或者update了一条数据，这时候主库会将这些数据更新到binlog二进制文件中，同时，主库会创建一个binlog dump线程，这个线程将更新了的binlog信息发送到从库的IO线程，需要注意的是，这个过程是异步的，如果等着从库接受完成，是不是特别慢，且影响性能。

这样的“一主多从”的主从复制方案做好之后，现在咱们就不怕当前这些大量的读请求了，因为我们把这些大流量读请求都分发到这些从数据库中了，写入数据的请求依然还是写到主数据，一点不影响我们读的业务，互不影响的。同时，从数据库还可以作为备份数据库来使用，万一主库突然故障了，它可以顶上去防止数据丢失。

但是，我们不能一味的加从数据库，加个十七八个的，这样做是无脑的操作啊，你想想看，你加一堆的的从数据库连接到数据库，复制他的数据，太多的IO线程会造成主数据不堪重负的，就会造成你写入数据慢，还会卡死，这就悲剧了。所以，不能这么搞啊，一般生产环境一个主数据库挂三个从数据就行了，最多不能超过5个以上，要是还是不满足肯定就会有其他方案了啊，多级缓存方案啊，是不是，后面会讲的。

主从延时

上面说了主从读写分离的那么多好处， 主从同步是有延迟的，当然，这个延时一般都在ms级别，但是如果到了秒级别，可能就会对有些业务造成影响，看我们能否接受。比如，我们在支付系统创建支付单后，风控系统会进入查询作出相应的风控操作，如果查不到就会可能终止本次交易了。

主从延迟优化

1. 我们可以在这些立马需要查的业务，让它直接查主数据库，但是这种方案不推荐，因为量大怕会拖垮主数据
2. 当从数据库读取不到，我们回去再读主数据，这样就能读到数据了。但是，这种也是有风险的，量大也会拖垮主库。
3. 像我前面文章提到过，分重要性业务和非重要业务，将很核心的几个业务查主数据，其他非核心，读写分离。
4. 使用缓存，将新增的数据同时添加一份缓存，然后查缓存数据，这种建议新增的数据使用缓存较好。
5. 使用消息队列中间件进行消息冗余，将新的主数据内容，通过消息中间件MQ冗余一份当前数据，然后发到需要查询的系统。

在消息体不大，推荐使用第 5 种优化方案，需要消息中间件；其次考虑缓存, redis,Memcache 都可以的，因为更新的操作，需要更新缓存，也需要解决一致性问题，所以，新增的数据，就首选缓存优化方案。最后，推荐重要性非重要性隔离方案。最好不要使用都查询主库的操作。

如何优雅使用读写分离

我们现在使用了数据库读写分离的机制，但是我们代码该怎么去友好的去访问数据库呢？以前我们一个数据源配置就可以了，现在有好多个数据源了，代码里既要区分哪个地方使用写数据库的数据源，哪个地方需要使用读数据的数据源。当然，肯定是有办法的，业界大佬们都早于我们遇到了这些问题，下面我会分享出两种方案：

1，程序代码嵌入

代码嵌入，是指通过在我们的代码中开发出数据库访问中间层，由这个数据库访问中间层去访问不同的数据源，以实现读写分离和数据源的管理。现在推荐使用淘宝开源的TDDL（Taobao Distributed Data Layer），使用方便，直接集成到我们代码就可以了，它自己管理读写分离和数据库配置。

特点是：

• 实现简单，可以根据自己业务进行定制化开发

• 语言不同，就得开发不同语言版本的数据库访问层

2，部署独立代理层

部署代理层是指，在我们的业务服务器和数据库直接引入数据访问代理层，并不用自己写代码。现在为代表的开源中间件有阿里的MyCat、360的Atlas、美团的DBProxy等。这些都是使用标准的MySql通信协议。

特点：

• 不用自己编写多余代码，使用方便。

• 支持对语言

• sql语句会跨两层网络，性能稍微低一点。

建议，在自己公司没有比较成熟的中间件团队的话就用程序代码封装的方案，虽然写代码麻烦点，但是自己可以把控；要是公司有成熟中间件团队，就尽量考虑代理层部署的方案，因为需要有个团队要研究和长期维护这个代理层，才能确保业务正常发展，现在我们公司大部分都用的是代理层方案，是有个专门团队来维护。

总结，今天讲到了当我们读多写少的场景下，采取数据库读写分离的方式来分摊大流量。

二、大量并发写入所带来的性能问题优化

随着运营部门的同事在不停的做出各种促销或者拉新活动，我们注册用户越来越多，同时订单量以及用户行为数据等持续的增加，导致我们的系统现在出现了下面这些问题。

1. 订单量剧增，单表数据量已经达到了千万的级别了，这个时候的索引查询已经很慢了，所以现在我们的类似这些大数据表的查询性能很差
2. 数据量持续增加，现在我们的磁盘大部分空间都被使用，导致数据库的复制备份操作很缓慢，所以，目前数据库系统已不能满足现在的数据量级。
3. 我们整个系统的所有业务，订单，用户，优惠券、政策等等都在一个数据库系统，耦合性太高，数据不隔离。
4. 像每天大量的用户关注、行为数据以及订单数据的写入，导致系统的写入性能持续下降。

以上这些问题均是由于大并发的写入操作导致目前的系统读写性能下降，并且系统可用性也在降低，这些都是现在阶段需要解决的，需要将这些数据进行分片，也就是分散开，栏均摊我们整个数据库的数据压力，同时也是解决单机数据容量以及性能的解决方案，我们业界现在比较流行的方法就是“分库分表”的方案。

提到分库分表，大家应该都不陌生，但是怎么在自己项目中合理的使用分库分表却不是一件容易的事情，从今天开始，我们从分库分表的策略到怎么部署上线以及怎么避坑等内容开始切入，帮助大家更好的掌握并使用分库分表的技术

怎么做数据库垂直拆分

垂直拆分是分库分表方案中最为常见的一种方式，大的核心思想就是，将一堆的统一数据放到其他节点数据库中或者表中进行存储，不同于我们前面主从复制，主从复制是所有节点数据都是一样，而垂直拆分后，是每个节点存储一部分数据，就像Hadoop里面的一个个的Block一样。

垂直拆分好处：

• 有效解决了单个数据库或者表的数据存储瓶颈。
• 有效提高数据查询性能。
• 有效提高并发写入性能，因为是可以写到多个库里面了。

我们公司的有个项目，你就理解我是用户关注类的就行，这些数据已经到了亿级别的了，之前是没分库分表的，到了亿级别之后，不论是查询还是写入或者是报表之类的，反正就是各种痛苦，后来就是进行分库分表，分到多个库，才得以解决。

垂直拆分策略

我们现在知道了我们急需分库分表的操作了，但是，我们该通过什么策略去将我们的数据库进行垂直拆分呢？我这里建议是，我们最好按照我们的系统业务来进行垂直拆分，垂直拆分就是将数据库竖着拆分，根据业务的不同将原有数据库中的那些表分到不同的数据库节点中。

不同的数据库对应着不同的业务，比如，我们将用户相关的表放在了用户数据库节点里，订单相关的表放在了订单数据库节点上，关注相关的表放在了关注数据库节点里。这样还有个好处就是，我们的关注数据量庞大到了几亿的量级如果影响到了数据的操作，但是并不影响用户的登录和浏览、搜索下单操作。起到了很好的数据隔离的作用。

案例展示

以前，我们用户表、关注表、订单表都在同一个库里面，也就是在我们的主库中，后来经过拆分后，它们分别被拆到用户库、关注库、订单库等。

垂直拆分这种方案，其实在我们中等规模的互联网公司里都会首先使用到，但是，随着数据的增加这种单库里面的表还是会面临瓶颈的，看上面我讲的我们关注表数据，虽然拆到了关注库里面，但是关注表数据都已经好几亿了，仍是会影响我们这块业务的。所以说，垂直拆分只能暂缓我们的问题，但是，像那种单表数据骤增的情况还是需要采取另一种方法的，那就是我们下面要说的水平拆分。

怎么做数据库水平拆分

水平拆分的核心思想是，将单一数据表数据按照我们约定的某种规则进行拆分到多个数据库和数据表中，我们的关注点是在表数据本身上。

有哪些常用拆分规则

1，按照表中某一字段取哈希值进行拆分,例如我们的用户表，如果将其拆分为16个库，每个库64张表，那么，我们就将UID哈希，为什么哈希大家知道吧，前面文章分析了hashmap，应该都懂吧。然后将哈希值对16取余，得到哪一个数据库，然后对64取余就知道哪个表。这种规则比较适用于这种实体类的表。

2，按照某一个表字段的区间做拆分，这里最常使用就是日期字段了，比如我们关注表的创建时间，比如我们要查某个月的关注数据，就可以将月份数据放进对应月份表中，这样我们就可以根据创建时间来定位到我们数据存储在哪张表里面，然后在根据我们的查询条件进行相应的查询。

数据库进行分库分表后，我们代码怎么去访问，也会带来一定的麻烦，之前只用访问一个库就行了，现在数据都被分到其他库里面了，这个和我们前面的读写分离差不多，可以去看看（）

现在数据库的分库分表解决了我们数据库瓶颈、并发写入和读取等问题，也解决了我们扩展和数据隔离的问题，但是引入了分库分表，也会给我们带来一些问题：

怎么解决分库分表带来的问题

1，分区键

分区键就是我们用来进行分库分表的字段，我们每次查询的时候都必须得带上这个字段，才能找到数据所在的库和表，我们将上面用户数据按照uid进行分库分表的，那如果现在我想按照昵称来查询怎么办呢？

• 这里我们一般建议，另外建立一张UID和昵称的映射表。
• 然后通过昵称查询出UID
• 在通过UID就可以进行定位到库和表了

2，多表JOIN

我们现在的单表数据都被分到多库多表中了，然后有些程序员之前写的那些连表join 操作怎么办，跨库了，就不能使用JOIN了。所以这块我们需要将他们放到我们业务代码中进行处理了，其实代码中处理我们会更清晰一些

3，统计类

和上面JOIN类似，类似统计的count()就不能使用了，然后这块我们建议是，通过另外建一张表活着放到redis缓存里面，最后再合并就行了，也很简单。

最后建议，我们在我们的业务中不要一开始就去分库分表，在没必要的情况下不要去分库分表；如果真的要分库分表，在公司资源充足下，建议一次性分到位，会给你很爽的感觉，比如分16个库64张表，资源紧缺的话，我们就根据业务来分，后续会将一些更过的方案。

总结，今天我们针对大并发的写入造成的我们数据库的瓶颈以及性能低下问题，我们就引入了分库分表的方案，主要分为数据库垂直拆分和水平拆分，也提到了拆分后给我们带来了哪些挑战并且给出相应的解决方案。

三、分库分表后，保证ID全局唯一

上两篇讲到了我们的系统在面临大并发读取的时候，采用了读写分离主从复制（数据库读写分离方案，实现高性能数据库集群）的方案去应对，后来又面临了大并发写入的时候，系统数据库采用了分库分表的方案（数据库分库分表方案，优化大量并发写入所带来的性能问题），通过垂直拆分以及水平拆分的方式，将数据分到多个库和多个表中去应对的，即现在是这样的一套分布式存储结构。

数据库分库分表那篇也讲到了，使用了分库分表势必会带来和我们之前使用不大相同的问题。今天，我将其中一个和我们开发息息相关的问题提出来进行讲解，也就是我们开发中所使用的的主键的问题。我们知道，以前我们单库的时候，主键唯一ID是自增的，现在好了，我们的数据被分到多个库的多个表里面了，如果我们还是使用之前的主键自增策略，那么这样就会出现两个数据插入到了两个不同的表会出现相同的ID值，这时我们该怎么去使用呢？

对于什么是主键，主键该怎么选，今天不做讲解，我相信大家可能比我还精通，我们今天主要是讲唯一主键ID在分布式存储系统下怎么生成，保证ID的唯一性且符合我们业务需要，才是我们开发人员最关心的实战。

UUID

这个时候，你可能会说，自增用不了，那我就是用UUID嘛，这个UUID生成出来的就是唯一的。的确，在我以前在一个公司中的确接触到是使用UUID来生成唯一主键ID的，而且性能还可以。但是，我想提一点的就是，当这个ID和我们业务交集不相关的时候是可以使用UUID生成主键的。比如，一般我们业务是需要用来做查询的，而且最好是单调递增的，这样我们的UUID就很不适合了。

主键ID单调递增有什么好处呢？

1，就拿我们用户关注航班这个模块来说，我们查看某个航班关注用户按照时间的先后进行排序。因为现在的ID是时间上有序的，所以现在我们就可以按照ID来进行排序了，同时这样对于有些并不是要存储时间的业务来说，会减少不少的存储空间。

2，有序的ID可以提升数据写入的性能

我们知道主键其实在数据库中就是一种索引，而索引在MySql数据库的B+数据结构中是顺序存储的，所以每次插入的时候就是递增排序的，直接追加到后面就行。如果是无序的话，则每次插入数据之前还得查找它应该所在的位置，这无疑就会增加数据的异动等相关的开销，如下图：

如上图所示，如果我们生成的ID是有序的，那这个 50 就直接插在尾部就行了，如果是无序的话，突然生成了一个 26，我们还得先找到 26 需要存放的位置，然后还要对其后面数据进行挪位置。

3，UUID不具备业务相关性

我们现在开发的项目都是依据公司业务开展的，而我们的唯一ID一般都是和业务有关系的，比如，有些订单ID中带上了时间的维度、机房的维度以及业务类型等维度。也就是为了我方便进行定位是那种业务的订单，才会这么设计的，是不是。

而UUID是由32位的16进制数字组成的字符串，不仅在存储空间上造成浪费，更不具备我们业务相关性。那我们该怎么解决呢？其实Twitter提出来的Snowflake 算法就能很好满足我们现在的要求，满足了主键ID的全局唯一性、单调递增性，也可以满足我们的业务相关。所以，我们现在使用的唯一ID生成方式就是使用Snowflake算法，这个算法其实很简单。下面我们来对其进行讲解，并对其相应改造使其能用到我们的开发业务中来。

Snowflake 算法原理

Snowflake 是由 64 比特bit二进制数字组成的，一共分为4大部分：

• 1位默认不使用

• 41位时间戳

• 10位机器ID

• 12位序列号

1. 我们从上图中可以看出snowflake算法的第二部分的41位时间戳，大概可以支撑2^41/1000/60/60/24/365 年，也就是大约有69年。我们设计一个系统用69年应该是足够了吧。
2. 10位的机器ID我们可以怎么使用呢？我们可以划分成大概2到3位IDC,也就是可以支撑4到8个IDC机房；然后划分7到 8 位的机器ID，即可以支撑128~256台机器。
3. 12位的序号，就代表每个节点每毫秒可以生成4096个ID序号。

如何改造

我们现在已经知道了Snowflake 算法的核心原理，并且知道了其有64位的二进制数据，那我们就可以根据自己业务进行改造以更好的来为我们业务服务。一般不同的公司对其进行改造的方式都不尽相同，但是道理都是一样的。我们可以这么做：

1. 我们是减少序列号的位数，增加机器ID的位数，是为了用来支撑我们单IDC的更多机器。
2. 将我们业务ID加入进去用来区分我们不同的业务。比如，1位0 + 41位时间戳 + 6位IDC(64个IDC) + 6位业务信息（支撑64种业务） + 10位自增序列（每毫秒1024个ID）

如此，我们就可以在单机房部署这么一个统一ID发号器,然后用Keeplive 保证高可用（对于高可用不熟悉的回去看看哈「高可用」你们服务器挂了怎么办，我们是这样做的）可以将不同的业务模块ID加入进去，这样的好处是即使哪个业务出问题了，我只看ID号我就分析出来，比如，我看到现在ID号有我的订单ID业务，我就去看订单模块。

开发如何使用

现在我们知道Snowflake 算法原理了，还知道了我们可以进行改造了。那我们开发人员该怎么去使用，来为我们业务生成统一的唯一ID呢？

1，直接嵌入到业务代码

嵌入业务代码的意思就是，这个snowflake算法就部署在和我们业务相同的服务器上，这样我们代码使用的时候，就不用了跨网络调用，性能相对比较好。但是也是有缺点的，因为我们的业务机器肯定是很多的，这就意味着我们发号器算法需要更多的机器ID位数。同时，太多的业务服务器我们会很难保证业务机器id的唯一性，这里就需要引用zookeeper一致性组件来保证每次机器重启都能能获得唯一的机器ID。

2，独立部署成发号器服务

也就是说，我们将其作为单独的服务部署到单独的机器上，已对外提供服务。这样就是多了网络的传输，不过影响不大，比如，我可以将其部署成一个主备的方式对外提供发号服务，机器ID可以用作序列号使用，这样也就是会有更多的自增序号，有部分大厂就是以这样单独的服务提供出来的。

开发中避坑大法

1，虽然snowflake很优秀，但是它是基于系统时间的，万一我们系统的时间不准怎么办，就会造成我们的ID会重复。那我们的做法就是，要利用系统的对时功能，一旦发现时间不一致，就暂停发号器，等到时钟准了在启用。

2，还有一个坑比较关键，也是常发生的，就是当我们的QPS并发不高的时候，比如每毫秒只生成一个ID号，这样就是直接结果是，每次生成的ID末尾都是1，这样我们分库分表就会出现问题呀对吧，因为我们用这个ID去分库分表呀，会造成数据不均匀，是吧，忘记了去复习哈（数据库分库分表方案，优化大量并发写入所带来的性能问题）那我们怎么解决呢？

我们可以将时间戳记录从毫秒记录改为秒记录，这样我一秒可以发好多个号了

生成的序列号起始号随机启动，比如这一秒起始号是10，我下一秒随机了变成了28，这样就更加分散开了。

总结，今天我们针对分库分表之后带来的第一个直接影响我们开发的问题，就是主键ID唯一性的问题，然后说到了使用Snowflake算法去解决，并且对其原理和使用进行了详细的讲解，同时，还将其在使用中遇到的坑给讲出来了，也对其进行了填坑分析，让大家直接避免遇到同样的问题。当然生成唯一ID有多种，我们根据业务选择合适我们自己的就好