日均PV千万的后台是如何形成的

admin

       一个日均PV在千万以上的移动客户端，大概有20w-50w的注册用户数。为了简单起见,将一次PV来代表一次Http请求。在移动客户端下，这些是纯逻辑的，不包含静态页面的访问和图片的访问。

并发量

       并发量的计算公式是pv/时间。无论是再复杂的请求平均响应时间在1秒以内，如果超过的1秒，那么就说明需要调优或者重新设计当前的业务系统。一天一共是86400秒，那么每秒支持的并发数为100左右，也就是每秒大概100个并发。

服务器配置

       服务器是两台32G内存的8核处理器。其中一台服务安装上Niginx来做分发，另一外一台服务安装上Redis来缓存。每台服务器都安装了Tomcat8。

Redis

       Redis由于是走内存，所以基本上都是毫秒级响应。使用Redis，基本上80%的请求可以在缓存中直接获取。剩下的20%Mysql完全可以支撑住。可以缓存热点数据，甚至是直接缓存结果。但是缓存结果的时候要注意，只缓存正确的结果。曾经我犯过这样的错误，将错误的结果缓存起来了，结果明明BUG已经修复，还是显示错误的页面，排查了问题好久，结果就是Redis将错误的结果也缓存了。没必要对Redis做伪集群处理，单机的Redis其实在千万级的PV下都是小case。

日志

       日均PV千万的系统，Tomcat的 access_log每天产生大概2g多的日志。tomcat追加2g多的日志是很快的，基本上都是毫秒级响应，要注意监控，因为每天2G多的日志一个月下来就可能将服务器的资源占满。所以要定时清理，可以写一个shell脚本定时清理前一个月的日志。

Mysql

       一定要注意加索引和慢查询（无论是阿里云还是腾讯云都提供慢查询的工具。可以清楚的看到是哪些sql导致了慢查询）。1千多万条记录，1G多。索引大概7八百兆。update：2秒多左右。insert1秒多，目前还没有分表，Mysql单表三千万的记录示处理起来没有丝毫障碍。

不要使用事务

       在高并发的情况下不要使用事务。避免出现锁等待。Spring的事务注解@Transactional慎用。如果不指定rollbackFor=Exception.class，将会出现事务一直running，导致事务无法释放或者事务根本无法提交，这些未提交的事务由于一直占用锁，那么其他sql一直锁等待，导致更新数据失败（血淋淋的教训）。在Mysql 5.5版本以后，如果要查看mysql锁相关的情况，到information_schema库下面，查看下面这些表：

1. innodb_trx         ## 当前运行的所有事务
   
2. innodb_locks       ## 当前出现的锁
   
3. innodb_lock_waits  ## 锁等待的对应关系
   
4. 以及SHOW ENINGE INNODB STATUS来查询INNODB的状态与死锁信息。

复制代码

故障排查

到了日均PV千万，故障排除是重点。一旦线上出问题，影响面是相当广的。由于日志分布在多个机器上，如果线上出现问题，挨个机器排查日志是一件很痛苦的事情。所以，构建好的监控系统是重点，推荐使用ELK构建一个快速的错误日志查询系统。

https://gold.xitu.io/post/58a158261b69e60059d3f524