redis读书笔记

1、redis & redis-cluster的开发计划
Redis的开发Antirze最近不知道受了什么刺激,接连发布了一些redis和redis cluster的开发计划信息。
首先,在巴塞罗那的talk上说(NoSQL Matters Bacelona , redis cluster design tradeoffs),“we’ll go stable Q1 2015”。作者已经跳票多次,不知道是否可信,@@
接着,前几天Antirze最近在twitter上发布了5个关于redis的开发改变:
1)redis-dev list和“get help” list分开、方便开发讨论
2)redis在github上接收change proposals,github.com/redis/redis-rcp
3)antirez本人会每周至少有两次事件去处理Issues/PRs.
4)开发模型改变,三个分支:stable/testing/unstable。每年至少4个stable releases。
5)new features不再跨版本back porting,定期merge到unstable

2、Multi-Users Redis Auth And ACL
作者在github上新不发布了一个关于auth&acl proposal
Antirze准备让redis支持更强大的Auth功能,对不同的用户进行不同的权限认证和访问控制。
这种支持无疑是增加redis的数据安全。比如下面的readonly、write、slow、admin权限控制非常精确,也很实用。
虽然AUTH和ACL的增强很令人期待,但是我还是存在一些疑问的地方:
1)口令认证会降低redis的性能。在我的测试中,短连接方式下是用密码,redis的性能越有10%的性能下降(吞吐量和QPS)。
在我们的一些高流量系统中,比如实时推荐的系统的redis,每秒的commands约6w+,10%的性能损失还是挺大的。
2)密码管理和ACL管理对redis来说也是个很头疼的事情。mysql起码可以把密码、权限都放在mysql.user等相关的数据表里面,很容易方便管理。
redis那只能把这些权限数据放到磁盘文件上面了,而且还需要定期的备份auth数据,防止这些数据丢失。
#readonly — All the non administrative read only commands.
#write — All the non administrative write commands.
#slow — #readonly and #write commands with a time complexity greater than log(N).
#admin — Administrative commands (CONFIG, SHUTDOWN, BGSAVE, …).
#list — List type commands (RW).
#set — Set type commands (RW).
#zset — Sorted Set type commands (RW).

3、最近看到的一些redis的博文,关于redis的使用经验
redis越来越被许多开发所喜欢,最近也看到了多篇redis在各个公司的是用经验。
3.1 Techu Search提供实时索引和搜索的技术的公司,他们是用redis实现不同的功能。
How Techu leverages redis
主要的使用场景:
1)request throttling,用INCR命令实现限速,避免恶意访问。
2)request metrics per tyoe,请求类别计数
3)search/excerpts request cacheing,搜索/摘要的请求缓冲
4)indexing request queueing,作为索引请求队列

3.2 first-time-ceo,介绍了一些redis的基本用法。
博文::Redis: Storing time-series data in a sorted set
1)利用sorted set的member的唯一性,unix timestamp作为事件score排序。
2)使用lua脚本生成唯一的member。
博文:Redis:Building an index with a Set:
作者主要使用set索引数据,模拟索引。

4、tomcat-redis-session-manager
Redis-backed non-sticky session store for Apache Tomcat。基于redis的非粘滞的session存储方案,也就我们通常说的共享session。
以redis作为存储并实现redis的HA方案,那么整个网站的session系统就很稳定了。我们实现了redis + keepalived的方案,也在准备上线twemproxy + redis/mc的方案。twemproxy方式使用一致性hash,会丢失1/n的session数据,也就这一部分用户在发生故障时需要重新登录。

此条目发表在redis分类目录,贴了, 标签。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.