高并发下生成唯一日志ID需要考虑较多，不然一定会出现重复的情况。之前我有一篇文章里有涉及过这个：http://www.04007.cn/article/202.html 里面有百度的框架中生成的唯一请求日志ID，其日志ID比较短，只是在一段时间内不重复，具体可以看那篇文章。日志ID在我看来也应该有规范，我觉得唯一请求日志ID应该有以下几个特点：  1：肯定是唯一的，上面百度的日志ID虽然隔段时间会重复，但如果日志只保存较短的时间的话，也可认为是维一的。  2：我觉得既然是ID，那就应...[>>…]

    天对公司的业务上的nginx+lua签名验证系统进行了改造，优化了原有的流程，在这个基础上我就想把一台服务器在原有的nginxproxy服务器的基础上进行优化，因为后期我将要对原来的几台proxy服务器进行改动，也算是提前先处理下，但是在处理的时候就碰到了问题了。当前的服务器与proxy的一个差别就是proxy上多安装了一个nginx模块：nginx_upstream_check_module。所以我需要将现在的这个服务器上的nginx扩展安装，但一看原来的解压包等各module下载后的压缩包我都没有权限（属于运维人员的），于...[>>…]

    nginx可做反向代理，但nginx并不知道后端的业务是否可用，如果后端服务器宕机的话，nginx自身并不能把这台realserver踢出upstream，这时就需要一个检查后端服务器的机制。nginx第三方模块nginx_upstream_check_module就可以做这样的事：检查后端服务器的健康情况。    nginx_upstream_check_module是淘宝技术团队开发的nginx第三方模块，如果后端服务器不可用，则所以的请求将不会转发到这台服务器。    nginx_upstream_check_module模块的github地...[>>…]

    这个方法之前在测试环境中使用时一切安好，但放上线上后发现经常502，因为只是一个调试模块，不影响线上业务，也没去认真研究。今天想想真是奇怪，就准备拿来研究一下，这篇文章肯定不可能把这个问题说全，因为涉及的其它地方太多我也没办法贴出来，贴点代码吧，算是为这个匪夷所思的问题立个碑。  PHP代码如下： //一个方法 publicfunctionhistorycards() { $data=array(); //取得redis里的数据 $val_history=array(); $redisKey="history_cards"; $val_history=(array)$this-&g...[>>…]

    之前没有碰到这个小问题，习惯了判断数组中有没有某个键值时，总是用isset($array[$key]).但今天在测试一个项目时发现这个判断离奇地不起作用了。影响代码：if(isset($array[$key]))unset($array[$key]));    就是这么一句简单的代码，作用是避免将这个字段抛到接口层。后来发现这个数据从数据库里取出来，其值为null；其实我非常讨厌null这个东西，因为总会有奇怪的事情发生。但是后端内容控制后台是别的同事开发，我也提过null这个东西，但人家就那样。得了吧，我们就...[>>…]

Redis配置文件中不常关注的配置项意义大全: #GENERAL include/path/to/other.conf#包含其它的redis配置文件 unixsocket/tmp/redis.sock#指定监听的socket，适用于unix环境 timeoutN#客户端空闲N秒后断开连接，参数0表示不启用 loglevelnotice#指定服务器信息显示的等级，4个参数分别为debugverbosenoticewarning syslog-enabledno#是否启用将记录记载到系统日志功能，默认为不启用 syslog-identredis#若启用日志记录，则需要设置日志记录的身份 syslog-facilitylocal0#若启用日志记录，则需要设置日志facility，可取...[>>…]

    先看一下redis进行主从连接后主库和从库的日志记录，以下是从库启动后连接主库的日志： 7775:S13Jun11:46:03.173#Serverstarted,Redisversion3.2.8 7775:S13Jun11:46:33.665*DBloadedfromdisk:30.492seconds 7775:S13Jun11:46:33.665*Theserverisnowreadytoacceptconnectionsonport6379 7775:S13Jun11:46:33.666*ConnectingtoMASTER192.168.168.68:7379 7775:S13Jun11:46:33.666*MASTER<->SLAVEsyncstarted 7775:S13Jun11:46:33.666*NonblockingconnectforSYNCfiredtheevent. 7775:S13...[>>…]

    突然收到服务器报警，看了一下程序日志，redis读取数据时报错UncaughtRedisException:RedisisLOADINGthedataset，这块业务的redis架构是1主3丛，通过对主库的info信息查看，发现从库有时直接显示down.而在服务器的表象上，主从链接也会每隔1分钟左右就断开一次，导致需要重新同步，主库上看到每隔一分钟主库就会进行一次bgsave操作。查看主库日志如下： 26543:M10Jun00:48:21.566*Slave192.168.168.90:9736asksforsynchronization 26543:M10Jun00:48:21.566*Fullresyncrequestedbyslave192.1...[>>…]

    redis的info命令得到的信息量非常大，必须要好好掌握。以下是收集的redis3.2.8版本中执行info后的所有数据意义说明。另外info命令可以通过给定可选的参数section，可以让命令只返回某一部分的信息：以下是info命令数据意义详解： #Server部分 redis_version:3.2.8#Redis服务器版本 redis_git_sha1：00000000#GitSHA1 redis_git_dirty:0#Gitdirtyflag redis_build_id:272f1rd31e4e1a#redisbuildid redis_mode:cluster#运行模式，单机standalone或者集群cluster os:Linux2.6.32-358.2.1.el6.x8...[>>…]

    在我们的业务redis中，因为redis服务器只是做数据缓存用，没有必要做数据备份，所以没有必要做持久化，redis的配置文件中我们都是配置的不做持久化。配置如下： #Itisalsopossibletoremoveallthepreviouslyconfiguredsave #pointsbyaddingasavedirectivewithasingleemptystringargument #likeinthefollowingexample: save"" #save9001 #save30010 #save6010000     另外，我们的redis是主丛结构，如果不是主从模式，是不会出现这样的问题的，线上运行时我在查看redisinf...[>>…]