具有设计感的网站,兰州网络seo公司,饮品店网站模板,网站开发什么时候用缓存业务场景中经常会有各种大key多key的情况#xff0c; 比如#xff1a;1#xff1a;单个简单的key存储的value很大2#xff1a;hash#xff0c; set#xff0c;zset#xff0c;list 中存储过多的元素#xff08;以万为单位#xff09;3#xff1a;一个集群存储了上亿的…业务场景中经常会有各种大key多key的情况 比如1单个简单的key存储的value很大2hash setzsetlist 中存储过多的元素以万为单位3一个集群存储了上亿的keyKey 本身过多也带来了更多的空间占用如无意外文章中所提及的hashset等数据结构均指redis中的数据结构 由于redis是单线程运行的如果一次操作的value很大会对整个redis的响应时间造成负面影响所以业务上能拆则拆下面举几个典型的分拆方案。1单个简单的key存储的value很大 i该对象需要每次都整存整取可以尝试将对象分拆成几个key-value 使用multiGet获取值这样分拆的意义在于分拆单次操作的压力将操作压力平摊到多个redis实例中降低对单个redis的IO影响 ii该对象每次只需要存取部分数据可以像第一种做法一样分拆成几个key-value 也可以将这个存储在一个hash中每个field代表一个具体的属性使用hget,hmget来获取部分的value使用hsethmset来更新部分属性 2value中存储过多的元素类似于场景一种的第一个做法可以将这些元素分拆。以hash为例原先的正常存取流程是 hget(hashKey, field) ; hset(hashKey, field, value)现在固定一个桶的数量比如 10000 每次存取的时候先在本地计算field的hash值模除 10000 确定了该field落在哪个key上。newHashKey hashKey ( set, zset, list 也可以类似上述做法但有些不适合的场景比如要保证 lpop 的数据的确是最早push到list中去的这个就需要一些附加的属性或者是在 key的拼接上做一些工作比如list按照时间来分拆。3一个集群存储了上亿的key如果key的个数过多会带来更多的内存空间占用ikey本身的占用每个key 都会有一个Category前缀ii集群模式中服务端需要建立一些slot2key的映射关系这其中的指针占用在key多的情况下也是浪费巨大空间 这两个方面在key个数上亿的时候消耗内存十分明显Redis 3.2及以下版本均存在这个问题4.0有优化所以减少key的个数可以减少内存消耗可以参考的方案是转Hash结构存储即原先是直接使用Redis String 的结构存储现在将多个key存储在一个Hash结构中具体场景参考如下key 本身就有很强的相关性比如多个key 代表一个对象每个key是对象的一个属性这种可直接按照特定对象的特征来设置一个新Key——Hash结构 原先的key则作为这个新Hash 的field。举例说明 原先存储的三个key user.zhangsan-id 123; user.zhangsan-age 18; user.zhangsan-country china; 这三个key本身就具有很强的相关特性转成Hash存储就像这样 key user.zhangsanfield:id 123; field:age 18; field:country china;即redis中存储的是一个key user.zhangsan 他有三个 field 每个field key 就对应原先的一个key。 key 本身没有相关性预估一下总量采取和上述第二种场景类似的方案预分一个固定的桶数量 比如现在预估key 的总数为 2亿按照一个hash存储 100个field来算需要 2亿 / 100 200W 个桶 (200W 个key占用的空间很少2亿可能有将近 20G )原先比如有三个key user.123456789 user.987654321user.678912345现在按照200W 固定桶分就是先计算出桶的序号 hash(123456789) % 200W 这里最好保证这个 hash算法的值是个正数否则需要调整下模除的规则这样算出三个key 的桶分别是 1 2 2。 所以存储的时候调用API hset(key, field, value)读取的时候使用 hget key field 注意两个地方1hash 取模对负数的处理 2预分桶的时候 一个hash 中存储的值最好不要超过 512 100 左右较为合适4大Bitmap或布隆过滤器Bloom 拆分使用bitmap或布隆过滤器的场景往往是数据量极大的情况在这种情况下Bitmap和布隆过滤器使用空间也比较大比如用于公司userid匹配的布隆过滤器就需要512MB的大小这对redis来说是绝对的大value了。这种场景下我们就需要对其进行拆分拆分为足够小的Bitmap比如将512MB的大Bitmap拆分为1024个512KB的Bitmap。不过拆分的时候需要注意要将每个key落在一个Bitmap上。有些业务只是把Bitmap 拆开 但还是当做一个整体的bitmap看 所以一个 key 还是落在多个 Bitmap 上这样就有可能导致一个key请求需要查询多个节点、多个Bitmap。如下图被请求的值被hash到多个Bitmap上也就是redis的多个key上这些key还有可能在不同节点上这样拆分显然大大降低了查询的效率。因此我们所要做的是把所有拆分后的Bitmap当作独立的bitmap然后通过hash将不同的key分配给不同的bitmap上而不是把所有的小Bitmap当作一个整体。这样做后每次请求都只要取redis中一个key即可。有同学可能会问通过这样拆分后相当于Bitmap变小了会不会增加布隆过滤器的误判率实际上是不会的布隆过滤器的误判率是哈希函数个数k集合元素个数n以及Bitmap大小m所决定的其约等于。因此如果我们在第一步也就是在分配key给不同Bitmap时能够尽可能均匀的拆分那么nm的值几乎是一样的误判率也就不会改变。具体的误判率推导可以参考wikiBloom_filter同时客户端也提供便利的api 2.3.4版本 setBits/ getBits 用于一次操作同一个key的多个bit值 。建议 k 取 13 个 单个bloomfilter控制在 512KB 以下以上方案仅供参考欢迎大家提供其他的优秀方案。
