Redis总结汇编

Redis内存使用优化与存储
作者 田琪 发布于 2011年8月16日

总结：

1    根据业务需要选择合适的数据类型，并为不同的应用场景设置相应的紧凑存储参数。
2    当业务场景不需要数据持久化时，关闭所有的持久化方式可以获得最佳的性能以及最大的内存使用量。
3    如果需要使用持久化，根据是否可以容忍重启丢失部分数据在快照方式与语句追加方式之间选择其一，不要使用虚拟内存以及diskstore方式。
4    不要让你的Redis所在机器物理内存使用超过实际内存总量的3/5。



Redis 常见的性能问题和解决方法
作者：nosqlfan on 星期三, 七月 4, 2012

总结：

1    Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
2    如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3    为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
4    尽量避免在压力较大的主库上增加从库
5    为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3…….，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变。



Redis几个认识误区
Saturday, Dec 4th, 2010 by Tim

Redis不可能比Memcache快

很多开发者都认为Redis不可能比Memcached快，Memcached完全基于内存，而Redis具有持久化保存特性，即使是异步的，Redis也不可能比Memcached快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因，目前想到的原因有这几方面。
1    Libevent。和Memcached不同，Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis使用另外一个libevent高性能替代libev，但是作者还是坚持Redis应该小巧并去依赖的思路。一个印象深刻的细节是编译Redis之前并不需要执行./configure。
2    CAS问题。CAS是Memcached中比较方便的一种防止竞争修改资源的方法。CAS实现需要为每个cache key设置一个隐藏的cas token，cas相当value版本号，每次set会token需要递增，因此带来CPU和内存的双重开销，虽然这些开销很小，但是到单机10G+ cache以及QPS上万之后这些开销就会给双方相对带来一些细微性能差别(5)。



Redis入门教程
分类： SQL/noSQL 2010-07-29 16:52

2.Redis的性能

下面是官方的bench-mark数据：
    The test was done with 50 simultaneous clients performing 100000 requests.
    The value SET and GET is a 256 bytes string.
    The Linux box is running Linux 2.6, it’s Xeon X3320 2.5Ghz.
    Text executed using the loopback interface (127.0.0.1).
    Results: about 110000 SETs per second, about 81000 GETs per second.
更多详细数据请见官方bench-mark page（http://code.google.com/p/redis/wiki/Benchmarks）