读写分离原理
读写分离原理图
看到这个图，首先想到的是什么是读写分离
读写分离采用一主多从的方式，数据库的业务一般读多写少，读锁是一种共享锁，写锁是排他锁，虽然inner db引擎的行级锁做的已经非常优秀了，但是还是会存在一些锁竞争的问题，另外，读并发量很大的情况下，会对数据库造成很大的压力；
为什么做读写分离，业务发展到什么时候需要做读写分离
随着业务发展，数据量越来越多，读成为系统发展的瓶颈，这时候，最先想到的一定是引入缓存，memcache,redis,缓存的开发复杂度，要小于读写分离，引入缓存也是要考虑缓存的高可用性，只有加了缓存数据的读依然还是系统瓶颈时，我们才会去考虑分库分表，读写分离的操作，脱离业务发展来谈架构的操作都是在耍流氓；
怎么做
·一主一从，一主多从都可以
·数据库主机负责读写操作，从机主负责读操作
·数据库主机通过binlog把数据同步给从机，每台服务器都有全量的数据
·业务服务把写操作和部分（后边会说哪部分）读操作落进主机，大部分读操作落尽从机器
引入复杂度
一.主从复制的延时
mysql中主从复制可能达到一秒钟，大量数据同步，时延甚至达到一分钟，造成的问题就是数据刚刚写进主库，还没来的急去复制到从库，用户马上就去查从库，查不到刚刚写入的信息，比如用户刚刚注册，马上登陆，提示用户名不存在，造成用户的困惑；
解决方案
1.写操作后边的读操作去访问主库（前边埋下的坑），注重方式对业务侵入太高
2.二次读取，读从库没有读到，再去主库读一次，缺点是会增加主库的压力
3.关键业务流量指向主机，非关键性业务指向从机，典型的用户签名，自我介绍，延时个几秒钟，对用户影响不打
二.流量分配的复杂性
如果采用单机架构，不用处理访问落到哪台机器上，采用主从架构后，需要考虑这一点
解决方案
1.代码封装
多个数据源，用多个mybatis文件的方式来处理，读写分离的问题，实现方式对业务有侵入
建议采用开源的解决方案，比如淘宝的tddl,
2.中间件封装
独立出一套系统，对数据库来说，他是服务层，对服务层来说，他是数据层，
网友评论