项目读写分离必要性分析

读写分离的优缺点：

优点：

1.  提升查询性能以及节约系统开销
2.  优化用户查询数据体验

缺点：

1. 增加维护成本
2. 增加项目成本
3. 有潜在的主库从库一致性问题

数据库读写分离架构解决什么问题？

如果要配置读写分离，首先要明白读写分离是用来解决什么问题？

大多数互联网业务，往往读多写少，这时候，数据库的读会首先称为数据库的瓶颈，这时，如果我们希望能够线性的提升数据库的读性能，消除读写锁冲突从而提升数据库的写性能，那么就可以使用“分组架构”（读写分离架构）。

引入读写分离架构的必要性

其实大部分项目来说，配置读写分离其实得不偿失，增加项目支出成本，而且对于小公司来说，也会增加一部分的运维压力。

在平常的项目开发中，如何考量是否需要引入读写分离架构，其实可以从这几个维度进行分析：

1. 用户数量
2. 项目类型
2. 数据库调用并发性
3. 实际业务对数据的要求

在一般项目中，引入读写分离架构是必须慎之又慎的，，如果引入读写分离其实是只为技术的实现，而脱离项目业务场景的技术，强行应用都是“耍流氓”。

用户数量：在日常用户并发在不到5000，引入读写分离不建议，可以开启主从复制就好，防止主数据库挂了或者数据问题，可以实时切换，防止数据问题。如果还不行，完全可以进行一个服务端的负载均衡，启动tomcat集群来解决这一问题，这个成本及维护性对于后端来说，其实明显优于读写分离方案。

项目类型：对于互联网项目，实行读写分离技术其实是业务倒逼技术实现，不得已而为之，对于普通的内网项目甚至只是后台管理的项目，其实不必要引入。

数据库调用并发性：对于有的项目，可能是一种写多读少的项目，其实引入读写分离并没有什么优点，就如上面所说，引入读写分离是为了解决项目中的读多写少的业务场景，而对于写多读少的项目场景，这一技术的优势其实并不能针对性的解决问题。采用项目集群数据库主从复制，可能更好。

实际业务对数据的要求： 凡是技术都不能脱离业务去谈技术，对于对数据及时性有很大的要求的项目，还是可以考虑缓存中间件的技术或者升级硬件设施来解决。

如果有帮到你，欢迎关注博主的公众号“java云端”，不定时更新java技术。

没有梦想的咸鱼，一辈子都是咸鱼，拥有梦想的咸鱼，说不定就是小鱼干。