前后端架构设计

一、前端高可用架构设计

用户请求——>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读请求，基本上可以勉强把压力给抗住。