数据量增多&＃xff0c;单机的数据库不足以支撑业务&＃xff0c;需要用到数据库集群。而读写分离&＃xff0c;就是将数据库的读和写分离&＃xff0c;对应到数据库一般就是主从数据库&＃xff0c;一主一从或者一主多从&＃xff1b;业务服务器把数据写到主数据库中&＃xff0c;读操作都去从库读&＃xff1b;主库会同步数据到从库&＃xff0c;保证数据的一致性。
主从集群
这种集群方式&＃xff0c;就是将访问的压力从主库转移到从库&＃xff0c;单机的数据库不能支撑并发读写的时候&＃xff0c;而且读的请求很多的情况下就适合数据库集群。如果写的操作很多的话&＃xff0c;那就不适合这种集群方式&＃xff0c;因为写的时候是写入主库&＃xff0c;主库的压力还是没有变化&＃xff0c;同时同步到从库也需要消耗资源。
单机的时候&＃xff0c;一般数据库优化就是加索引&＃xff0c;但是加了索引对查询有优化&＃xff0c;但是写入的时候会有影响&＃xff0c;因为写入的数据库不会更新索引。所以在主从数据库中&＃xff0c;可以单独的对读库(从数据库)做索引&＃xff0c;而写库(主数据库)可以减少缩影而提高写的效率。
但是主从数据库中需要注意&＃xff1a;主从同步延迟、分配机制的考虑
主从同步延迟
二次读取
一般操作是&＃xff0c;在从库读取数据时&＃xff0c;没有读到数据&＃xff0c;就去主库进行数据读取。但是这种操作还是将读的压力返还给主库&＃xff0c;如果有恶意的攻击&＃xff0c;主库就爆了。
一般情况下&＃xff0c;通过对数据库访问的API进行封装就能实现这个功能&＃xff0c;业务之间没有耦合。
写了之后的马上读操作操作主库
在写了数据后&＃xff0c;立马读操作就去访问主库&＃xff0c;之后的读操作访问从库&＃xff0c;这种业务上会有高度耦合。
根据业务&＃xff0c;将重要的业务数据的读写都放在主库&＃xff0c;其他的业务进行读写分离
类似付钱的这种业务&＃xff0c;读写都到主库&＃xff0c;避免延迟的问题&＃xff0c;但是例如改个头像啊&＃xff0c;个人签名这种比较不重要的就读写分离&＃xff0c;查询都去从库查。
分配机制的考虑
分配机制的考虑&＃xff0c;就是怎么制定去操作去主库写&＃xff0c;去从库读。
代码封装
抽取一个中间层&＃xff0c;让中间层来实现读写分离和数据库连接。即封装一个provider&＃xff0c;包含了对数据的save&＃xff0c;query等操作&＃xff0c;当save时操作的数据库是主库的&＃xff0c;query时操作的数据库是从库。
实现简单&＃xff0c;但是如果如果其中一个数据库宕机了&＃xff0c;就需要修改配置重启项目。还有如果有多个子系统的话&＃xff0c;语言不一致的话&＃xff0c;就会进行重复的开发。
数据库中间件
有专门的独立系统来实现读写分离和数据库连接管理&＃xff0c;业务服务器和数据库中间件通过SQL协议交流&＃xff0c;在业务服务器看起来&＃xff0c;数据库中间件就是一个数据库。
因为是通过sql协议的所以可以兼容不同的语言不需要单独写一套&＃xff0c;并且有中间件来实现主从切换&＃xff0c;业务服务器不需要关心这点。但是多了一个服务&＃xff0c;就会有其他的消耗&＃xff0c;难于管理&＃xff0c;而且中间件性能要求高&＃xff0c;实现复杂&＃xff0c;难度高。
开源的中间件有Mysql Proxy,Atlas。
数据库中间件
总结
读写分离理解和实现相对简单&＃xff0c;但是只能减少访问的压力&＃xff0c;不能分担存储的压力&＃xff0c;当数据增多是&＃xff0c;查询的速度还是会很慢。这时候就需要用到分库分表了。
正常情况下&＃xff0c;单机不能支撑业务时&＃xff0c;才会用数据库集群&＃xff0c;软件设计越简单的设计越好。
一般数据库的优化是&＃xff0c;先优化一些查询操作&＃xff0c;然后优化业务的逻辑&＃xff0c;或者加入缓存&＃xff0c;最后不行再用集群&＃xff0c;最后再分库分表。
京公网安备 11010802041100号