Redis的个人使用经验总结

逃离我推掉我的手 2022-06-16 09:27 345阅读 0赞

redis是性能比较好的nosql，这里总结下个人使用的经验总结：  
【key命名】  
1、全局规划，key值前缀作为命名空间 ： key - value第一级的key值前缀要全局规划好，避免冲突导致互相覆盖。  
2、key不要包含空格符，命名不要过长 ： 含有空格容易导致输入错误，命名过长浪费内存空间。  
4、key前缀不要出现魔鬼数字，防止硬编码 ： key值前缀应该要清晰明了，容易理解。

【内存】  
1、避免内存泄露 ： redis是内存数据库，随着数据的越来越多，占用会越来越大，要注意垃圾回收，定期清理垃圾数据。  
2、合理规划内存占用，养成节约内存的习惯：  
1）收到系统最大内存限制，一般应用实例缓存控制在最大内存的2/3以内。  
2）大数据内存占用应该接近实际存储容量，但还要实测分析内存占用是否合理  
3 )预留一定的内存空间，一般redis只适用机器内存1/2到2/3，内存其实分为两部分：  
1））缓存数据占用的内存，对应于redis.conf配置的maxmemory。  
2））处理高并发请求分配的临时内存，并发请求越多，临时内存越多。  
3、key的数量越少越好 ： 减少key数量可以降低内存开销  
4、权衡value的取值为，尽量使用纯数字可以节省内存：比如把“true”改为1，“false”改为 0。

【事务】  
1、优先使用批量接口获取批量数据： redis的交互越多越耗时，另外也不能保证其原子性，使用redis批量接口命令，其次才使用事务。  
2、集合操作为主的业务考虑使用set数据结构：set有丰富的去交集、差集等命令，简单高效，保证了事务的原子性。  
3、redis只支持简单事务，redis事务是一个隔离的操作，事务中的所有命令都会序列化，按顺序执行，事务的执行过程中，不会被其他客户端发过来的命令请求所打断。  
4、redis对事务的支持没有其他关系型数据库那么强大，redis在事务失败时不会进行回滚，而是继续执行余下命令，它不保证原子性（所有指令同时成功或同时失败）。只有决定开始执行全部指令的能力，没有执行到一半回滚的管理。如果事务执行到一半redis被kill掉，已经执行的指令同样不会被回滚。

【性能】  
1、尽量减少和redis的交互次数：交互的越多越耗时，另外原子性也得不到保证，尽量使用批量命令。  
2、调优参数 ： 通过调整set\_max\_inset\_entries参数，从def的512调整到1024。但是占用内存会增大。  
3、redis最佳使用方式是cache非持久化：其他模式会占用更多的资源，需要根据具体项目做决定。

【可靠性】  
1、需要定时监控redis的健康情况：使用各种redis健康监控工具，实在不行可以定时返回redis 的 info信息。  
2、客户端连接尽量使用连接池（长链接和自动重连）

【安全性】  
1、无用户管理和权限管理： 全局只有一个超户，对应一个密码。  
2、不安全的客户端访问方式。

redis不适合作为海量数据存储方案，redis适合在数据规模较小，性能要求较高的条件下使用。