1、增加缓存
在web层和db层之间加一层缓存。减少数据库读取负担，提高数据读取速度。
2、业务拆分
分库：以电商平台为例，包含了用户、商品、评价、订单等几大模块，最简单的是在一个数据库中创建四张表。
随着业务规模的增大，需要对业务进行拆分。每个表都使用单独的数据库进行存储，将原本对一个数据库的依赖拆分成对4个数据库同时承担压力，提高系统吞吐量。
3、Mysql主从复制、读写分离
当数据库的写压力增加，cache只能缓解数据库的读取压力。使用主从复制技术达到读写分离，以提高读写性能和读库的可扩展性。
读写分离就是只在主服务器上写，从服务器上读：主数据库处理事务性查询，从数据库处理select查询。
- 主从只负责各自的读和写，极大程度缓解X锁和S锁的竞争。
- slave可以配置MyISAM引擎，提高查询性能节约系统开销。
- 增加冗余，提高可用性。
3.1 主从复制概念
数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。
3.2 主从复制用途
读写分离
在开发工作中，有时候会遇见某个sql 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。
数据实时备份，当系统中某个节点发生故障时，可以方便的故障切换
架构扩展
随着系统中业务访问量的增大，如果是单机部署数据库，就会导致I/O访问频率过高。有了主从复制，增加多个数据存储节点，将负载分布在多个从节点上，降低单机磁盘I/O访问的频率，提高单个机器的I/O性能。
3.3 Mysql主从形式
一主一从
一主多从
一主一从和一主多从是最常见的主从架构，实施起来简单并且有效，不仅可以实现HA，而且还能读写分离，进而提升集群的并发能力。
多主一从
多主一从可以将多个mysql数据库备份到一台存储性能比较好的服务器上。
双主复制
双主复制，也就是互做主从复制，每个master既是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。
级联复制
级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。因为如果主节点有太多的从节点，就会损耗一部分性能用于replication，那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。
3.4 Mysql主从复制原理
MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点
- 主数据库有个bin-log二进制文件，记录了所有增删改sql语句。（binlog线程）
- 从数据库把主数据库的bin-log文件的sql语句复制过来。（io线程）
- 从数据库的relay-log重做日志文件中再执行一次sql语句。（sql执行线程）
上图主从复制分了五个步骤进行：
- 步骤一：主库的更新事件(update、insert、delete)被写到binlog
- 步骤二：从库发起连接，连接到主库。
- 步骤三：此时主库创建一个binlog dump thread，把binlog的内容发送到从库。
- 步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log
- 步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db。
3.5 mysql主从复制模式
MySQL 主从复制默认是异步的模式。MySQL增删改操作会全部记录在binary log中，当slave节点连接master时，会主动从master处获取最新的bin log文件。并把bin log中的sql relay。
- 异步模式
- 半同步模式
- 全同步模式
4、分表分库
在cache层的高速缓存，MySQL的主从复制，读写分离的基础上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。采用Master-Slave复制模式的MySQL架构，只能对数据库的读进行扩展，而对数据的写操作还是集中在Master上。这时需要对数据库的吞吐能力进一步地扩展，以满足高并发访问与海量数据存储的需求。
对于访问极为频繁且数据量巨大的单表来说，首先要做的是减少单表的记录条数，以便减少数据查询所需的时间，提高数据库的吞吐，这就是所谓的分表。在分表之前，首先需要选择适当的分表策略，使得数据能够较为均衡地分布到多张表中，并且不影响正常的查询。
分表能够解决单表数据量过大带来的查询效率下降的问题，但是却无法给数据库的并发处理能力带来质的提升。面对高并发的读写访问，当数据库master服务器无法承载写操作压力时，不管如何扩展Slave服务器都是没有意义的，对数据库进行拆分，从而提高数据库写入能力，即分库。
数据库经过业务拆分及分库分表，虽然查询性能和并发处理能力提高了。但是原本跨表的事务上升为分布式事务；由于记录被切分到不同的库和不同的表中，难以进行多表关联查询，并且不能不指定路由字段对数据进行查询。且分库分表后需要进一步对系统进行扩容（路由策略变更）将变得非常不方便，需要重新进行数据迁移。
分表策略：
- 使用用户ID是最常用的分库的路由策略。
- 当数据比较大的时候，对数据进行分表操作，首先要确定需要将数据平均分配到多少张表中，也就是：表容量。
这里假设有100张表进行存储，则我们在进行存储数据的时候，首先对用户ID进行取模操作，根据 user_id%100 获取对应的表进行存储查询操作。
在实际的开发中，我们的用户ID更多的可能是通过UUID生成的，这样的话，我们可以首先将UUID进行hash获取到整数值，然后在进行取模操作。
分库策略：
数据库分表能够解决单表数据量很大的时候数据查询的效率问题，但是无法给数据库的并发操作带来效率上的提高，因为分表的实质还是在一个数据库上进行的操作，很容易受数据库IO性能的限制。
因此，如何将数据库IO性能的问题平均分配出来，很显然将数据进行分库操作可以很好地解决单台数据库的性能问题。
分库策略与分表策略的实现很相似，最简单的都是可以通过取模的方式进行路由。
分库与分表实现策略：
上述的配置中，数据库分表可以解决单表海量数据的查询性能问题，分库可以解决单台数据库的并发访问压力问题。
有时候，我们需要同时考虑这两个问题，因此，我们既需要对单表进行分表操作，还需要进行分库操作，以便同时扩展系统的并发处理能力和提升单表的查询性能，就是我们使用到的分库分表。
分库分表的策略相对于前边两种复杂一些，一种常见的路由策略如下：
１、中间变量 ＝ user_id%（库数量*每个库的表数量）;
２、库序号 ＝ 取整（中间变量／每个库的表数量）;
３、表序号 ＝ 中间变量％每个库的表数量;