对投票数据统计的时候发现了Redis Hash类型的一个大坑，单个key中field过多，导致取不出来。特记录下尝试解决和探索的过程。
第一阶段：问题描述
一个投票类的产品，对单个选项mid投票成功后，记录了总票数，还记录了用户投票日志(可以理解成投票明细)，用的都是Redis Hash类型来存储。投票日志的存储格式如下：
$redis->hset('vote_log', 'uid|mid|timestamp', 1);
最近，运营需要统计固定时间段每个选项投票的用户数，要的比较急，就很快写了一个脚本
算法：
继续阅读
从“晓说”，到“晓松奇谈”，再到“矮大紧指北”；从大四，到工作两年，再到工作五年。从在北京没有窗户的隔断到带阳台和卫生间的卧室。
每个周六不听听高老师的声音，似乎都觉得生活缺少了点什么。而“矮大紧指北”的出现，似乎每天都有意无意的听到高老师的声音。
结束了一天的工作，夜幕下，骑着自行车，周围车水马龙，耳机里习惯性的想起高老师的指北，差不多听完的时候也就到家了，那种幸福，简直是一天的发光时刻。
继续阅读
好久没有关心博客了，今天发现用的还是这种带问号的地址（http://niliu.me/?p=200）。之前也就是知道这种地址对SEO不友好，今天查了一些资料对比了下，所谓的不友好是指搜索引擎会对这种网址降权，因为这种地址参数变（参数可以随便加），而内容不变。
我们当然希望我们的文章可以被更多的人通过搜索引擎查询到，那就需要重写这个地址，一般使用WEB服务器提供的rewrite模块就可以了（比如Nginx的ngx_http_rewrite_module），通过修改配置文件，增加规则，重新映射地址, Nginx的rewrite语法如下：
上篇文章《用户互动数据排序中数据归一化的必要性探讨》的结尾提到归一化后的数据存储到Redis sorted sets中是否对数据读写有影响，查了相关资料，推导的结论是没有影响。
这里简化描述问题，用Redis实现投票排行榜TOP3，Option1票数100，Option2票数100000，Option3票数10000000
zadd vote_rank 100 'Option1' 100000 'Option2' 10000000 'Option3'
对数据min-max归一化处理后得到数据分别是0, 0.0099901, 1
最近在工作中看到了基于用户互动数据排序的两种实现思路，一种是“分权加和”，直接根据权重来计算数值，另一种在第一种的基础上对数据做了归一化处理。当然两种方式都是没问题的，毕竟都经过线上的验证。
做了归一化处理，看似更科学、更严谨，既然不做也可以，那么归一化处理到底有没有好处，是不是有必要呢？
下面首先具体展开描述下两种方式，给有需要的读者一个参考。
这是之前在CSDN上的一些记录，点击进入
loading…
man curl 是这么描述的curl is a tool to transfer data from or to a server.
简单说就是一个文件传输(上传、下载)工具。
很多同学会发现当去curl –help的时候会吐出来好几屏参数，不单单是英语的问题（如果是英文的问题可以移步到linux curl 命令详解，以及实例 – 海底苍鹰(tank)博客翻译的还是很全面），只能说功能很丰富。当然阮一峰的整理对于入门了解也是很推荐的curl网站开发指南- 阮一峰的网络日志。
很多时候要跟踪一些很紧急的故障，打开Manual查看确实很让人抓狂。
curl -x 123.57.156.244:80 -sv -o /dev/null -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" http://ip.taobao.com/service/getIpInfo.php?ip=115.183.85.158
-v显示一次http通信的全过程，有端口连接和http request header信息
-s是静默模式不输入任何东西，-sv不显示连接的时间，request header还是会显示。
这个国庆参加完同学的婚礼2号回来，哪也没去，去了马孔多。
马孔多是一个二十户人家的村落，泥土和芦苇盖成的屋子沿河岸排开，湍流的河水清澈见底，河床里卵石洁白光滑宛如史前巨蛋。导游马尔克斯这样跟我开场，其他的什么都没说。