分布式缓存服务 DCS-DCS使用建议:业务使用规范
下载分布式缓存服务 DCS用户手册完整版
业务使用规范
原则 |
原则说明 |
级别 |
备注 |
|---|---|---|---|
就近部署业务，避免时延过大 |
如果部署位置过远（非同一个region）或者时延较大（例如业务服务器与Redis实例通过公网连接），网络延迟将极大影响读写性能。 |
强烈建议 |
如果对于时延较为敏感，请避免创建跨AZ Redis实例。 |
冷热数据区分 |
建议将热数据加载到 Redis 中。低频数据可存储在 Mysql或者ElasticSearch中。 |
建议 |
Redis将低频数据存入内存中，并不会加速访问，且占用Redis空间。 |
业务数据分离 |
避免多个业务共用一个Redis。 |
强烈建议 |
一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。 |
禁止使用select功能在单Redis实例做多db区分。 |
强烈建议 |
Redis单实例内多DB隔离性较差，Redis开源社区已经不再发展多DB特性，后续不建议依赖该特性。 |
|
设置合理的内存淘汰（逐出）策略 |
合理设置淘汰策略，可以在Redis内存意外写满的时候，仍然正常提供服务。 |
强烈建议 |
DCS默认的逐出策略为volatile-lru，请根据业务需求选择。Redis支持的数据逐出策略 |
以缓存方式使用Redis |
Redis事务功能较弱，不建议过多使用。 |
建议 |
事务执行完后，不可回滚。 |
数据异常的情况下，支持清空缓存进行数据恢复。 |
强烈建议 |
Redis本身没有保障数据强一致的机制和协议，业务不能强依赖Redis数据的准确性。 |
|
以缓存方式使用Redis时，所有的key需设置过期时间，不可把Redis作为数据库使用。 |
强烈建议 |
失效时间并非越长越好，需要根据业务性质进行设置。 |
|
防止缓存击穿 |
推荐搭配本地缓存使用Redis，对于热点数据建立本地缓存。本地缓存数据使用异步方式进行刷新。 |
建议 |
- |
防止缓存穿透 |
非关键路径透传数据库，建议对访问数据库进行限流。 |
建议 |
- |
从Redis获取数据未命中时，访问只读数据库实例。可通过域名等方式对接多个只读实例。 |
建议 |
核心是未命中的缓存数据不会打到主库上。 用域名对接多个只读数据库实例，一旦出现问题，可以增加只读实例应急。 |
|
不用作消息队列 |
发布订阅场景下，不建议作为消息队列使用。 |
强烈建议 |
|
合理选择规格 |
如果业务增长会带来Redis请求增长，请选择集群实例（Proxy集群和Cluster集群） |
强烈建议 |
单机和主备扩容只能实现内存、带宽的扩容，无法实现计算性能扩容。 |
生产实例需要选择主备或者集群实例，不能选用单机实例 |
强烈建议 |
- |
|
主备实例，不建议使用过大的规格。 |
建议 |
Redis在执行RewriteAOF和BGSAVE的时候，会fork一个进程，过大的内存会导致卡顿 |
|
具备降级或容灾措施 |
缓存访问失败时，具备降级措施，从DB获取数据；或者具备容灾措施，自动切换到另一个Redis使用。 |
建议 |
- |
