使用redis的经验之谈

先说好，这可是一篇水文，哈哈哈。

可以直接看 https://redis.io/documentation

                   https://docs.spring.io/spring-data/redis/docs/2.1.9.RELEASE/reference/html 

一、为什么要写这篇文章？

大多数中小型系统中使用redis非常不严谨，redis的天然单线程，适合一致性存储，基于内存，速度比数据库快n倍，友好的操作方式被程序员拿来适用于各种操作中，将其形容为垃圾场也不为过，数据丢进去的时候各种姿势，某天就会突然发现取出来变得困难或者效率不那么高。产生这些现象的本质是程序员没有认清redis在系统中承担的角色，也就是职责范围，拿来做了n种骚操作。

为此我建议大家在解决方案中，如果能想到用redis来解决，不妨再花几分钟想想不用redis是否还有其他方案。

试想一下 redis穿插在整个系统中，承担系统功能、业务功能，对于大多数没有做集群的redis来说，在某种程度上将系统业务用redis做成了串连，降低了系统的整体io能力，如果非常不幸redis服务不可用了，系统会如何？再者乱丢乱扔数据redis碎片化问题也会越来越严重。

二、需要注意的操作redis的方式

1、业务数据分区存储，如果不支持分区，那就数组分组。比如存储用户的登陆信息，建立一个空间为 user ，然后进行map key value的方式操作

2、禁止使用 keys* 等命令。单线程的redis，一个命令下去时间开销是非常宝贵的，命令执行没有返回除非强制终止，否则会一直执行直到完成，那么在后面要操作redis的人就开始排长队，根据业务不同排长队带来的后果也不相同。

3、谨慎使用lua脚本。lua的支持无疑是一大利器，但是也需要非常注意 lua脚本的编写，还是那句话时间开销要非常注意。

4、不要太频繁的去操作redis。经常有多线程方式去操作redis的业务，但是要注意当前程序的redis连接池，非常大的可能性出现连接还未释放，马上线程又去申请新的连接，占满连接池后开始扩张连接池，不是拖垮当前程序就是拖垮redis。拖垮自身程序到不是致命问题，一旦拖垮redis那哭着加班都解决不了造成的后果了。

5、需要对redis在整个系统中承担的角色非常清晰，不要什么都丢给redis，有些不是热数据能进数据库就进数据库。如果实在离不了redis，建议分redis单独处理某一块业务，避免所有业务流量都跑到一个redis上造成拥塞或其他问题，要坏就坏一块，不要影响整体。

三、操作redis的2种方式

1、jedis，这种我就不介绍了，操作非常多，非常全。

2、springboot-redis-starter

springboot-redis是一个开箱即用的starter，官方文档中简要的介绍了其功能。

RedisTemplate 官方只实现了string的序列化和反序列化，但是平时研发场景绝对够用了，

根据业务场景分空间存储数据
举例，存储用户的信息   业务空间为user    key是userId    值是User对象
redisTemplate.opsForHash().put("user","userId","User");

redisTemplate的合理使用能解决很多问题，使用前需要特别考虑你需要存储的数据结构，存的时候需要考虑取的问题，更需要考虑存取操作对系统业务的影响。

欢迎关注我的个人公众号

redisTemplate也支持lua脚本，有兴趣的自己看文档。