MySql的读写分离

  数据量增多，单机的数据库不足以支撑业务，需要用到数据库集群。而读写分离，就是将数据库的读和写分离，对应到数据库一般就是主从数据库，一主一从或者一主多从；业务服务器把数据写到主数据库中，读操作都去从库读；主库会同步数据到从库，保证数据的一致性。

    这种集群方式，就是将访问的压力从主库转移到从库，单机的数据库不能支撑并发读写的时候，而且读的请求很多的情况下就适合数据库集群。如果写的操作很多的话，那就不适合这种集群方式，因为写的时候是写入主库，主库的压力还是没有变化，同时同步到从库也需要消耗资源。

    单机的时候，一般数据库优化就是加索引，但是加了索引对查询有优化，但是写入的时候会有影响，因为写入的数据库不会更新索引。所以在主从数据库中，可以单独的对读库（从数据库）做索引，而写库（主数据库）可以减少缩影而提高写的效率。

    但是主从数据库中需要注意：主从同步延迟、分配机制的考虑

主从同步延迟

    二次读取

      一般操作是，在从库读取数据时，没有读到数据，就去主库进行数据读取。但是这种操作还是将读的压力返还给主库，如果有恶意的攻击，主库就爆了。

        一般情况下，通过对数据库访问的API进行封装就能实现这个功能，业务之间没有耦合。

    写了之后的马上读操作操作主库

       在写了数据后，立马读操作就去访问主库，之后的读操作访问从库，这种业务上会有高度耦合。

    根据业务，将重要的业务数据的读写都放在主库，其他的业务进行读写分离

        类似付钱的这种业务，读写都到主库，避免延迟的问题，但是例如改个头像啊，个人签名这种比较不重要的就读写分离，查询都去从库查。

分配机制的考虑

        分配机制的考虑，就是怎么制定去操作去主库写，去从库读。

      代码封装

        抽取一个中间层，让中间层来实现读写分离和数据库连接。即封装一个provider，包含了对数据的save，query等操作，当save时操作的数据库是主库的，query时操作的数据库是从库。

        实现简单，但是如果如果其中一个数据库宕机了，就需要修改配置重启项目。还有如果有多个子系统的话，语言不一致的话，就会进行重复的开发。

      数据库中间件

        有专门的独立系统来实现读写分离和数据库连接管理，业务服务器和数据库中间件通过SQL协议交流，在业务服务器看起来，数据库中间件就是一个数据库。

        因为是通过sql协议的所以可以兼容不同的语言不需要单独写一套，并且有中间件来实现主从切换，业务服务器不需要关心这点。但是多了一个服务，就会有其他的消耗，难于管理，而且中间件性能要求高，实现复杂，难度高。

        开源的中间件有Mysql Proxy,Atlas。

 总结

        读写分离理解和实现相对简单，但是只能减少访问的压力，不能分担存储的压力，当数据增多是，查询的速度还是会很慢。这时候就需要用到分库分表了。

        正常情况下，单机不能支撑业务时，才会用数据库集群，软件设计越简单的设计越好。

        一般数据库的优化是，先优化一些查询操作，然后优化业务的逻辑，或者加入缓存，最后不行再用集群，最后再分库分表。

MySql的读写分离

标签：提高   width   实现   功能   api   auto   tla   接管   存储