福哥答案2021-01-28：
1.使用key值前缀来作命名空间
虽然说Redis支持多个数据库（默认32个，可以配置更多），但是除了默认的0号库以外，其它的都需要通过一个额外请求才能使用。所以用前缀作为命名空间可能会更明智一点。
另外，在使用前缀作为命名空间区隔不同key的时候，最好在程序中使用全局配置来实现，直接在代码里写前缀的做法要严格避免，这样可维护性实在太差了。
2.创建一个类似 ”registry” 的key用于标记key使用情况
为了更好的管理你的key值的使用，比如哪一类key值是属于哪个业务的，你通常会在内部wiki或者什么地方创建一个文档，通过查询这个文档，我们能够知道Redis中的key都是什么作用。
与之结合，一个推荐的做法是，在Redis里面保存一个registry值，这个值的名字可以类似于 key_registry 这样的，这个key对应的value就是你文档的位置，这样我们在使用Redis的时候，就能通过直接查询这个值获取到当前Redis的使用情况了。
3.注意垃圾回收
Redis是一个提供持久化功能的内存数据库，如果你不指定上面值的过期时间，并且也不进行定期的清理工作，那么你的Redis内存占用会越来越大，当有一天它超过了系统可用内存，那么swap上场，离性能陡降的时间就不远了。所以在Redis中保存数据时，一定要预先考虑好数据的生命周期，这有很多方法可以实现。
比如你可以采用Redis自带的过期时间为你的数据设定过期时间。但是自动过期有一个问题，很有可能导致你还有大量内存可用时，就让key过期去释放内存，或者是内存已经不足了key还没有过期。
如果你想更精准的控制你的数据过期，你可以用一个ZSET来维护你的数据更新程度，你可以用时间戳作为score值，每次更新操作时更新一下score，这样你就得到了一个按更新时间排序序列串，你可以轻松地找到最老的数据，并且从最老的数据开始进行删除，一直删除到你的空间足够为止。
4.设计好你的Sharding机制
Redis目前并不支持Sharding，但是当你的数据量超过单机内存时，你不得不考虑Sharding的事（注意：Slave不是用来做Sharding操作的，只是数据的一个备份和读写分离而已）。
所以你可能需要考虑好数据量大了后的分片问题，比如你可以在只有一台机器的时候就在程序上设定一致性hash机制，虽然刚开始所有数据都hash到一台机器，但是当你机器越加越多的时候，你就只需要迁移少量的数据就能完成了。
5.不要有个锤子看哪都是钉子
当你使用Redis构建你的服务的时候，一定要记住，你只是找了一个合适的工具来实现你需要的功能。而不是说你在用Redis构建一个服务，这是很不同的，你把Redis当作你很多工具中的一个，只在合适使用的时候再使用它，在不合适的时候选择其它的方法。
缓存雪崩，缓存击穿，缓存穿透，以及缓存数据和数据库的一致性。
还有就是缓存key过期的问，合理使用避免频繁和redis建立IO链接。
安全问题，禁用一些危险的命令比如 keys，通用端口最后做一下修改，之前好像暴露出过安全问题。
redis配置bind 理解偏差问题，bind的作用不是白名单不是允许哪些IP可以访问。
Redis功能强大，数据类型丰富，再快的系统，也经不住疯狂的滥用。通过禁用部分高风险功能，并挂上开发的枷锁，业务更能够以简洁、通用的思想去考虑问题，而不是绑定在某种实现上。
Redis根据不同的用途，会有不同的持久化策略和逐出策略，所以，在使用和申请 Redis 集群前，请明确是用来做缓存还是存储。Redis的集群有主从和 cluster 两种模式，各有优缺点。以下规范不区分集群模式，我们分别从使用场景和操作限制两方面说明。
使用规范
1、冷热数据区分
虽然 Redis支持持久化，但将所有数据存储在 Redis 中，成本非常昂贵。建议将热数据 (如 QPS超过 5k) 的数据加载到 Redis 中。低频数据可存储在 Mysql、 ElasticSearch中。
2、业务数据分离
不要将不相关的数据业务都放到一个 Redis中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。
3、消息大小限制
由于 Redis 是单线程服务，消息过大会阻塞并拖慢其他操作。保持消息内容在 1KB 以下是个好的习惯。严禁超过 50KB 的单条记录。消息过大还会引起网络带宽的高占用，持久化到磁盘时的 IO 问题。
4、连接数限制
连接的频繁创建和销毁，会浪费大量的系统资源，极限情况会造成宿主机当机。请确保使用了正确的 Redis 客户端连接池配置。
5、缓存 Key 设置失效时间
作为缓存使用的 Key，必须要设置失效时间。失效时间并不是越长越好，请根据业务性质进行设置。注意，失效时间的单位有的是秒，有的是毫秒，这个很多同学不注意容易搞错。
6、缓存不能有中间态
缓存应该仅作缓存用，去掉后业务逻辑不应发生改变，万不可切入到业务里。
缓存的高可用会影响业务；
产生深耦合会发生无法预料的效果；
会对维护行产生肤效果。
扩展方式首选客户端 hash
如果应用太小就别考虑了，如单 redis 集群并不能为你的数据服务，不要着急扩大你的 redis 集群（包括 M/S 和 Cluster)，集群越大，在状态同步和持久化方面的性能越差。 优先使用客户端 hash 进行集群拆分。如：根据用户 id 分 10 个集群，用户尾号为 0 的落在第一个集群。
操作限制
1、严禁使用 Keys
Keys 命令效率极低，属于 O(N)操作，会阻塞其他正常命令，在 cluster 上，会是灾难性的操作。严禁使用，DBA 应该 rename 此命令，从根源禁用。
2、严禁使用 Flush
flush 命令会清空所有数据，属于高危操作。严禁使用，DBA 应该 rename 此命令，从根源禁用，仅 DBA 可操作。
3、严禁作为消息队列使用
如没有非常特殊的需求，严禁将 Redis 当作消息队列使用。Redis 当作消息队列使用，会有容量、网络、效率、功能方面的多种问题。如需要消息队列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ。
4、严禁不设置范围的批量操作
redis 那么快，慢查询除了网络延迟，就属于这些批量操作函数。大多数线上问题都是由于这些函数引起。
1、[zset] 严禁对 zset 的不设范围操作
ZRANGE、 ZRANGEBYSCORE等多个操作 ZSET 的函数，严禁使用 ZRANGE myzset 0 -1 等这种不设置范围的操作。请指定范围，如 ZRANGE myzset 0 100。如不确定长度，可使用 ZCARD 判断长度
2、[hash] 严禁对大数据量 Key 使用 HGETALL
HGETALL会取出相关 HASH 的所有数据，如果数据条数过大，同样会引起阻塞，请确保业务可控。如不确定长度，可使用 HLEN 先判断长度
3、[key] Redis Cluster 集群的 mget 操作
Redis Cluster 的 MGET 操作，会到各分片取数据聚合，相比传统的 M/S架构，性能会下降很多，请提前压测和评估
4、[其他] 严禁使用 sunion, sinter, sdiff等一些聚合操作
5、禁用 select 函数
select函数用来切换 database，对于使用方来说，这是很容易发生问题的地方，cluster 模式也不支持多个 database，且没有任何收益，禁用。
6、禁用事务
redis 本身已经很快了，如无大的必要，建议捕获异常进行回滚，不要使用事务函数，很少有人这么干。
7、禁用 lua 脚本扩展
lua 脚本虽然能做很多看起来很 cool 的事情，但它就像是 SQL 的存储过程，会引入性能和一些难以维护的问题，禁用。
8、禁止长时间 monitor
monitor函数可以快速看到当前 redis 正在执行的数据流，但是当心，高峰期长时间阻塞在 monitor 命令上，会严重影响 redis 的性能。此命令不禁止使用，但使用一定要特别特别注意。
9、Key 规范
Redis 的 Key 一定要规范，这样在遇到问题时，能够进行方便的定位。Redis 属于无 scheme 的 KV 数据库，所以，我们靠约定来建立其 scheme 语义。其好处：
1、能够根据某类 key 进行数据清理 2、能够根据某类 key 进行数据更新 3、能够方面了解到某类 key 的归属方和应用场景 4、为统一化、平台化做准备，减少技术变更
一般，一个 key 需要带以下维度：业务、key 用途、变量等，各个维度使用 : 进行分隔，以下是几个 key 的实例:
面试官问，实际项目中用Redis要注意哪些规范？
最后
适当的约束是架构成熟的必要条件，通过约定能达到规范是集体开发的最高境界。Redis用的多，也要用的稳，给点约束、立点规矩，生活将变的美好。通过二次封装redis客户端，直接阻断，效果更佳。
答案4：
主库压力很大，可以考虑读写分离。
Master 最好不要做持久化工作，如 RDB 内存快照和 AOF 日志文件。(Master 写内存快照，save 命令调度 rdbSave 函数，会阻塞主线程，文件较大时会间断性暂停服务；AOF 文件过大会影响 Master 重启的恢复速度)。
如果数据比较重要，使用 AOF 方式备份数据，设置合理的备份频率。
保证主从复制的速度和网络连接的稳定性，主从机器最好在同一内网。
官方推荐，使用 sentinel 集群配合多个主从节点集群，解决单点故障问题实现高可用。
