标签：mon 增加 传输 磁盘 朋友 mys 方案 提前 写入
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树， 牺牲了一定的读性能换取了写入数据的高性能，
架构- 数据库的优化
标签：mon 增加 传输 磁盘 朋友 mys 方案 提前 写入
原文地址：https://www.cnblogs.com/yingchen/p/11679375.html
