后台服务后台遇到的坑整理，以及做活动的优化经历,redis需要读写分离吗以及其他问题

因为去年做活动主要是H5活动比较多，运营环节在观察

选型：

nginx, springboot, java8, redis, (mysql)

nginx做动静分离和集群分发

spring boot提供app容器，简化配置，快速开发

java8 提供函数编程

redis 丰富的数据结构和数据持久化

mysql 缺省redis的情况下使用，之后弃用。

服务器改为 localCache->Redis。后来直接把mysql去掉。因为Redis丰富的数据结构完全胜任各种活动的要求和特点

运营环节排除的错误有

a.数据库的链接使用了外网地址，造成访问性能极低。

b.使用jedis,redis连接池而不是直接用spring的redisTemplate,读写性能提高100%。

c.客户端的过场动画机制，加载完或者4秒后隐藏过场动画，结果加载完并没有触发隐藏，导致用户体验差。这是运营起见观察多次后来才终于找到了这个bug。

d.图片少访问量多的功能页面使用base64将图片直接写入html

e.使用本地缓存，减少日志输出

f.将统计数据等操作放入队列，队列在进程的子线程处理。防止缓存访问超时造成服务不可用，并且节约线程。

g.微信授权的接口，前端不但要将授权的openid缓存下来，节约每一次远程访问第三方的接口。因为获取微信用户信息要访问好多个微信API，每个几十毫秒，这个在活动高峰的时候用户体验影响很大。

最后控制接口访问的时间大部分在1ms内

后来的设想是将一个redis从库部署到阿里云上，然后redis主从读写分离，写在主，读在阿里云的从，并用阿里的DataManager来监控redis性能。这也主要是便于熟悉redis的性能瓶颈和便于监控。

后来这个想法没有实施，原因

①是考虑到redis是内存数据库，不存在IO瓶颈，读写都很快。

②是即使用redis从库分担从库持久化的IO压力，但是很明显网络IO比磁盘IO更慢。

并发压力大的时候，应该用redis集群。

遇到的其他问题：

1.有的Linux环境会清除temp临时 文件夹，导致文件上传找不到路径，需要启动的时候执行spring boot的文件路径