Redis作为缓存使用,在值大小为1k的情况下,可以支持到每秒近十万次的set操作,可见redis的运行效率是非常的高的。但是为什么我们还会有的时候会遇到redis的瓶颈呢?一般来说,都是因为我们没有对redis的所有的操作有一个全面直观的了解。
Redis运行模式
Redis是运行在单线程下的,也就是说,一个redis实例最多也就只能占用一个cpu,当redis实例线程运行所使用的cpu到达100%后,就无法进行更多的操作了,甚至从操作系统层面就开始拒绝连接了。然后我们就遇到了最迷茫的事情,为什么我设置了很多的连接,但是都无法连接到redis服务呢,原因大抵如此。

Redis在执行一个操作的时候,其他所有的操作,包括系统的,后台的等等,都会出现阻塞,一旦有阻塞,就会出现返回变慢的情况。

虽然说redis的运行时非常快的,但是也会受到很多其他因素的影响,在分析过程中,要注意都有什么耗时的操作在霸占cpu(依旧是单线程的问题),这些操作能不能分解,这些操作能不能再做缓存,这些操作是否是必要的,在优化处理时都应该考虑这样的问题。

总而言之,redis是以单线程来应对上层多线程的调用,在编码过程中,使用到redis就要考虑到这一层。
Redis操作中需要规避的一些问题
Redis提供了比较多的数据结构,让单纯的kv结构更加丰富,但随之而来的问题就是,数据结构越是复杂,操作时间越长,记住redis只能单线程!

当然,redis就是为了大量快速地读写一些数据而生的,放心大胆地去用,不然搭建一个redis干嘛呢?

为了放心地使用redis,下面列举一些需要特别注意,必要时要规避这些操作。这些操作有时会很慢,但是具体有多慢呢?我们不能用通常的模式去理解,如果说这个操作只需要10ms呢?是否算慢呢?当一个操作需要10ms时,这个redis的实例,在1s中只能执行100次同样的操作,这样算快还是慢呢?当redis的调用量上来以后,这个操作就成了系统的瓶颈了。

SISMEMBER
这个操作是查看集合中的成员。在集合较大的情况下,会变得比较慢。所以,一般不要直接返回整个集合中的成员,而是采用标准的调用方式SISMEMBER key member,查看集合是否具有该成员,从而避免大量的无用的数据处理。

SINTER
返回一个集合的全部成员,该集合是所有给定集合的交集。当两个巨大的集合进行交集的运算,其效果也可以是毁灭性的。

LPUSH & RPUSH
在队列头部/尾部插入一串key。这个操作本身并无什么大问题,但是我们又考虑到redis是一个单线程,那么我们一次性插入了大量的值,就会造成阻塞,那么就有必要把这一次操作分散为多次的操作,循环去做了,虽然觉得循环会耗时,但是在没有读写分离的情况下,这种处理方式总归是比直接阻塞redis要来得好的。建议一次性增加200个左右为佳。但是这也受限于key值的大小。具体的问题具体分析,在调试和测试中要注意这部分的耗时,可以控制在10ms以内即可(redis默认超过10ms的操作对于redis是慢的)。

MSET & MGET
批量设置和获取一串key的值。此操作与上面的也是一样的,要考虑到整体的耗时,在需要的时候要做到循环设置/获取,标准也是尽量控制一次操作在10ms以内。

KEYS
KEYS操作,查询并枚举redis中与给定规则相符的key。此物为大杀器,看似每个操作只需要40-70ms,在编码和功能性的测试中,根本无法感知到其带来的恶果,因为70ms实在是很难感知到到底有多长,但是用另一个指标来衡量,就很明显看出来了。取平均值,假设KEYS操作耗时50ms,那么一个redis实例的qps只有可怜的20,还是在不做其他动作的情况下。
此处要着重说明之前的一个线上问题的解决,就是因为KEYS操作引起,最后调用者临时做了读写分离,并且将redis的实例拉到了恐怖的21个才勉强支持起线上的调用量,堪称本司有史以来最豪华redis,并且这个还是在用户数没有暴增的情况下。
所以切记,KEYS是禁止使用的!(后续再新机房中的redis会直接改掉这个操作,具体怎么再来调用KEYS操作,我就不告诉你!)

CONFIG GET & CONFIG SET
非管理人员,禁止使用!

Redis需要注意的操作其实并不多,并且很多情况下,根本不会造成压力,但是这些情况都是需要在编码时注意的,去衡量并正确高效地使用redis。记住一句,我们是单线程!我们是运行在毫秒级别的服务!
Redis的设计中需要注意的
Redis本身没有强的模式,在使用中,所有人都可以随意地设置redis的存储,那么我们要如何才能高效地使用redis呢?有一些问题就需要在存储的设计时要注意了。

Key的命名要简短,且有意义。Key在redis中也是要占用空间的,并且内存是很宝贵的,所以要节约使用。当key名有意义,那么在程序的逻辑处理过程中,就有可能直接获得key名,从而直接去获取到相应的value了。

Value值不宜过大。当value在1k的时候,redis可以支持到10w/s左右,那当value的大小达到10k,那么redis就只能支持到1w/s左右了。可见value的大小对于redis的效率还是很有影响的。所以,每个key的value值要尽量精简,哪怕是冗余一些多余的key也不要制造一个超级大的key因为那样的话,还不如使用其他的存储来得实惠了。

返回的数据要尽量紧凑,小型。虽然redis没有对客户端做什么限制,但是他是预留了功能的,可以在一次请求超过了多久,或者是总数据量超过多少,还有就是规定时间内发送数据超过多少的情况下,就可以直接杀死链接,没有任何返回,也没有任何道理。所以要注意,只返回有用的东西。

对于list要活学活用。我们不能做KEYS,那么当我们又需要将某种类型的KEY进行计数的时候,我们就应该去使用list了。将一些相关的key都存放于一个list中,我们就可以轻松地使用LLEN来获取到list的长度,其效果可以抵消一部分KEYS的应用场景了。对于list也并不是万灵药,虽然在很多情况下,list可以消耗更少的资源来做到和key相同的效果,但是也要注意,list不适宜过长,要做到可控。

Set(集合)的运用,与list类似,就不多描述了,参见一下redis的命令列表吧。这也是一种非常有用的数据结构。

对于list和set还是要说两句,正因为有了这样的数据结构,我们得以用更小的代价管理更加庞大的key。

要用SETEX去设置key的过期时间。Redis本身就是一个缓存,只是一个缓存,在需要持久化的场景下,不要妄想能在redis中做的存储大量的值。所以redis中尽量存储一些不需要持久化的东西,并且如果关联到持久化的数据的话,最好能有缓存载入的脚本,能手工载入一些缓存数据,在出现整个redis集群完全崩溃的情况下可以减少crash到数据库的时间。

我们是单线程!又说到这个话题了,redis就是个单线程,我觉得也不太可能改造了。那么我们怎么来应对大量并发呢?
其实并不是没招,招有的是。
方法一,我们可以使用队列,将请求放入队列中,再取出处理,将大量的并发序列化,持续地,高效地在redis中处理。
方法二,读写分离。在有可能的情况下一定要具备读写分离功能。当序列化后依然无法响应大量的并发,那么我们就需要做读写分离了。这样只要在量上来时,多拉实例,并添加到负载均衡即可了。

要为分布式做好准备。现在本司在redis的分布式上选型是twemproxy,在分布式的情景下,很多操作会受到限制,所以,当可以预见到redis在将来会增长到需要做分布式的场景下,就需要注意了,在编码中就要有意去规避这些操作,以减少将来修改的成本。

如何去界定一个redis是否需要做成分布式,建议当redis的数据量超过15G时就需要更换为分布式,当redis的数据量达到8G,并且有增长的趋势时,就需要考虑分布式的方案了。

就本司当前情况来看,只有少量的一些应用会达到分布式的要求,其他的,因为历史原因,不适合马上切换为分布式。大量的应用还是处于读写分离即可支持的情况下,所以不一定上线,但一定要有读写分离的方案,或者是预案。
后续的一些展望
在后续的规划中,redis更加倾向于小型化,轻量化的部署。这里有两条路,一是集中化的分布式redis,虽然将数据打散了,这样解决了容量的问题,但是,但是!我们特么还是单线程!同时,集群化,也限制了一些特殊的操作,但是这些小技巧有的时候又是非常nice的。那么我们就提出了第二个方案,二级缓存。在持久化层上有几个集群,这些集群又可做读写分离,在这个大容量的缓存上每个服务,甚至是每个进程都对应一个自己的超级轻量化redis,不需要预加载,不怕数据丢失,随时可重启的这种,当然,可以做到读写分离也是极好的。每个关于缓存的请求,都会先去查询二级缓存中的redis(轻量化的那个),当不命中时,会去一级缓存(大容量的那个)中查询,如果命中,则将数据加载至二级缓存,返回结果。当一级缓存也不能命中时,就要去到持久化层获取实际的数据,并同时将数据加载到一级和二级缓存了。

二级缓存的模式下,又涉及到读写分离等问题,但那时,将是千万级别并发访问了,希望将来有一天能够看见。