一、前端高可用架构设计
用户请求——>DNS域名解析(轮询)——>Nginx虚拟ip(keepalived监测心跳)——>tomcat服务
DNS轮训缺点:
a.只负责IP轮询获取,不保证节点可用
b.DNS IP列表变更有延时
c.外网IP占用严重
二、后端高并发架构图
一、千万级用户量压力预估
预估客户数量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读请求,基本上可以勉强把压力给抗住。