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

新书Java并发编程系统与模型已上线，欢迎拜读。

       一个日均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库下面，查看下面这些表：

innodb_trx         ## 当前运行的全部事务
innodb_locks       ## 当前出现的锁
innodb_lock_waits  ## 锁等待的对应关系
以及SHOW ENINGE INNODB STATUS来查询INNODB的状态与死锁信息。复制代码

故障排查

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

小广告

新书《Java并发编程系统与模型》目前已经写完一部分。可是实际上说实话，并不知道读者们对java并发系统有哪些比较关心的，并且闭门造车实在是太累，写出来怕没人看。因此我放在这里征求你们的意见。你们能够直接在评论里提问或者但愿做者重点描写哪一部份内容，我好有针对性的写。