分布式缓存Redis之内存优化

写在前面

  本学习教程所有示例代码见GitHub：https://github.com/selfconzrr/Redis_Learning

  Redis作为内存数据库，所有数据都从内存中拿，省去读写磁盘的消耗（持久化是由fork子进程处理，主服务对外能力不受影响），响应速度极快。但我们不可能将所有的数据都读到内存中，所以内存资源显得非常可贵，我们就要优化存储结构，使得好钢用在刀刃上。

一、尽量使用hash

  COC中每个客户会对应上千个标签，每个客户就是一个对象，我们如何存储它？

存储结构比较：

1. 序列化对象：要求在redis存储前对象进行序列化操作，每次取出后还要执行反序列化操作，开销太大；如果只想取对象的某一个值，都需要将整个对象取出，还要解决并发、数据一致性、加锁等复杂问题。
2. K-V模式: phone字段冗余；
3. HASHMAP: phone字段只出现一次，避免数据冗余。

内存优化效果：

  前提假设COC有1千万用户对象，每个用户对象有1000个标签，Redis存储的phone_no格式为185XXXXXXXX。根据ASCII编码，每位数字占用单字节字符，每个phone_no占用11Byte。K-V结构中，存放一个完成对象，每个phone_no需要重复1000次，所以存放1千万个对象phone_no为1000*1千万，所占空间为：

1000次*10000000个*11B/1024/1024=102.45G

二、根据业务场景，考虑使用BITMAP

  前面我们在学String的时候提到过两个命令：setbit key offset 0/1 和 getbit key offset，这两个命令是在位上进行0/1赋值和取值。假设还是1000W用户，每个用户有1000个0/1标签，我们可以使用bitmap来存放这些数据：

  所有标签总占用的内存为：0.000119MB*1000W=1.19GB,如果使用key-value结构（包括hashes），内存占用至少是它的8倍。

BITMAP使用总结：

1. 只适合01型标签；
2. 需要位移位与标签的字典表，属于额外开销，但相对而言字典表offset数字可共享redis数字池，比直接存字符串要省空间。
3. 牺牲时间换空间：维护字典表；入库需要对应转化；出库计算也需要转换。

三、其他：

  Redis提供内存回收策略，根据使用的情况可以选择适当的回收策略，比如过期数据清除，expire设置数据过期时间；

  Redis提供内存共享策略，服务器启动时，会自动创建0-9999的数字对象，其他地方使用，可以直接引用。

  本质：对内存的操作，其实是在每一个redis对象结构内都有一个count的属性，该属性记录了这个对象被引用的次数，如果为0，那么在内存回收时将回收该空间。

—–乐于分享，共同进步
—–Any comments greatly appreciated
—–诚心欢迎各位交流讨论！QQ:1138517609