标签：解释 设置 ops redis Redis appapi key 规则
- 必须明确应用场景，1）作为缓存还是存储；2）数据丢失对应用的影响
- 解释：与持久化关系数据库（MySQL通过Redo可保证数据不丢）不同，Redis在故障时会丢失分钟级别数据，业务必须确保不会受到影响
- 禁止命令：keys、flushall、flushdb；针对大key禁止命令：hgetall，hkeys，smembers，lindex 0 -1
- 解释1：Redis为单线程服务，上述命令会造成实例阻塞，业务高峰时可能引发雪崩
- 解释2：flushall、flushdb命令会造成数据彻底丢失，无法恢复
- 不允许频繁访问的大key存在：单条数据不超过100KB，避免网卡被打满
- 解释：历史真实线上故障，单个key接近1MB，促销时ops超过100，生产千兆网卡（1000Mbps = 128MBps）机器流量直接被打满
- 对于超过100KB但必须使用的低频key（后台管理操作、低峰worker），必须在业务前缀前增加标识
- 实例：bigkey.appapi.xxxxxx
- list/set/hash 等类型数据，item/member/field个数需限制在10万以下
- 解释：此类key占用内存大，无论查询数、删除还是TTL自动超时，都可能造成实例阻塞
- 建议：将field数目超过10万的hash按照field拆分成多个key，以便水平扩展，并规避hgetall流量风险
- 为key设置TTL，建议TTL不应超过3个月
- 解释：Redis是内存DB，成本很高，应该只用于存取『临时热数据』，不经常访问的数据必须可以自动过期
- Java程序直接通过官方Jedis客户端连接，不建议使用Sharded Jedis
- 解释：生产上遇到的一例线程池阻塞问题可能是Sharded Jedis相关bug引起
- 通过（域名:端口号）访问集群，禁止直接使用（ip:端口号）
- 示例：rm6381.jxq.db.dmall.com:6381
- 解释：Redis高可用是通过切换域名来实现的
- Redis性能很高，建议单个应用实例连接池最大连接数配置不超过16
- 解释：相同IDC单次ops一般1ms内，一个连接可以输出1000 ops，16个连接保守估计可以输出15000以上ops，可以满足绝大多数业务需求
- 其他推荐参数配置:
- testOnBorrow=false
- testOnReturn=false
- testWhileIdle=true
- 可读性和可管理性：key必须包含可识别的业务前缀，以方便统计、订正数据，推荐使用『.』或『_』或『:』与业务key隔开
- 示例：appapi.xxxxxx 或者 appapi_xxxxxx 或者 appapi:xxxxxx
- 对于bitmap类型，由于redis将其存储为string，建议key中隐含类型，比如：MEDUSA:BITMAP:PAY_ORDER_USER:20180327
- Redis的多数据库较弱，禁止使用select命令切换db
- 尽量不使用pub/sub，建议通过MQ来满足生产者/消费者业务场景
- 解释：可以持久化的MQ可以提供更高的性能、并持久化数据
- 分片集群twemproxy不支持pub/sub
- Redis分片集群（Twemproxy）命令支持列表：https://github.com/twitter/twemproxy/blob/master/notes/redis.md
标签：解释,
设置,
ops,
redis,
Redis,
appapi,
key,
规则
From： https://www.cnblogs.com/liyanbofly/p/17876538.html