今天在部署python代码到预生产环境时，web站老是出现redis链接未初始化，无法连接到服务的提示，比对了一下开发环境与测试环境代码，完全一致，然后就是查看各种日志，排查了半天也没有查明是什么原因引起的。
没有办法的情况下，直接登录服务器，从uwsgi与nginx中卸载掉这个web服务，然后暴力的在命令操作符下输入python main.py，执行访问发现又正常了......狂吐血400CC...然后是各种怀疑uwsgi和nginx，查看配置与其他服务正常，排除完后只能回归到检查代码。
静下心来查看优化过后的代码，发现为了保持redis只有一个长链接，在web服务主程序启动时会对redis模块进行一次初始化，在代码中用global将redis链接设置为静态全局变量，redis链接只需要初始一次
# 初始化Redis缓存链接 r = None def set_redis_config(_redis): """ 设置redis配置参数 :param _redis: redis配置参数 """ global r # 初始化Redis缓存链接 try: if not r: r = redis.Redis(host=_redis.get('server', ''), port=_redis.get('post', ''), db=_redis.get('db', ''), password=_redis.get('pwd', ''), socket_timeout=1, socket_connect_timeout=1) log_helper.info('初始化redis缓存链接') except: pass
然后将初始化代码改变地方，放在勾子里，再次启用uwsgi与nginx服务，运行终于正常了。
找了朋友问问得知，原来uwsgi是多进程服务，听了后心里比较担心，会不会因为多进程关系使global失效，造成改造后长链接过多使redis服务崩溃了，马上使用jmeter进行了压力测试，压了300个并发跑了一段时间，连上redis服务输入client list命令，查看已链接的客户端列表，发现没几个，打开日志发现在高并发时，初始化代码执行的并不多，也就是说使用uwsgi虽然造成了redis长链接需要经常创建，但global还是起到了一定的作用，没有产生很差的结果。
由于redis要经常重新创建链接，担心它会影响性能所以对其中一个接口进行改造，一个使用redis读取数据，另一个直接读取postgresql数据库，然后对两个接口通过手动刷新页面方式进行反复访问后，查看接口日志占用的时间，发现刷新慢时，使用redis方式会占用比较多时间，而访问非常频繁时，反复调用一个长链接的机会会多很多，影响不大，两种方式访问的效果差不多。
当然和没有使用uwsgi的开发环境与测试环境对比来看，redis要经常创建新链接会占用一定的开销，影响了部分性能。暂时还没有想到好的解决办法，先记录一下，以后有时间再尝试用其他方式测试看看效果。
