1、增加了数据库等连接池后，架构发生了变化，进行了一定的性能提升 主从读写分离： 大部分系统时读多，写少，读写的数据量可能会有几个数量级 刷朋友圈的肯定比发朋友圈的多太多了。 所以这时候的优化要考虑到主从读写分离 主从就要涉及到主从的数据复制过程： 1、主从复制， mysql的主从复制全部依赖于binlog ， mysql的所有变化以二进制的形式存在磁盘上的二进制日志文件中， binlog从主库传输到了从库上，一般这个过程时异步的，主库操作不等待binlog同步完成 从库连接到主节点，会创建一个io线程， 请求binlog的信息，并写入relay_log中，然后在从库进行回放，最终从库一致性 可以进行一主多从多配置，最多挂3-5个从库，因为从库多了，主库需要log dump线程来处理复制的请求，对主库资源消耗大 ，主库的网络带宽也是限制 问题点：主从延迟问题，解决办法： 1、尽量不去从库查询数据，可以进行数据的冗余。 2、使用缓存，写入库的同时在缓存中进行记录 缓存的方案比较适用于新增数据 3、查询走主库（明确查询的量不是很大） 4、运维增强保证对主从延迟的一些监控和报警 缓存，如果是更新数据的操作，可能会导致库里和数据库不一致的问题 如何访问数据库： 数据库中间件，来解决数据库的访问问题 业务继续扩张，单表的数据量太大了 数据量大了：占用磁盘空间，恢复和备份时间长，索引也占用很大的空间，查询也会很慢 分库分表， 对数据库进行垂直拆分和水平拆分 依照策略将数据尽量平均地分配到多个数据库节点或者多个表中 垂直拆分： 分库，专库专用，好处： 1、业务影响解耦，单独存储对应的业务 2、垂直拆分一般是按照业务来进行拆分的 当单个库数据量也很大的情况下，分表 - 水平拆分： 水平拆分表，按照某些字段来进行拆分 1、某个字段的hash值进行拆分 2、根据时间长度来进行拆分 - 数据不平均，表需要按时提前建好 3、查询的时候比较难确定是哪个库哪个表，数据库中间件来解决问题 假如是用user_id来进行水平区分，那之后的查询必须带user_id才能确定表地址并进行查询 如果不带user_id怎么办？难道全部都查一遍吗？ 思路：可以引入几个简单的映射表，比如user_id和哪几个字段的 映射关系 分库分表后的id的全局唯一： Twitter. Snowflake 算法，生成唯一id Nosql的区分： Redis ，base，MongoDB 传统的数据库都是机械磁盘， 对于磁盘的访问有两种方式： 一种是随机IO，一种是顺序IO, 随机IO需要 话费时间去做昂贵的磁盘寻道， 读写效率要比顺序IO 小两到三个数量级，所以尽量减少随机IO LSM树， 牺牲了一定的读性能换取了写入数据的高性能，