redis如何使用，redis使用技巧

1、redis使用技巧：用好redis要充分了解其工作原理，不要把它当成一个透明的盒子。

（1）key设计，以“：”作为分割符，加上服务简称，例如：服务简称（不超过5个字符）:实际key

总体key不易太长

redis如何使用、（2）必须使用连接池；要么不用redis要么就全程连接池，否则会有3-5倍的差异

（3）架构上的三级存储：程序内部缓存，redis缓存（第三方独立缓存），数据库，数据仓库（历史数据）

• 数据量大时，对数据库的使用要提前做好：分库，分区，分表（历史数据）
• 数据库或者缓存要基于业务的拆分，不同业务使用不同的redis库和数据库；
• 同一业务内部的数据量大时，要提前做好业务程序的水平拆分；
• 注意：redis只缓存热点数据，程序内部只缓存本程序所使用到的热点数据；

2、特别注意：

（1）Redis是缓存，不是数据库，不要把Redis当作数据库使用！！！！！

redis 使用。（2）在开启了Redis持久化机制时，一旦Redis发生故障重启时要全量加载持久化的数据，这时可能会造成未来得及持久化数据的丢失，并且缓存的数据量大时加载非常慢，因此，建议每个redis实际缓存的数据不要超过6G（这一建议的另一个原因是：Redis工作是单进程的，缓存数据量大时访问速度也会降下来）；

（3）Redis缓存使用方式（注意：缓存的引入主要针对读操作的数量远大于写操作的场景）：

• 全量缓存，redis不做持久化，使用场景：总数据量少、数据冷热区分度低，数据全量加载至Redis，其持久化由配置文件或数据库完成，例如缓存全国所有的城市区号和对应的城市名字；
• 热点缓存，redis不做持久化，使用场景：总数据量大，冷热数据区分度明显，此时只加载热数据至Redis缓存，可以采用Redis的expire机制通过时间流逝自动逐出冷数据的方式，让热数据自动留下来；数据一旦被访问之后要延长expire时间，此时需要注意：缓存穿透的问题，expire时间过短是引起该问题的因素之一。

（4）Redis做缓存+关系数据库做持久化的工作模式会造成二者数据不一致的问题，它可以通过采用分布式锁来环境，但是要注意：分布式锁极难保证一致性，从某种程度上说，只要存储的数据被放在一个以上的地方，都无法及时、彻底保障一致性（详情可查询CAP原则）。

3、Redis的pipline与lua脚本，二者都能在一定场合下加速访问，二者各自适用的场景：pipline只是批量发送命令和结果，命令之间不能存在依赖关系；lua脚本可以让连续操作的多个命令之间存在依赖关系。

redis快速入门、使用pipline和lua的时候要特别注意：

（1）在数据存在分片时，只能操作当前redis分片的数据；

（2）简短的连续操作，不适合长期占用redis；

4、对于每个服务，如果其redis缓存数据量较大，例如超过500，则要独占一个库，selectdb；为什么要分库？如果数据量增加了，可以随时将该数据从Redis中迁移出来，不需要程序做任何改动。

5、redis分片方式：预分片与动态分片

（1）为什么要分片？redis是单进程单线程的方式工作，其内部又为热点数据，访问频度高，数据量大时，性能将会受到影响；

（2）分片的本质：部署多个redis实例，redis的所有数据都基于key，因此把将key按照一定算法映射到不同的redis实例上，从而实现将数据存储到不同的redis实例上；

（3）分片的方法：

• 预分片，预估数据量大小，提前给够redis实例的数量，适合：目标数据量级可预估；可采用预先多分配Redis分片的方式，承载同一量级内的数据；常见ToB领域，一般使用twemproxy做集群管理中间件；
• 动态分片，数据量难以预估，并且持续增加；场景ToC领域；

• 分片+分组，服务拆分之后，数据将会被分散至各类微服务中，从而降低一组内的缓存数量；
• 常见的几种分片之后的负载均衡方式：客户端负载均衡，服务端负载均衡（RedisCluster），中间层负载均衡（Codis，Sudis）；

6、redis通信协议：简单，支持常见的各种语言；

间隔符号，linux下是\r\n，简单字符串以+开头，错误以-开头，整型数以：开头，大字符串以$开头，数组以*开头。