推荐: 1.确定场景,是缓存(cache)还是持久型;
2.Cache 的使用原则是:“无它也可,有它更强”;
3.永远不要强依赖 Cache,它会丢,也会被淘汰;
4.优先设计合理的数据结构和逻辑;
5.设计避免 bigKey,就避免了 80%的问题;
6.Keyspace 能分开,就多申请几个 Redis 实例;
7.pubsub 不适合做消息分发;
8.尽量避免用 lua 做事务
不建议: 1.“我的服务对 RT 很敏感,任何抖动都会导致服务出现问题”。 我们更建议:“低 RT 能让我的服务运行的更好,如果偶发高 RT,我的服务也 能应对”。
2.“为了方便,我把很多业务依赖的数据都放在一个 redis 里” 我们更建议:“区分 cache 和持久化数据,尽量使用不同的 Redis 实例;此外, 不同的应用尽量使用不同的 Redis,避免相互影响。”
3.“我有一个大排行榜/大集合/大链表/消息队列;我觉得阿里云 Redis 服务能力 足够支持。” 我们更建议:“尽量拆散大 Key,服务能力不够可通过分布式集群线性扩展, 而大 Key 是无法线性扩展性能的。”
4.我有一个特别大的 Value,存在 redis 里,访问能好些。需要了解:redis 吞 吐量有瓶颈。
资源来源于《阿里云数据库运维实战问题改》
https://developer.aliyun.com/topic/download?spm=a2c6h.20345107.J_6399686890.1.2e1e17dbzKUX5r&id=8198
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。