Redis如果使用32bit进行编译，内部所有数据结构所使用的指针空间占用会少一半。
【ziplist】
如果Redis内部管理的集合数据结构很小，它会使用紧凑存储形式压缩存储。
Redis的ziplist是一个紧凑的字节数组结构，协议如下图所示：
这种结构下，如果是存储hash结构，那么key和value会作为两个entry被相邻存储。
如果存储的是zset结构，那么value和score会作为两个entry被相邻存储。
【intset/hashtable】
Redis的intset是一个紧凑的整数数组结构，用于存放元素都是整数且元素个数较少的set集合。
如果整数可以用uint16(无符号16位)表示，那么intset的元素就是16位的数组，如果新加入的整数超过了uint16的表示范围，那么就用uint32表示...Redis支持set集合动态从uint16升级到uint32，再升级到uint64。
如果set里存储的是字符串，那么sadd立即升级为hashtable结构。
【小对象的界限】
hash-max-ziplist-entries 512 # hash的元素个数超过512就必须用标准结构存储
hash-max-ziplist-value 64 # hash 的任意元素的key/value的长度超过64就必须用标准结构存储
list-max-ziplist-entries 512 # list 的元素个数超过512就必须用标准结构存储
list-max-ziplist-value 64 # list的任意元素的长度超过64就必须用标准结构存储
zset-max-ziplist-entries 128 # zset的元素个数超过128就必须用标准结构存储
zset-max-ziplist-value 64 # zset的任意元素的长度超过64就必须用标准结构存储
set-max-intset-entries 512 # set的整数元素个数超过512就必须用标准结构存储
【内存回收机制】
如果当前Redis内存有10G，当你删除了1G的key之后，再观察内存会发现内存变化不会太大。原因是OS是以页为单位来回收内存的，这个页上只要还有一个key在使用，那么就不能被回收。Redis虽然删除了1G的key，但是这些key分散在了很多页面中，每个页面都还有其他key存在，导致内存不会被立即回收。其实这就像叠叠乐游戏，抽取了多个积木之后，整体占用的空间并不会减少。
但如果执行flushdb，然后再观察内存，会发现内存确实被回收了。原因是所有的key都被干掉了，大部分之前使用的页面都干净了，就会立即被OS回收。
【内存分配算法】
内存分配需要适当的算法划分内存页，考虑内存碎片，需要平衡性能和效率。
Redis目前的内存分配细节是依赖于第三方内存分配库，Redis默认使用jemalloc，也可以切换到tcmalloc。
使用info memory可以查看redis的内存信息。
【参考】
《Redis深度历险 核心原理与应用实践》