如果共用一个，为了避免 id 重复，还得加 id 前缀，同时有些数据更新频繁，这样也会影响到那些更新不频繁的数据的实时性，但是开多个，也会有维护多个实例的负担，大家都是怎么考虑的

我这里说的是一个业务

不是有 12 个数据库编号嘛？

多个好，方便监控

一个 redis 用到里面多个 db

服务器有资源就多开，省得写了 bug 干挂了 redis ，影响其他项目。维护多个实例没啥负担，容器编排起来

分文件夹不行吗？
加个前缀区分

有钱就多个实例，穷就共用一个

两种情况都有
对于长期的业务，开多个实例，需要就开
需要开一段时间就不开的业务，共用一个实例，并且针对业务给出 id ，业务结束了可以删除这个 id 前缀的 key

共用一个 Redis 挂了就全挂

共用一个，反正我们只用来存 token 和当锁，挂就挂了

根据情况而定
且 cluster 不支持 db

除非是开发环境，不然肯定分开啊
如果不是重型使用，几个 redis 进程的消耗本身微不足道

是 16 个 0-15

直接面向数据库编程。我的 redis 是因为我的脚手架工具一定要我装.不然就不能启动。

1 、看量，量少一把梭，量大就分开
2 、核心服务独占
3 、业务和开发环境要分开，避免开发挖坑

按业务分开

主要取决于 Redis 是用来做什么的，如果就是用来存一存 token ，或者拿来当锁记录的，崩就崩了吧。
但是你如果拿来当消息队列，而且是比较重要数据的消息队列，还是单独部署吧！

一个业务使用同一个 redis

技术最终表现服务业务，看具体业务需求

一个实例，不同 key 加前缀。实际上我这有好几个项目用的都是同一个实例，不存大 key,各个业务自己加前缀区分也没出过问题。大概这样 projectA:user:12345

一个服务， 一个 Redis ，避免出现一些莫名其妙的问题