- 内存占用情况：最近几天内存中的数据量一直维持在6-9万左右，内存占用在20-30M之间。当数据批量清理后内存用量有些许下降（比如session过期清理）。
- 读写效率情况：通过redis自带的统计工具来看，正常业务平均每秒钟使用redis的数量在几十次到上百次之间；当session清理时达到700次以上(瓶颈是清理session的算法而非redis)，系统负载没有明显波动，当session清理时达到极限使用情况，系统负载在0.20左右。另，在上线前的压力测试中，在wap服务器这样的环境里，redis每秒钟完成的读和写都是4-5w，比官方的数据小很多（10万级），估计还有比较大的优化空间。
- jredis客户端：遇到一个bug，当tomcat应用正常运行，而redis重启时（仅在测试环境尝试重启），jredis连接池的重连功能会出问题：尝试在短短的1秒内大量重试，而之后再也不重试了。这样即便后来redis重启完毕，jredis也不再连接redis了。解决方法是在jredis上做封装时，增加一个reload方法，当redis服务由于不可抗力中断并恢复之后，通过一个jsp调用reload方法，手工通知jredis重新加载连接。而传说中的jredis会泄漏连接的bug并没有构成威胁，通过观察，redis客户端连接始终保持在一个稳定的数值(在wap服务器上是50)。
- 在内网的另一台机器上部署了另一个redis作为slave，虽然redis的同步很频繁，但是和部署备份前相比，没有感觉到负载的上升。具体压力数据有待测试。但直观上感觉，如果像mysql的slave一样，牺牲掉10%以内的请求时间即可完成slave，对服务来说应该是值得的。
- 一个小tip：在set数据之后一定记得随手给这个数据设置过期时间。前几天多亏明飞同学review了我的session清理代码，发现了一个垃圾泄漏的bug；侥幸的是wap这里所有的set都设置了过期时间，那些泄漏掉的垃圾在一段时间后还是会被redis回收，没有成为真正的太空垃圾。
- 另，接上一个问题，redis适合存储临时的、频繁使用的数据；并不适合存储需要长期保存的、逻辑性强的数据。而像wap这样的服务又不想让代码过于复杂（比如spring+hibernate+struts），所以也许我们还需要另一个数据服务，来保存那些有逻辑的、需要长期保存的数据；而且这个数据服务最好是比hibernate简单很多的、独立于业务逻辑代码的（最好不需要配置OR-mapping）、高效的。
Jun
12