项目架构优化
目录
1.第一次架构优化:tomcat和mysql数据库分开部署.
2.第二次架构优化:引入缓存
使用memcache作为本地缓存,使用redis作为分布式缓存.
3.第三次架构优化:引入负载均衡策略
4.第四次架构优化:数据库读写分离
主库:写
从库:读
5.第五次架构优化:数据库按业务分库
6.第六次架构优化:使用LVS或者F5来使用多个Nginx负载的均衡.
7.第七次架构优化:通过DNS轮询实现机房的负载均衡.
8.第八次架构优化:容器化+微服务架构(此架构也可以从一开始就做).
单机架构:
tomcat和mysql数据库部署在同一台机器上,适合用户少的业务.
随着业务量增大,tomcat和mysql数据库之间会产生资源竞争,单机性能不能支撑业务.
1.第一次架构优化:tomcat和mysql数据库分开部署.
2.第二次架构优化:引入缓存
使用memcache作为本地缓存,使用redis作为分布式缓存.
3.第三次架构优化:引入负载均衡策略
使用负载均衡可以支持很大的并发量,但是更多的请求最终都到了单机数据库服务器上,此时数据库成为瓶颈.
4.第四次架构优化:数据库读写分离
主库:写
从库:读
一般业务都是读多写少,通过同步机制把主库的数据写入从库,可使用mycat这种数据库中间件,来组织数据库的读写分离和分库分表.
业务持续增大,不同业务间访问量差距巨大,造成不同业务间对数据库的竞争,相互影响.
5.第五次架构优化:数据库按业务分库
把不同的业务数据保存在不同的数据库中,使业务间的资源竞争降低,对于访问量大的业务,可以部署多个数据库节点来支撑.
数据库瓶颈:
1.cpu瓶颈:
1.sql问题.如果sql中有join,group by,order by,非索引字段条件查询,会增加cpu运算.
解决:sql优化,建立合适的索引.
2.单表数据量太大,查询的时候扫描太多的行,导致查询效率低,cpu使用率会升高.
解决:水平分表.
2.IO瓶颈:
1.磁盘I/O瓶颈.热点数据太多,数据库缓存放不下,后面查询都会产生大量的I/O,降低了查询
速度.
解决:分库+垂直分表.
2.网络I/O瓶颈:请求的数据太多,网络带宽不够.
解决:分库.
水平分库:以字段为依据,按照一定策略(hash,range),将一个库中的数据拆分到多个库中,库多了,每个
库的IO和CPU压力就小了.
结果:1.每个库的结构都一样.
2.每个库的数据都不一样,没有交集.
3.所有库的并集就是全部数据.
水平分表:以字段为依据,按照一定策略(hash,range),将一个表中的数据拆分到多个表中.
结果:1.每个表的结构都一样.
2.每个表的数据都不一样,没有交集.
3.所有表的并集就是全部数据.
垂直分库:以表为依据,按照不同的业务,将不同的表拆分到不同的库中(到这一步可以实行服务化了).
结果:1.每个库结构都不一样.
2.每个库的数据也不一样,没有交集.
3.所有库的并集就是全部数据.
垂直分表:以字段为依据,按照字段的活跃性,将表中的字段拆分到不同的表中(主表和扩展表);
结果:1.每个表的结构都不一样.
2.每个表的数据也不一样,每个表至少都有一列主键作为交集,用于关联数据.
3.每个表的并集就是全部数据.
垂直分表拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表,这样更多的热点数据就能被缓存下来,进而减少了IO,拆分之后想要获取全部数据就需要做关联查询,但不要用join,因为join不仅会增加CPU压力,而且会将2个表耦合在一起(必须在一个数据实例上),关联数据应该在业务层做优化,分别获取主表和扩展表的数据,然后用关联字段获得全部数据.
6.第六次架构优化:使用LVS或者F5来使用多个Nginx负载的均衡.
由于并发量太大,这个时候Nginx成了瓶颈,可以使用LVS或F5架构.
LVS:软件,运行在操作系统的内核态,可对TCP请求或更高层级的网络协议进行转发,因此支持的协议更多,并且性能也高于Nginx,LVS属于单机版软件,需要做主备高可用架构,以防一个节点宕机.
F5:一种负载均衡硬件,价格昂贵.
7.第七次架构优化:通过DNS轮询实现机房的负载均衡.
在DNS服务器中配置一个域名对应多个IP地址,每个IP地址对应不同机房中的虚拟IP,当用户访问网站的域名时,DNS服务器会使用轮询或者其他策略,来选择某个IP给用户提供访问,此方式就是实现了机房间的负载均衡.
8.第八次架构优化:容器化+微服务架构(此架构也可以从一开始就做).
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！