前后端架构设计

一、前端高可用架构设计

前后端架构设计_第1张图片

用户请求——>DNS域名解析(轮询)——>Nginx虚拟ip(keepalived监测心跳)——>tomcat服务
DNS轮训缺点:
a.只负责IP轮询获取,不保证节点可用
b.DNS IP列表变更有延时
c.外网IP占用严重

二、后端高并发架构图

前后端架构设计_第2张图片

一、千万级用户量压力预估

预估客户数量1000万,根据28法则活跃用户200万,假设平均每个用户有30次点击,共计6000万点击(pv)。
每天24小时,根据28法则,每天最活跃的用户集中在(24小时0.2)约5小时内,而大部分用户的点击量为(6000万0.8)约5000万。大概每秒钟3000的请求量,这5小时中又会出现高峰访问,一般高峰访问是活跃访问的2~3倍,假如我们按照3倍计算,那么5小时内短暂的访问峰值是10000左右的请求。

二、服务器压力预估

高峰期1万的请求量,一个tomcat预估支撑500个请求,需要部署20台应用服务。而应用服务对数据库的访问量又是要翻倍的。因为假设一秒钟应用服务器接收到1万个请求,但是应用服务器为了处理每个请求可能要涉及到平均3~5次数据库的访问。

按照3次数据库访问来算,那么每秒会对数据库形成3万次的请求。

按照一台数据库服务器最高支撑每秒5000左右的请求量,此时需要通过6台数据库服务器才能支撑每秒3万左右的请求。

图片服务器的压力同样会很大,因为需要大量的读取图片展示页面,这个不太好估算,但是大致可以推算出来每秒至少也会有几千次请求,因此也需要多台图片服务器来支撑图片访问的请求。

三、分布式缓存抗下读请求

但是目前上述系统架构中压力最大的,其实是数据库层面 ,因为估算出来可能高峰期对数据库的读写并发会有3万左右的请求。

此时就需要引入分布式缓存来抗下对数据库的读请求压力了,也就是引入Redis集群。

一般来说对数据库的读写请求也大致遵循28法则,所以每秒3万的读写请求中,大概有2.4万左右是读请求

这些读请求基本上90%都可以通过分布式缓存集群来抗下来,也就是大概2万左右的读请求可以通过 Redis集群来抗住。

我们完全可以把热点的、常见的数据都在Redis集群里放一份作为缓存,然后对外提供缓存服务。

在读数据的时候优先从缓存里读,如果缓存里没有,再从数据库里读取。这样2万读请求就落到Redis上了,1万读写请求继续落在数据库上。

Redis一般单台服务器抗每秒几万请求是没问题的,所以Redis集群一般就部署3台机器,抗下每秒2万读请求是绝对没问题的。

四、基于数据库主从架构做读写分离

此时数据库服务器还是存在每秒1万的请求,对于单台服务器来说压力还是过大。

但是数据库一般都支持主从架构,也就是有一个从库一直从主库同步数据过去。此时可以基于主从架构做读写分离。

也就是说,每秒大概6000写请求是进入主库,大概还有4000个读请求是在从库上去读,这样就可以把1万读写请求压力分摊到两台服务器上去。

这么分摊过后,主库每秒最多6000写请求,从库每秒最多4000读请求,基本上可以勉强把压力给抗住。

你可能感兴趣的:(java,java)