18-MySQL读写分离+分库分表
正常情况下，只要当单机真的顶不住压力了才会集群，不要一上来就集群，没这个必要。有关于软件的东西都是越简单越好，复杂都是形势所迫。
一般是
先优化，优化一些慢查询，优化业务逻辑的调用或者加入缓存等，如果真的优化到没东西优化了然后才上集群，先读写分离，读写分离之后顶不住就再分库分表。
1. 读写分离
读写分离顾名思义就是读和写分离了，对应到数据库集群一般都是一主一从(一个主库，一个从库)或者一主多从(一个主库，多个从库)，业务服务器把需要写的操作都写到主数据库中，读的操作都去从库查询。主库会同步数据到从库保证数据的一致性。
这种集群方式的本质就是把访问的压力从主库转移到从库，也就是在单机数据库无法支撑并发读写的时候，并且读的请求很多的情况下适合这种读写分离的数据库集群。如果写的操作很多的话不适合这种集群方式，因为数据库压力还是在写操作上，即使主从了之后压力还是在主库上和单机区别就不大了。
在单机的情况下，一般做数据库优化都会加索引，但是加了索引对查询有优化，但是会影响写入，因为写入数据会更新索引。所以做了主从之后，可以单独的针对从库(读库)做索引上的优化，而主库(写库)可以减少索引而提高写的效率。
看起来还是很简单的，但是有两点要注意：主从同步延迟、分配机制的考虑；
1.1 主从同步延迟
主库有数据写入之后，同时也写入在binlog(二进制日志文件)中，从库是通过binlog文件来同步数据的，这期间会有一定时间的延迟，可能是1秒，如果同时有大量数据写入的话，时间可能更长。
这会导致什么问题呢？比如有一个付款操作，你付款了，主库是已经写入数据，但是查询是到从库查，从库里还没有付款记录，所以页面上查询的时候你还没付款。那可不急眼了啊，吞钱了这还了得！打电话给客服投诉！
所以为了解决主从同步延迟的问题有以下几个方法：
- 二次读取
二次读取的意思就是读从库没读到之后再去主库读一下，只要通过对数据库访问的API进行封装就能实现这个功能。很简单，并且和业务之间没有耦合。但是有个问题，如果有很多二次读取相当于压力还是回到了主库身上，等于读写分离白分了。而且如有人恶意攻击，就一直访问没有的数据，那主库就可能爆了。
- 写之后的马上的读操作访问主库
也就是写操作之后，立马的读操作指定访问主库，之后的读操作采取访问从库。这就等于写死了，和业务强耦合了。
- 关键业务读写都由主库承担，非关键业务读写分离
类似付钱的这种业务，读写都到主库，避免延迟的问题，但是例如改个头像啊，个人签名这种比较不重要的就读写分离，查询都去从库查，毕竟延迟一下影响也不大，不会立马打客服电话哈哈。
1.2 分配机制的考虑
分配机制的考虑也就是怎么制定写操作是去主库写，读操作是去从库读。
一般有两种方式：代码封装、数据库中间件。
- 代码封装
代码封装的实现很简单，就是抽出一个中间层，让这个中间层来实现读写分离和数据库连接。讲白点就是搞个provider封装了save,select等通常数据库操作，内部save操作的dataSource是主库的，select操作的dataSource是从库的。
优点：就是实现简单，并且可以根据业务定制化变化，随心所欲。
缺点：就是是如果哪个数据库宕机了，发生主从切换了之后，就得修改配置重启。并且如果系统很大，一个业务可能包含多个子系统，一个子系统是java写的一个子系统用go写的，这样的话得分别为不同语言实现一套中间层，重复开发。
- 数据库中间件
就是有一个独立的系统，专门来实现读写分离和数据库连接管理，业务服务器和数据库中间件之间是通过标准的SQL协议交流的，所以在业务服务器看来数据库中间件其实就是个数据库。
优点：因为是通过sql协议的所以可以兼容不同的语言不需要单独写一套，并且有中间件来实现主从切换，业务服务器不需要关心这点。
缺点：多了一个系统其实就等于多了一个关心。。如果数据库中间件挂了的话对吧，而且多了一个系统就等于多了一个瓶颈，所以对中间件的性能要求也高，并且所有的数据库操作都要经过它。并且中间件实现很复杂，难度比代码封装高多了。
MySQL读写分离一般通过中间件实现:
mysql_proxy：mysql_proxy是MySQL的一个开源项目，通过其自带的lua脚本进行sql判断。Atlas：是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。Amoeba：阿里巴巴开发。
1.3 同步方案
本地缓存标记
上图流程：
1）用户A发起写请求，更新了主库，并在客户端设置标记，过期时间（预估的主库和从库同步延迟的时间），可以使用cookie实现
2）用户A再发起读请求时，带上这个cookie
3）服务器处理请求时，获取请求传过来的数据，看有没有这个标记
4）有这个业务标记，走主库；没有走从库。
这个方案就保证了用户A的读请求肯定是数据一致的，而且没有性能问题，因为标记是本地客户端传过去的。
但是无法保证其他用户读数据是一致的，但是实际场景很少需要保持其他用户也保持强一致，延迟个几秒也没问题。
2. 分库分表
读写分离其实只是分担了访问的压力，但是存储的压力没有解决。
存储的压力说白了就是随着系统的演化，需求的增加，可能表的数量会逐渐增多，比如一段时间上个新功能就得加个表。并且随着用户量的增多类似用户表的行数肯定会增多，订单表的数据肯定会随着时间而增多，当这种数据量达到千万甚至上亿的时候，读写分离就已经满足不了，读写性能下降严重。
也就是一台服务器的资源例如CPU、内存、IO、磁盘等是有限的，所以这时候分库分表就上啦！
2.1 分库
分库讲白了就是比如现在你有一个数据库服务器，数据库中有两张表分别是用户表和订单表。如果要分库的话现在你需要买两台机子，搞两个数据库分别放在两台机子上，并且一个数据库放用户表，一个数据库放订单表。
1. 联表查询问题
也就是join了，之前在一个数据库里面可以用上join用一条sql语句就可以联表查询得到想要的结果，但是现在分为多个数据库了，所以join用不上了。就比如现在要查注册时间在2019年之后用户的订单信息，你就需要先去数据库A中用户表查询注册在2019年之后的信息，然后得到用户id,再拿这些id去数据库B订单表中查找订单信息，然后再拼接这些信息返回。所以等于得多写一些代码了。
2. 事务问题
搞数据库基本上都离不开事务，但是现在不同的数据库事务就不是以前那个简单的本地事务了，而是分布式事务了，而引入分布式事务也提高了系统的复杂性，并且有些效率不高还会影响性能例如Mysql XA。还有基于消息中间件实现分布式事务的等等这里不展开讲述。
2.2 分表
我们已经做了分库了，但是现在情况是我们的表里面的数据太多了，就一不小心你的公司的产品火了，像抖音这种，所有用户如果就存在一张表里吃不消，所以这时候得分表。分别又分垂直分表和水平分表。
1. 垂直分表
垂直分表的意思形象点就像坐标轴的y轴，把x轴切成了两半，对应到我们的表就是比如我们表有10列，现在一刀切下去，分成了两张表，其中一张表3列，另一张表7列。
这个一刀切下去让两个表分别有几列不是固定的，垂直分表适合表中存在不常用并且占用了大量空间的表拆分出去。
就拿头条的用户信息，比如用户表只有用户id、昵称、手机号、个人简介这4个字段。但是手机号和个人简介这种信息就属于不太常用的，占用的空间也不小，个人简介有些人写了一坨。所以就把手机号和个人简介这两列拆分出去。
那垂直分表影响就是之前只要一个查询的，现在需要两次查询才能拿到分表之前的完整用户表信息。
2. 水平分表
水平分表的意思形象点就像坐标轴的x轴，把y轴切成了两半(当然不仅限于切一刀，可以切好几份)。也拿用户表来说比如现在用户表有5000万行数据，我们切5刀，分成5个表，每个表1000万行数据。
水平分表就适合用户表行数很多的情况下，一般单表行数超过5000万就得分表，如果单表的数据比较复杂那可能2000万甚至1000万就得分了，这个得看实际情况有些表很简单可能一亿行都不用分。所以当一个表行数超过千万级别的时候关注一下，如果没有性能问题就可以再等等看，不要急着分表，因为分表会是带来很多问题。
水平分表的问题比垂直分表就更烦了。
要考虑怎么切，讲的高级点就叫路由。
1）按id也就是范围路由
比如id 值1-999万的放一张表，1000万-1999万放一张表，一次类推。这个得试的，因为范围分的大了，可能性能还有问题，范围分的小了。。那表不得多死。
这种分法的好处就是容易切啊，简单粗暴，以后新增的数据分表都不会影响到之前的数据，之前的数据都不需要移动。
2）哈希路由
就是取几列哈希一下看看数据哪个库，比如拿id来做哈希，1500取余8等于4，所以这条记录就放在user_4这个表中，2011取余8等于3，所以这条记录就放在user_3中。这种分法好处就是分的很均匀，基本上每个表的数据都差不多，但是以后新增数据又得分表了咋办，以前的数据都得动，比较烦！
3）搞一张表来存储路由关系
还是拿用户表来说，就是弄一个路由表，里面存userId和表编号，表示这个userId是这张user表的的。这种方式也简单，之后又要分表了之后改改路由表，迁移一部分数据。但是这种方法导致每次查询都得查两次，并且如果路由表太大了，那路由表又成为瓶颈了！
再说说查询时候的问题。
比如你要查注册时间最早的前100名用户，这就等于你得在水平分的每一张表都order by 一下注册时间并且取100个，然后再把每个表的100个结果对比一下得到最终的结果。首先操作变麻烦了，以前一个order by就搞定的事情现在变的复杂了，而且还得考虑一个因素就是时间的问题，如果你拆成了20个表，那你得执行20个order by，如果是串行执行的话，这个时间开销也是个问题！
分库分表的实现：具体实现也分为程序代码封装、数据库中间件封装。
3. 总结
说了这么多好像分库分表一点都不好啊，没错会引入很多问题，所以在架构设计要遵循演化原则，任何东西都不是一蹴而就的，在不同场景适配不同的架构，架构只有合适的，没有一个架构可以适配任何场景。
在软件中简单够用就是好的，技术没有贵贱，不是用了分布式就牛逼，越复杂的系统维护的成本和难度越高，出现问题的几率越大。这种架构的演化往往都是被用户所驱动的，可以说是”不得已而为之”。
基本上单机数据库可以支撑10万用户量级别，所以一般情况下像数据库吃不消就升级硬件，优化数据库配置、优化代码、引入redis等。只有在真的不行了才上这些更复杂的东西。